Services & Resources / Wolfram Forums
-----
 /
MathGroup Archive
2005
*January
*February
*March
*April
*May
*June
*July
*August
*September
*October
*November
*December
*Archive Index
*Ask about this page
*Print this page
*Give us feedback
*Sign up for the Wolfram Insider

MathGroup Archive 2005

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

Search the Archive

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


  • Prev by Date: Re: Re: Re: Types in Mathematica
  • Next by Date: Re: does this shut down anyone else's kernel?
  • Previous by thread: Re: Re: Re: Types in Mathematica
  • Next by thread: Re: Re: Types in Mathematica