Re: Mathematica and Lisp
- To: mathgroup at smc.vnet.net
- Subject: [mg129555] Re: Mathematica and Lisp
- From: David Bailey <dave at removedbailey.co.uk>
- Date: Tue, 22 Jan 2013 23:18:48 -0500 (EST)
- Delivered-to: l-mathgroup@mail-archive0.wolfram.com
- Delivered-to: l-mathgroup@wolfram.com
- Delivered-to: mathgroup-newout@smc.vnet.net
- Delivered-to: mathgroup-newsend@smc.vnet.net
- References: <kcqkv4$lq5$1@smc.vnet.net> <kct7fj$sgo$1@smc.vnet.net> <kd03ej$6dl$1@smc.vnet.net> <kd2ltk$cog$1@smc.vnet.net> <kd7tsg$q3s$1@smc.vnet.net> <kdanpt$3d5$1@smc.vnet.net> <kdlfp1$117$1@smc.vnet.net>
On 22/01/2013 07:40, Richard Fateman wrote: >> Well I'd imagine that engineers who simply want to perform a >> mathematical calculation - one that doesn't come straight out of the >> box, like an isolated integral - the Mathematica language is probably >> easier to use than LISP. > > Using Mathematica as a simple command language -- a front end to the > symbolic mathematics application program underneath -- is quite > different from using Mathematica as a language in which to build > significant new applications. I tried to describe exactly that situation in my original comment - one in which the user had to write a little code to get what he wants. > > Even so, you seem to forget the trouble new users have in typing > simple mathematics into Mathematica. The surprise when sin(x)/x > turns out to be sin. > This is true, but one way or another, they are going to face this with any computer algebra package because in CA variables can't be restricted to be single letters - there just aren't enough of them. I used to give an introduction to Mathematica, and I used to show examples like that early on, and motivate people by pointing out that ordinary math notation is actually ambiguous - e.g. f(x)/x - once they saw that, the extra rules of Mathematica made perfect sense. >>>> > > First of all, it would be (foo 1 2 3). No commas. > Yes - a typing error, but it probably also shows how long ago I gave up on LISP! > and that the language did live up >> to its name: Lots of Irritating Sets of Parentheses! Once it had to add >> other constructs that elegance was lost. > > Any experienced Lisp programmer these days will use an editor that keeps > track of both indentation and parentheses, and so the structure of a > program will be quite evident from the indentation. A programmer > will probably first notice the error in indentation and correct it by > adding or removing a parenthesis. It is an enormous boon to the > construction of programs with nested structure, such as if-then-else > conditionals, and mathematical expressions. In case you hadn't noticed, > the parenthesis structure for large deeply nested mathematical > expressions is difficult for humans to comprehend accurately; > fortunately the INPUT lines in Mathematica are generally short, while > the OUTPUTS are the complicated ones. > > The prefix vs. infix issue is also a red herring. If Lisp programmers > wanted to use infix they would use any of a number of free infix front > ends. They rarely do. Having 3 types of brackets, definitely helps to discern the structure, even with indentation. Perhaps LISP could have been improved by permitting all three, to be used interchangeably so long as they paired correctly. Unless the infix front end distinguished reliably between code and data (which I don't think it could, in general), you would still have a problem - ideally you want to see sin(a) but (apples oranges pears) Also, if you print out an expression, you want the first format, and if you print a list, you want the second. If you print a fragment of code, you may want to see a mixture of both styles. Extra types of brackets make all that simple. > > I rarely write programs of any length in Mathematica, because (as I've > said) I hold the programming language in generally low regard. > On the other hand I am pretty much familiar with the language because > I wrote a parser for it (in Lisp) some time ago, and in my experience > one of the best ways to really learn a language is to "implement" it. Did you implement it, or just parse it? I do agree about learning a language by implementing it. Two of us once wrote a Fortran compiler in Fortran (!!), and bootstrapped it. It was widely used on Prime computers. One of the things I discovered, was that the old issue about Fortran's context sensitive grammar, was an utterly trivial problem! > > I do find it an object of curiosity to see how some ideas are > expressed by the symbolic mathematical routines (e.g. integration). > And the Solve (and related, e.g. Reduce) programs have followed > an interesting path of improvement. > > It is also useful for finding high-precision values of numerical > library functions to compare to other programs, e.g. Bessel functions, > that I was experimenting with. Unfortunately for Mathematica, I found > bugs in > its Bessel function (reported and acknowledged by them). > Here's one in version 8 (I do not yet have version 9 installed) > q=429515858585961022071539/6922263581864661506963; > > a=N[BesselJ[0,q],45]; > b=N[BesselJ[0,q],100]; > c=N[BesselJ[0,q],45]; > > a==c > returns False. > > If I were using a computer to do something that required correct answers > for, say, life safety, like building a bridge, I would follow WRI's > advice and not use Mathematica. > (see http://www.wolframalpha.com/termsofuse/) So have you found the perfect language - one in which none of the functions contain imperfections, and yet which offers anything approaching the computational sophistication of Mathematica? BTW, I wouldn't be surprised if a lot of safety critical code isn't written in Fortran! David Bailey http://www.dbaileyconsultancy.co.uk