MathGroup Archive 2005

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Types in Mathematica thread

  • To: mathgroup at smc.vnet.net
  • Subject: [mg62778] Re: Types in Mathematica thread
  • From: "Steven T. Hatton" <hattons at globalsymmetry.com>
  • Date: Mon, 5 Dec 2005 03:37:32 -0500 (EST)
  • References: <dmp9na$hi2$1@smc.vnet.net>
  • Sender: owner-wri-mathgroup at wolfram.com

OK, this is my third attempt to write a reply to this message.  There is
something to be said for not using pre-release software for /everything/. 

:(

I wrote more in my previous posts on just about every point herein. 
Unfortunately, the latest (at your own peril) bits for my usenet client
seem to be a bit buggy, thus I have lost my previous posts. 

Kris Carlson wrote:
 
> My message:
>  
> Hmmm, most of you know more than I do about Mathematica and programming
> but it seems this thread missed some of the mark. I'm harking to Murray's
> email because he gave the best answer. 

Do you have a usenet message ID for that?

> 1. Everything is an expression, which is wonderful in its simplicity. Thus
> since everything is of the form head[body], everything is typed in at
> least one way via the head, and everything can be tested for its type, eg,
> with Head[expr].

How does that differ from type checking in such languages as C++?
 
 
> 4. There are other built in type tests that rely on other tests than Head:
> NumberQ, NumericQ, IntegerQ, EvenQ, OddQ, PrimeQ; ArrayQ, VectorQ, MatrixQ
> (for these there are nice element tests, too), PolynomialQ (element
> tests). There are built in "structural" tests, and I mention these for the
> reason mentioned next: SameQ, UnsameQ, OrderedQ, MemberQ, FreeQ, MatchQ,
> ValueQ, AtomQ. With these, argument-testing syntax is f[x_?testQ]. q.v.
> Section 2.3.5.

RealQ?  Ironically that one seems to be missing.  Probably an intentional
ommission. 
 
> 5. Mathematica excels in pattern-matching, which in one form or another
> (little pun there), is what all these other tests do. There are many
> built-in high level pattern matching functions and devices. Since we can
> write our own pattern tests, data typing is limited only by our own
> ingenuity. Thus, overall, the type-testing and automatic conversion
> facility in Mathematica exceeds what I have seen rigidly implemented in
> other languages (I hasten to say I am not broadly educated in other
> languages.)

What distinguishes Mathematica from compiled languages is largely that these
mechanism are selfinflicted.  That is, Mathematica applies its pattern
matching to Mathematica code as it is evaluated.  In C++ the only places
where such a thing is applicable are in the CPP (the root of all C++ evil),
and templates, but only at (pre)compile time.

In a sense, Mathematica is like a scripting language along the lines of
bash, JavaScript, Perl, etc.  All of these languages can generate and or
modify code as they interpret code.  They all have pattern matching and
substitution rules of one form or another.  And of course, Lisp must be
mentioned in this context, though it is not generally considered a
scripting language.

> 6. Taking a statement from Maeder a bit out of context, "In general, such
> [devices] are powerful tools for proving the correctness of an
> implementation." He said it in regard to constructors and selectors acting
> on datatypes. (M220 v1.1, Datatypes)

Can you clarify what you mean by "M220 v1.1, Datatypes"?  I assume that
relates to the Mathematica training course.  Are you referring to text
distributed with the course?

> 7. Downvalues are "default" function structures, or "common" functions, or
> "built-in function" structures, or "broadest class" functions. Upvalues
> are "special case" functions, or "user-defined" functions / modifications
> of built-in or default functions, or "narrow-case" functions, or
> "context-dependent" functions. (This latter is especially important for AI
> and for a general understanding of the universe.)

Upvalues are evaluated when the associated symbol is encountered as an
argument.  This precedes the evaluation of downvalues of the function in
which the argument appears.  I am not sure of upvalues are ordered according
to specificity in the way downvalues are.  I would expect them to be, but I
really don't recall having read that they are.
 
> What is overloading? Mathematica does not provide functions such as
> plusII[ i1_Integer, i2_Integer], plusRR[ r1_Real, r2_Real ], plusRI[
> r_Real, i_Integer }, and so forth. You would not be using it if it did
> [because it would be a big pain in the rear like we find in other
> "strongly typed" languages--KWC]. You simply write

C++ has a very powerful function and operator overloading mechanism. You
certainly can overload, say, + for vectors.  You can overload it using
templates which makes the overload definition apply to any abstraction
which matches the template structure.
 
> 
> In[1]:= 1.1 + 2/3
> 
> Out[1]= 1.76667
> 
> 
> and expect it to work.

It depends what exactly you expect. C++ can be fairly tricky regarding
numerical type conversions.  But so can Mathematica.  There are situations
where you have to treat results as complex numbers, for example, when all
your inputs are "real", and typical usage in math would suggest a real
value result.
 
> For automatic type conversion, use definitions like
> 
> 
> h /: x_h + i_Integer := plusHI[ x, i ]
> 
> 
> or reuse existing code,
> 
> 
> h /: x_h + i_Integer := x + makeH[ i ]
> 
> 
> where makeH[ i ] is a constructor (type converter) that turns in integer i
> into a h data element.

One thing you can't do (AFAIK) is type conversion based on accepted
parameter types in a function call.  For example, in C++, you could create
a Date class that automatically converts to a string when passed to a
function taking an argument of type string.
 
> 8. All the above being said, my conclusion is that Mathematica is a
> superior language designed and implemented by superior intellects. As
> Andrzej just said, post a problem to MathGroup before assuming Mathematica
> can't do something.

You really have to put that in perspective.  Almost every program I use, to
include Mathematica is written in either C or C++.  Some have a
considerable amount of additional code written in some form of an
interpreted language.  For example Mozilla has a lot of JavaScript built
in. Emacs is largely implemented in Lisp, but the Lisp interpreter itself
is written in C.  Even Java is written in C and C++.  Mathematica is very
specialized, and is not well suited to creating such facilities as user
interfaces.  In many ways its graphics support is fairly limited in
comparison to development environments such as OpenSceneGraph.

In the C++ Standard Library there are 57 (IIRC) generic algorithms for
operating on generic collections.  Many of these have direct parallels in
Mathematica.  Also have a look at section 5.2.1 of
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1836.pdf

As I've said, Mathematica is a very specialized language.  To compare it to
C++ in terms of superiority would not make sense.  If every program written
in C++ failed to function at the same time, the entire technological
infrastructure of the planet would come to a screeching halt.  The same
cannot be said of Mathematica.  OTOH, if I want to solve differential
equations using familiar symbols and relatively easy to use constructs, I
would not turn to C++.  If I wanted to write a program to do that, I most
certainly /would/ use C++.

-- 
The Mathematica Wiki: http://www.mathematica-users.org/
Math for Comp Sci http://www.ifi.unizh.ch/math/bmwcs/master.html
Math for the WWW: http://www.w3.org/Math/


  • Prev by Date: Re: Re: Types in Mathematica
  • Next by Date: Re: Types in Mathematica thread
  • Previous by thread: Types in Mathematica thread
  • Next by thread: Re: Types in Mathematica thread