Search All of the Math Forum:

Views expressed in these public forums are not endorsed by NCTM or The Math Forum.

Notice: We are no longer accepting new posts, but the forums will continue to be readable.

Topic: Mathematica and Lisp
Replies: 83   Last Post: Mar 5, 2013 10:12 PM

 Search Thread: Advanced Search

 Messages: [ Previous | Next ]
 Richard Fateman Posts: 1,539 Registered: 12/7/04
Re: Mathematica and Lisp
Posted: Feb 26, 2013 1:09 AM
 Plain Text Reply

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 math-familiar 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
fullform-like 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 2-d display, it is more complicated but the effect --
which is to get the moral equivalent of the fullform underneath
the 2-d 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 non-commutative (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 hodge-podge 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

>

Date Subject Author
1/11/13 amzoti
1/12/13 Richard Fateman
1/12/13 David Bailey
1/14/13 Richard Fateman
1/14/13 David Bailey
1/16/13 Richard Fateman
1/18/13 David Bailey
1/22/13 Richard Fateman
1/22/13 David Bailey
1/24/13 Richard Fateman
1/25/13 Richard Fateman
1/26/13 Murray Eisenberg
1/26/13 Murray Eisenberg
1/26/13 W. Craig Carter
1/16/13 Murray Eisenberg
1/16/13 Richard Fateman
1/16/13 David Bailey
1/18/13 Murray Eisenberg
1/31/13 Noqsi
2/2/13 Daniel Lichtblau
2/3/13 Richard Fateman
2/2/13 Richard Fateman
2/3/13 David Bailey
2/5/13 Richard Fateman
2/6/13 David Bailey
2/6/13 Richard Fateman
2/3/13 Andrzej Kozlowski
2/5/13 Richard Fateman
2/6/13 David Bailey
2/8/13 Dave Snead
2/5/13 Bill Rowe
2/6/13 Joseph Gwinn
2/3/13 Matthias Bode
2/3/13 Noqsi
2/6/13 Richard Fateman
2/6/13 David Bailey
2/6/13 mathgroup
2/4/13 Alex Krasnov
2/6/13 Noqsi
2/8/13 Richard Fateman
2/9/13 János Löbb
2/9/13 Richard Fateman
2/10/13 michael
2/10/13 Bill Rowe
2/8/13 Andrzej Kozlowski
2/8/13 Noqsi
2/9/13 Richard Fateman
2/10/13 David Bailey
2/9/13 Matthias Bode
2/15/13 Noqsi
2/17/13 David Bailey
2/18/13 Joseph Gwinn
2/18/13 David Park
2/22/13 Richard Fateman
2/23/13 David Bailey
2/23/13 Richard Fateman
2/25/13 David Bailey
2/26/13 Richard Fateman
2/27/13 Bill Rowe
2/27/13 Richard Fateman
3/2/13 Bill Rowe
3/3/13 Richard Fateman
3/3/13 Noqsi
3/5/13 Richard Fateman
3/5/13 Vince Virgilio
3/3/13 Bob Hanlon
1/16/13 Noqsi
1/16/13 Richard Fateman
1/18/13 Noqsi
2/23/13 Dr. Peter Klamser
2/25/13 Richard Fateman
2/26/13 Noqsi

© The Math Forum at NCTM 1994-2018. All Rights Reserved.