Re: Mathematica and Lisp
- To: mathgroup at smc.vnet.net
- Subject: [mg129485] Re: Mathematica and Lisp
- From: Richard Fateman <fateman at cs.berkeley.edu>
- Date: Wed, 16 Jan 2013 23:17:13 -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>
On 1/14/2013 8:28 PM, David Bailey wrote:
> On 14/01/2013 05:01, Richard Fateman wrote:
>
>>
>> David has a point: to some extent Mathematica "does Lisp wrong". Lisp
>> has lists but also arrays and hashtables. Mathematica uses the term
>> List, but the implementation is as an array. Then there is a SparseArray
>> which is also not an array but a hashtable.
>
> Actually, I don't think sparse arrays are based on hash tables. You can
> see the internal structure of a SparaseArray object thus:
>
> s = SparseArray[{{1, 1} -> 1, {2, 2} -> 2, {3, 3} -> 3, {1, 3} -> 4}];
>
> s//InputForm
>
> SparseArray[Automatic, {3, 3}, 0, {1, {{0, 2, 3, 4}, {{1}, {3}, {2},
> {3}}}, {1, 4, 2, 3}}]
>
> The approach seems to be to index down one dimension, and then follow a
> list of entries for the other dimension. I am not sure what happens in
> the 1-dimensional case, but if you dump the structure out in the same
> way, it clearly isn't a hash table.
The point is that Mathematica is confusing to new users;
>
> Incidentally, this really is the internal structure of a sparse array -
> you can replace the head of a sparse array, manipulate the structure and
> reassemble a sparse array if necessary!
>
> Of course, It makes you wonder why sparse arrays do not use hash tables!
Maybe it will be in version 10. There is no way of telling from outside
the company.
>
> I am less convinced that LISP did get it right - they just got there
> first! Variants of LISP had to add arrays and hash tables to the basic
> language, which obviously traded language simplicity for performance on
> larger problems.
There is an ANSI Standard Common Lisp that has a range of features.
Arrays were in "early" Lisp at least by 1966. There were arrays in
Fortran and Algol before that, so Lisp wasn't first. If you want to
criticize languages by historical relics, you might note that Fortran
doesn't have subroutines. Oh, variants of Fortran added subroutines.
Mathematica seems to have kept its original design (at
> least in this area) over the years, even though internally, lists now
> come in two flavors!
Mathematica's internal design has apparently changed in many respects;
some WRI literature claims it's been entirely rewritten.
>
>
> I also like the way in which Mathematica does not force people to use
> functional programming.
Lisp does not force people to use functional programming. Here is a
Lisp program. (loop for i from 1 to 10 do (print i))
I find many situations in which functional
> programming gives no perceptible gain, and can render an algorithm more
> obscure.
I've not seen that be a problem for lisp programmers.
Perhaps that is because I learned Fortran as my first computer
> language :)
>
> I do tend to agree that teaching Mathematica as a first programming
> language, would be a bad idea, because so much happens behind the scene
> - for example the way in which multiple definitions for a function get
> reordered to improve efficiency. I would imagine that some students
> would get a hazy idea of what the were asking the computer to do, or how
> expensive it might be.
I think the issue is not only that it violates transparency, but that it
mis-uses terms, it can make a hash of comparing algorithms and data
structures for efficiency, it is expensive and proprietary, it has no
formal definition, and some things are done just out-and-out wrong from
the perspective of computer science and numerical analysis.
But other than that, eh..
>
> David Bailey
> http://www.dbaileyconsultancy.co.uk
>
>