Re: Re: Re: Types in Mathematica
- To: mathgroup at smc.vnet.net
- Subject: [mg62526] Re: [mg62515] Re: [mg62456] Re: Types in Mathematica
- From: "Steven T. Hatton" <hattons at globalsymmetry.com>
- Date: Sun, 27 Nov 2005 02:40:01 -0500 (EST)
- References: <200511191053.FAA16418@smc.vnet.net> <200511260747.CAA06485@smc.vnet.net> <BD8ABCAD-B6A4-49F8-809E-0B5B67783E69@mimuw.edu.pl>
- Sender: owner-wri-mathgroup at wolfram.com
On Saturday 26 November 2005 05:36, Andrzej Kozlowski wrote:
> *This message was transferred with a trial version of CommuniGate(tm) Pro*
>
> 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.
Well, for one - and it's debatable whether it falls into the category of math
- I have mentioned Karnaugh maps. But that arose from the discussion of
symbolic logic, and the lack of a biconditional operator, etc. That does IMO
fall into the category of math, without question.
One shortcoming I found was in the available 3D rotations. The Mathematica
offerings do not provide the same functionality commonly found in 3D graphics
libraries. In particular, they have singularities. I believe I have asked
about that in the past in the newsgroup.
> 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.
Then I will say I am only referring to a limited subset of what is in the
Mathematica book. In particular, the material discussed in Part 2, and
specifically sections 2.1 through 2.8. Add to those the sections in the
Apedices discussing the mechanics of how Mathematica works.
> 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.
Don't put /anything/ past the C++ community. They'll try some of the craziest
things. Sometimes they even produce usable results. I believe your topic is
interesting, and hope to look into it. I have been interested in that kind
of programming for some time (if I understand what you intend.) I even wrote
a rudementry symbolic parser that converts symbolic logic statements into
parse trees. The longterm objective was to create an algebraic programming
system intended to both explore, and represent concepts in abstract algebra.
There is some interesting discusion of the mathematics I was approaching in
Volume 1 of _Fundamentals of Mathematics_, Edited by H. Benke, F. Bachmann,
K. Fladt, W. Süss and H Kunle, Translated by S. H. Gould, The MIT Press,
Cambridge, MA, 1974
> 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.
The sparse arrays themselves are discussed in The Mathematica Book.
> 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.
I've actually been considering getting Roman Mäder's _Programming in
Mathematica_. I suspect it is a bit less advanced than Wagner's book, but
Wagner's book appears to be out of print, and is available from Amazon at
$150 US for the one copy they have access to.
Here are some general questions about how Mathematica is discussed which seem
considering.
Is it meaningfull, and would it be useful to talk about function signatures?
That is, a symbol used as a function may have different sequences of patterns
associated with it. In languages with function overloading the formal
parameter list of a function can be used as a means of disambiguating (form
of) the function to call. The same kind of behavior happens in Mathematica.
In Java and C++ the function name inconjunction with its formal parameter
list (and a few other things) is called its "signature". I do not recall
ever encountering the term function signature in Mathematica literatue.
Assuming my observation is accurate regarding common usage, why do people not
talk about function signatures in Mathematica?
A related question follows from this example:
In[n]:=Information[Plot3D]
Plot3D[f, {x, xmin, xmax}, {y, ymin, ymax}] generates a three-dimensional plot
of f as a function of x and y. Plot3D[{f, s}, {x, xmin, xmax}, {y, ymin,
ymax}] generates a three-dimensional plot in which the height of the surface
is specified by f, and the shading is specified by s.
...
Note there is no specification of /what/ "f", "x", "xmin", "xmax", "y",
"ymin", and "ymax" should be. What difficulties exist which prevent the
specification of the "types" of these parameters?
What about the notion of "return values"? For example Plot3D returns a
SurfaceGraphics object, but the documentation resulting from
Information[Plot3D] does not mention that. Why?
Steven
- References:
- Re: Re: Re: Types in Mathematica
- From: "Virgilio, Vincent - SSD" <Vincent.Virgilio@itt.com>
- Re: Re: Types in Mathematica
- From: "Steven T. Hatton" <hattons@globalsymmetry.com>
- Re: Re: Re: Types in Mathematica