Subject: Discussion about arrays and matrices in Maxima
From: Robert Dodier
Date: Mon, 18 May 2009 22:29:19 -0600
On 5/18/09, ?iga Lenar?i? <ziga.lenarcic at gmail.com> wrote:
> So from my experience - it's hard to improve something in Maxima,
Keep in mind that you are always free to maintain and distribute
your own Maxima packages (or even your own entire fork).
That might be a good way to publicize and refine your proposals.
I don't mean to be difficult --- I'm generally sympathetic to your
proposals. Bear in mind that the wheel of Maxima grinds slowly,
but exceedlingly fine.
> *) Matrices should internally represented as n-dimensional lisp
> arrays.
I agree that a matrix should use a Lisp array for storage, but
I'm inclined to use a 1-d array, since it makes some restructuring
operations (e.g. transpose, row/column extraction) simpler.
I can't tell if the translated Fortran code wants 1-d or 2-d arrays.
Fortran would be happy with 1-d, but there seems to be some
code to present 1-d as 2-d or vice versa, I'm not sure what's
going on.
> *) Matrices should support advanced indexing possibilities, both for
> retrieval of values and assigment (symetric). A good start is
> 'amatrix' package. I would like to improve upon Maxima list indexing
> also to support things like my_list[[1,3,4]]. In general Maxima lists
> and Maxima matrices/arrays should try to behave in the same way if
> possible - this makes for easier learning of Maxima.
Agreed.
> *) Lisp arrays for holding matrix elements should be of general type
> for general matrices containing Maxima expressions, but perhaps we
> could think about a special case of 'double-float cases, where a
> matrix would internally represented by a 'double-float array. I'm
> mentioning this, because I wish for faster floating point performance
> in Maxima.
Agreed.
> *) Entering matrices would probably be implemented as it is now -
> with matrix function.
No opinion on this point.
> *) Make matrices/arrays good citizens of Maxima: besides indexing and
> assigment, also functions like 'map' could be defined to work on both
> (elementwise for lists and arrays). If it is possible for a function
> to work on lists and arrays in somewhat the same way, it should be
> implemented. If it is not - two functions should be written and named
> approprietly, for instance:
> makelist()
> makematrix()
I think I'm in agreement on these points.
> *) The only place a word 'array' should be mentioned in Maxima
> documentation is where implementation of matrices is explained,
> ideally (if current array facilities are some day removed). I think
> matrix (in Maxima language) is a suitable word for an array(its
> meaning in computer science).
I'm not so sure about this. A matrix is an algebraic object, right?
while an array is just a storage container. I think confounding
fundamentally different kinds of objects for the sake of convenience
is a poor choice. (Incidentally I'm also opposed to treating lists
as synonymous with vectors --- they have different algebraic
properties.)
A hash table is called an undeclared array in Maxima; I think that's
an unfortunate choice of words. I'd rather just call them hash tables
(and implement them with Lisp hash tables).
Another tangential point --- Maxima distinguishes arrays which are
values from arrays which are properties. I'm inclined to preserve
that distinction.
Thanks for bringing up the topic. Perhaps in the near future
(i.e. less than 1 year) we'll really get rolling on it.
best
Robert Dodier