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: Work on Basic Mathematica Stephen!
Replies: 81   Last Post: Jun 4, 2013 5:59 AM

 Messages: [ Previous | Next ]
 David Bailey Posts: 714 Registered: 11/7/08
Re: Warsaw Univ. course, was Re: Work on Basic Mathematica Stephen!
Posted: May 31, 2013 3:19 AM

On 28/05/2013 08:49, Richard Fateman wrote:
>
> I do not see any connection here. It is possible to write a linked list
> in Mathematica and still use its evaluation. e.g.
> consider using node[element,RestOfList]. Instead of [A,B,C] use
> node[A,node[B,node[C,Nil]]]. A node here is like a lisp "cons" cell.
> In fact there are other computer algebra systems written in lisp that
> use lisp lists and have similar evaluation strategies to Mathematica.
>

Yes you could, and you might find it instructive to do this, because you
would then see exactly why Stephen Wolfram chose to implement lists in a
different way!

Try using your implementation to implement some 1000 x 1000 matrix algebra!

OK - perhaps you wouldn't want to use your new list implementation for
linear algebra, but in that case, where would you want to use it? Lisp
lists are expensive to use unless the algorithm is tailored to generate
lists in reverse order, and consume them in forward order (OK you can
reverse a Lisp list, but that consumes space for a copy, but random
access is still inefficient).

Since the Lisp language was designed very early on, I would imagine its
list structure reflects the tiny memory spaces available at that time.
Garbage collection of varying sized objects is more complex and tends to
need some slack memory.

The decision to implement lists the Mathematica way, has been amply
vindicated in recent years. Because the mechanisms supplied to access
lists are not skewed towards sequential access, it has been possible to
produce packed arrays (and indeed sparse arrays) that work as drop in
replacements for the equivalent list structures - with enormous
performance gains.

Mathematica also gains from the decision to make lists mutable - again
this simplifies the design of algorithms and increases performance.

Clearly Mathematica lists also score in they must help internally to
avoid repeated evaluation. Clearly Mathematica must store some
information in the head of every object to keep track of objects that
need reevaluation, and you wouldn't want each list node to be bloated
out in that way.

Yes you could implement Lisp-style lists in Mathematica, and with a bit
more effort, you could also supply them with a nice syntax for
input/output, so try it and see how many people find them useful!

David Bailey
http://www.dbaileyconsultancy.co.uk

Date Subject Author
5/12/13 David Park
5/14/13 Nasser Abbasi
5/15/13 szhorvat@gmail.com
5/16/13 szhorvat@gmail.com
5/16/13 Dr. Peter Klamser
5/17/13 Andrzej Kozlowski
5/17/13 Murray Eisenberg
5/17/13 Dr. Peter Klamser
5/18/13 Dr. Peter Klamser
5/19/13 Murray Eisenberg
5/19/13 paulmchale7@gmail.com
5/19/13 paulmchale7@gmail.com
5/23/13 szhorvat@gmail.com
5/24/13 David Park
5/20/13 Ingolf Dahl
5/20/13 David Annetts
5/22/13 mathgroup
5/23/13 Richard Fateman
5/24/13 W. Craig Carter
5/23/13 David Park
5/23/13 mathgroup
5/24/13 Richard Fateman
5/25/13 David Park
5/25/13 Richard Fateman
5/25/13 David Park
5/28/13 Alexei Boulbitch
5/28/13 Alexei Boulbitch
6/4/13 Bill Rowe
5/24/13 David Park
5/27/13 Noqsi
5/28/13 Richard Fateman
5/31/13 David Bailey
6/1/13 Richard Fateman
6/2/13 David Bailey
6/3/13 Richard Fateman
6/3/13 David Bailey
6/4/13 Andrzej Kozlowski
5/29/13 fd
5/30/13 Noqsi
5/31/13 Richard Fateman
5/31/13 Kevin J. McCann
5/31/13 Andrzej Kozlowski
6/1/13 Richard Fateman
6/1/13 Richard Fateman
6/2/13 Andrzej Kozlowski
6/3/13 Richard Fateman
6/3/13 Andrzej Kozlowski
6/1/13 Daniel Lichtblau
6/2/13 Richard Fateman
6/2/13 James Stein
6/3/13 waku
6/3/13 Daniel Lichtblau
5/27/13 Noqsi
6/2/13 David Bailey
5/28/13 fd
5/31/13 David Bailey
5/28/13 fd
6/2/13 Mark McClure
6/3/13 Richard Fateman
6/3/13 Joseph Gwinn
6/3/13 lshifr@gmail.com
6/3/13 lshifr@gmail.com