The Maxima computer algebra system

Stavros Macrakis | 30 Jun 2008 23:56

Re: Maxima: Syntax improvements

Costa,

Thanks for the suggestions.

> (1) Its a very good idea to incorporate Matlab syntax for matrix manipulations eg. a(1:4,[1 5 6]).

I assume that this denotes an array slice, which would certainly be
useful functionality for Maxima.  Robert Dodier's amatrix does
something like this (see
http://maxima.cvs.sourceforge.net/maxima/maxima/share/contrib/amatrix/)
but as far as I can tell it does not interoperate with any existing
Maxima matrix/array functionality, so in order to calculate
scalar-matrix products, determinants, inversion, eigenvalues, etc.
etc. you need to convert back to Maxima's standard representation.

On the other hand, the particular *syntax* you propose above is quite
different from, and incompatible with, Maxima syntax, which would be
a[1..4, [1,5,6]].  Though it would be nice to benefit from
compatibility with Matlab/Octave syntax, it would also be nice to
benefit from compatibility with Mathematica, R/S-plus, SAS, Python, K,
etc. but they are all mutually incompatible and preferred by different
communities! And your proposed syntax would break much existing code,
since ":" is the assignment operator and a() is function application
(not matrix/array subscripting).

Maxima's current array/matrix semantics are a mess, I must say, with
at least four different kinds of object (hasharrays, explicit lists,
explicit matrices, Lisp arrays) supporting subscripting with varying
semantics. We really need to work on this....

(Continue reading)

headers

Robert Dodier | 2 Jul 2008 04:32

Re: Maxima: Syntax improvements

On 6/30/08, Stavros Macrakis <macrakis <at> alum.mit.edu> wrote:

>  > (1) Its a very good idea to incorporate Matlab syntax for matrix manipulations eg. a(1:4,[1 5 6]).
>
>  I assume that this denotes an array slice, which would certainly be
>  useful functionality for Maxima.  Robert Dodier's amatrix does
>  something like this (see
>  http://maxima.cvs.sourceforge.net/maxima/maxima/share/contrib/amatrix/)

Yes, amatrix is essentially an experiment to get functionality
similar to Matlab's array slicing, but using Maxima notation
(i.e. without any changes to the Maxima parser).

>  but as far as I can tell it does not interoperate with any existing
>  Maxima matrix/array functionality, so in order to calculate
>  scalar-matrix products, determinants, inversion, eigenvalues, etc.
>  etc. you need to convert back to Maxima's standard representation.

Right, at present any code which assumes it knows the internal
structure of a matrix cannot work with amatrix. But code which
only accesses elements via indexing should not notice if the
matrix implementation has changed.

>  Maxima's current array/matrix semantics are a mess, I must say, with
>  at least four different kinds of object (hasharrays, explicit lists,
>  explicit matrices, Lisp arrays) supporting subscripting with varying
>  semantics. We really need to work on this....

Yes, I think revising the array/matrix stuff would be a very useful goal.
Not sure where to start. If someone has any kind of plan, I'm all ears.

(Continue reading)