MathGroup Archive 2005

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

Search the Archive

Re: Re: Re: Types in Mathematica

On 26 Nov 2005, at 16:47, Steven T. Hatton wrote:

> When I wanted a means of crating a locally orthogonal basis in  
> Mathematica, I
> turned to my experience in 3D graphics for a solution.  I've found  
> a few
> surprising limitations in the offerings of Mathematica in terms of
> mathematical functionality.

I would suggest that before deciding you have come across   
"surprising limitations in the offerings of Mathematica in terms of
mathematical functionality" you should post your problem to this  
mailing list. There may be fewer limitations than you think.

> When I asked questions about Mathematica as a programming language,  
> I have
> been intending the types of issues treated in the TMGB-P by Michael  
> Trott.
> There are numerous subtelties dealing with order of evaluation,  
> effects of
> attributes, canonical ordering of arguments, etc. which lie  
> completely in the
> domain of Mathematica as a programming language.  In order to use  
> Mathematica
> effectively, one has to have a fairly good grasp of such matters.   
> There is
> clearly an underlying programming language which is, to my  
> knowledge, nowhere
> formally presented in isolation.  That may be a business decision.   
> I don't
> know.

Actually, I referred to such matters as partly "basic Mathematica  
literacy" and partly "tricks of the trade". Of course the border line  
between the two is rather narrow (and constantly changing as  
Mathematica is being developed) but on the whole the Mathematica book  
only deals with the former. There are many things you can do with  
Mathematica that do not belong to any general theory of programming  
languages and won't be found in the Mathematica book but are useful  
"tricks of the trade". I could mention just two examples: one is the  
so called "algebraic programming", which I discussed in an article in  
the Mathematica Journal a few issues back. It basically a matter of  
using ideas form algebra (and even algebraic functions0 for solving  
problems not normally regarded as problems in algebra. Essentially,  
that is a way of programming that will work in a Computer Algebra  
System, but not in a general programming language.
Another interesting example, is the way Carl Woll has been using the  
optimised technology of sparse arrays to solve numerous problems  
which on the surface have nothing to do with sparse arrays. He has  
posted now a number of examples of this technique. Obviously this  
belongs to the "tricks of the trade" of Mathematica. These tricks  
work only because of the particular features of the Mathematica  
implementation of certain mathematical functions, and there is no  
reason to expect they would work in an analogous way even in another  
CAS, never mind a general programming language.

There is in fact a vast number of similar techniques, almost none of  
which are discussed in the Mathematica book. Michael Trott's book has  
quite a few "tricks of the trade" (by the way, I have taken this  
expression from a regular column in the Mathematica Journal, edited  
by Paul Abbott, who possibly knows more about these things than  
anyone else - perhaps he will comment on this?) but in fact it is not  
really written form a programmer's view point. To see the difference  
you should compare it with David Wagner's "Power Programming with  
Mathematica. The Kernel.". That is a book written by a programmer for  
programmers and even though it was written for version 3 it is still,  
in my opinion, the most illuminating text on Mathematica programming  
there is.

Andrzej Kozlowski

  • Prev by Date: Re: Smooth the data in a table, Why this cannot work?
  • Next by Date: Re: Re: Re: Types in Mathematica
  • Previous by thread: Re: Re: Types in Mathematica
  • Next by thread: Re: Re: Re: Types in Mathematica