
Re: Mathematica and Lisp
Posted:
Feb 26, 2013 1:09 AM


On 2/24/2013 11:19 PM, David Bailey wrote: > On 24/02/2013 04:31, Richard Fateman wrote: > >> It means that for many people the misconceptions that they have about >> precedences are never revealed to them because they don't use FullForm, >> and their programs are buggy. There are hosts of arbitrary precedences >> among // /. /; _ _? .... that ordinary mathematics does not have, so >> the ordinary mathfamiliar occasional programmer has no solid clue. >> For example, do you know offhand if Pi x // Sin is Sin[Pi*x] or >> Pi*Sin[x] ? Do you realize that if you type Sin Pi x you see as a >> result, Pi Sin x. so it seems that Mathematica believes sin(pi*x) = >> pi*sin(x). >> > > I think anyone with some Mathematica experience uses a selection of > operators, such as /. etc. and spells out other things longhand. For > example, I always write Map rather than use the /@ operator. On the > other hand, I use the // operator a lot, so I was able to answer your test.
And for people without much Mathematica experience, or who are not adventuresome and just use the syntax they learned in a math class and maybe from Pascal or C, these things will remain mysterious indefinitely.
> >> >> How do you know this? Do you have a survey? Just curious how you can say >> this. > Well, I have seen a fair bit of beginner Mathematica code, both from my > consultancy and from answering questions on this forum. Practically > nobody presents their code in full FullForm! For example, hardly anyone > would spell out CompoundExpression rather than use a semicolon.
This is true. But we also have lots of examples of people misunderstanding the code they have written that would have been clear had they simply used FullForm. I think we have no idea how many people make mistakes in syntax in the real world. I do have some idea of how many people misunderstood how to type sin(x) from what was typed in to a website I maintained that did integral table lookup and allowed Mathematica syntax. About 30% got that, or something like it, wrong.
> > Suppose that FullForm were the only acceptable input to Mathematica  > which you would appear to advocate.
Not really. I am advocating the simplicity and reliability of a fullformlike programming language  especially for programming and control structure. The "data" language for math expressions could be the same, but could also be infix if there was a lot of such math.
Would you want FullForm output also? For programs, yes. For math expressions, I think experience has been that people (myself included) prefer something like MathJax, (2d typeset stuff) or options for linear strings. Other options include fullform and even spoken stuff. It is perfectly clear that something like fullform for expressions is a key to understanding some 'features' of Mathematica that figure prominently in the list of bug reports.
> That would result in some pretty ugly maths, so perhaps you would relent > at this point, but part of the convenience of Mathematica is that you > can paste bits of output back into other input!
This is a feature that is available in many ways. select a subexpression and get the underlying representation, and paste it somewhere else. This is especially simple if the output is fullform, in which case the selection can be done in an ordinary text editor. If it is done in some 2d display, it is more complicated but the effect  which is to get the moral equivalent of the fullform underneath the 2d display, is the same.
> > Program bugs are often to be found in obscure bits of code that are hard > to read. Formulae are obviously far easier to read if they are not > written in FullForm (or Lisp!).
If you have looked at formulas published in historic books of integrals you will find that they are sometimes hard to read because of ambiguous or even incorrect syntax that is disambiguated only because the reader KNOWS that an integration formula could only be one of the possible choices. Actually in some cases I've simply had to test the formula by some other means (e.g. integration or differentiation) to figure out the formula in the book.
The point is, complicated or poorly typeset or "old" formulas are not the pure crystalline beauty that you might like to believe. For an easy example, look at the crap turned in by calculus students.
> > I would concede that it might be a good idea if certain built in symbols > such as Sin had a new attribute such as NonAlgebraic that forbade their > use in expressions like Sin Pi x.
There is a format in Mathematica called TraditionalForm, or something like that. I have never used it. > > The real truth is that conventional written maths is hopelessly > ambiguous without context.
Ah yes.
That is why you can come up with expressions > like Sin x  or indeed f(x). Likewise hardly any maths/physics paper > would spell out those multiplications that were noncommutative (e.g. by > using a special operator)  the reader is just meant to figure it out.
It is not even that simple. Sometimes the same notation is used to mean different things in the same paper. Look for the phrase "by abuse of notation".
> Thus every CAS has to resolve those ambiguities one way or another. I'd > say Stephen Wolfram's design is about as good as you can get  and > certainly better than Lisp!
Well, I guess I disagree with respect to (a) the programming language, which is, around the edges, is a hodgepodge of peculiar syntax and semantics, easily and frequently demonstrated. and also (b) the mathematical/data/numerical expression language, which requires [], and makes up its own incompatible definitions of atan2, list, etc.
This particular thread was mostly about (a). As you say, for an experienced programmer who either knows how to keep away from the hairy edges of the Mathematica language, or knows how to use them and uses them with relish, there is less of a problem than with the naive, or the unskilled/ careless/unfortunate. Unfortunately, most programmers are not so skilled as they think they are. Like the 80% of automobile drivers who consider themselves "above average".
RJF
>

