On Thu, Jan 25, 2007 at 02:08:20PM -0500, Stavros Macrakis wrote:
> >I agree to some extent here... Maxima has confusing semantics with
> >regard to lists, matrices, arrays, subscripted variables, and soforth.
>
> Agreed. For the rest, I think this proposal is going in precisely the
> wrong direction, with multiple special-purpose mechanisms defined by a
> mixture of semantics and implementation matters. I have previously
> proposed a simpler system, which separates semantics and
> implementation cleanly. I will outline more details later.
Are we off list on purpose? I see this message in my private mail, but
not on the list. In any case, I was trying to get the ball rolling on
the discussion. So I'll try to clarify your questions.
> >To kick it off, I think maxima should have (at least) the following
> >types of things:
> >
> >1) lists, which are just like lisp lists, current maxima lists are fine
>
> >2) vectors, which have mathematical semantics and O(1) indexing.
>
> What exactly do you mean by "mathematical semantics"?
> Why are you requiring that semantics be aligned with performance
> characteristics?
Maxima is both a programming language, and a language for expressing
mathematics. It is computationally interesting to do things with
"arrays" which are conceptually different from mathematical
"vectors". That is, I might want to put various things into an ordered
structure with O(1) access time. However, I don't want to necessarily
have the notion of a transpose, or commutative addition, or whatever.
I don't have a hard and fast definition of "mathematical semantics"
but it should include some notions such as: vector addition, vector
inner product, multiplication by scalars, transpose. A vector should
probably conceptually be no different from a 1 column or 1 row matrix.
When it comes to mathematical vectors, the common and expected case is
to access them by indexing, and therefore it would be unacceptable to
have a vector which could not be indexed efficiently, even if we
provide an iterator type of access mechanism.
> >3) Arrays, which are like common lisp "vectors"
>
> What exactly are the properties you want?
an ordered structure that can contain any maxima data type with O(1)
access time which is suitable for writing computational code which
needs direct access to elements.
> >4) Hash tables, which are like common lisp hash tables but can be
> >accessed in a similar way to an array, except the index need not be an
> >integer.
>
> Why is this different from a list or an array?
Arrays are conceptually "ordered" that is indexed by integers, and
also indexable by an iterator scheme (ie a notion of a "next" element
or a "previous" element). A hash table is a representation of a
mapping from a key to a value. One could completely eliminate arrays
and only have hash tables, but I think there is an efficiency price to
pay that would be unacceptable when only integers are needed.
> >5) Numerical arrays, which are like common lisp arrays specialized to
> >double floats.
>
> This is an implementation matter. Are the semantics the same as
> arrays? If we later add quad-precision floats, is that a different
> type?
The goal here is to have specialization suitable for fast numerical
mathematical computation. I don't claim to have a comprehensive
suggestion as to how to get that, but I think it's essential. There
need not be a conceptually different type, but there should be a way
to get high performance by specialization.
> >6) Matrices, which should have mathematical semantics.
>
> What exactly do you want here? I assume you want to allow general
> values in each entry, not just numbers. If they entries happen to be
> double-floats, how does this relate to your "numeric arrays"?
Good questions. I don't have answers as yet.
> That is an implementation detail. I think what you intend is that the
> objects above be first-class objects, which can be assigned to
> variables, passed as arguments, etc.
Yes, this is what I intend. All storage types should be first-class
objects.
I'm glad to see the ball rolling on this issue.
--
Daniel Lakeland
dlakelan at street-artists.org
http://www.street-artists.org/~dlakelan