|
[Date Index]
[Thread Index]
[Author Index]
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
|
