> How can I learn the differences/relationships between lists, arrays,
> and matrices?
Sigh. Our documentation is a problem, isn't it?
Well, first of all, I would avoid arrays, both the named arrays
generated by array(...) and the anonymous arrays generated by
make_array(...). Those are I suppose useful for efficiency in handly
large numeric calculations, but for most applications, I'd stick to
lists, matrices, and associative arrays (hash-arrays). It is true
that they have O(n), not O(1), access time, but if you are doing
symbolic calculations, that will probably not matter, since symbolic
calculation in general is rather expensive. If you are doing large
numeric calculations with compiled Maxima code, it may well matter,
though.
Lists and matrices are first-class objects: they can be assigned to
variables, passed as arguments, returned as values, form part of a
larger object, etc. I would use them as much as possible.
Associative arrays in Maxima, alas, are not first-class objects. They
are attached to a particular symbol. I would like to change this, but
for now, that's the state of affairs. Associative arrays are useful
when you want to define a relationship between keys (not just small
integers) and values.
> I've read the documentation in pieces, and I never
> picked up the idea that if I define init[1], init[2], and init[3],
> maxima wouldn't realize that "init" meant the 3 vector.
The notation a[i] is used both for indexing in lists and for accessing
associative arrays. Though I suppose it is true that the
documentation never says that setting init[1] etc. creates a vector
named init, it never says that it does, either.... It is hard to
cover all the cases like this that *might* operate according to the
rules of other languages; for example, (current standard) Maxima does
not allow [a,b]:[2,3] (parallel assignment) or first(x):3 (accessors
functioning as setters on the LHS i.e. accessors having l-value
semantics) the way other languages do.
I think we're all aware that Maxima array/list/associative array
semantics are confusing, and we're thinking about how to improve them
(there has been discussion on the list).
-s