[PYTHON MATRIX-SIG] Are we talking about one thing or two?

[Jim Fulton, U.S. Geological Survey]

On Wed, 13 Sep 1995 16:47:19 -0400 
Chris Chase S1A said:
> >>>>> "Dave" == Dave Forrest <forrest@rose.rsoc.rockwell.com> writes:
> 
> Dave> Rather than trying to make a one-size-fits all that isn't exactly what
> Dave> anyone wants, why not make two interfaces (maybe one implementation?)
> Dave> that give each camp what they want to work with?
> 
> By two interfaces do you mean having different meanings for an
> operator such as "*" depending on the arguments classes?
> 
> I think it would be too confusing to have an operation "A*B" that
> performs matrix multiplication when A and B are matrices (two
> dimensional arrays) but performs elementwise multiplication for the
> a general class of arrays (whatever you want to call them - arrays,
> tensors, tables - I prefer arrays).

Hm.  Well this is what happens now with numbers.  Math on integers is
different from math on numbers.
 
> I think that supporting the Matlab-like matrix linear algebra such as
> matrix multiplication and matrix division is a high priority for many
> people.  One question is can the new operators be added to the
> language without difficulty, in a logical fashion, and without
> cluttering the language with operators that are only used for this
> "matrix" class?
> 
> 
> The Matlab approach uses 
> 
> "+", "-", ".*", "./" ".^"  for elementwise operations (called array
> operations in Matlab. I call them vector operations.) 
> 
> "*", "/", "\", "^" for matrix operations.  ("^" is a Matrix power operator).
> 
> Python is much more general than a matrix language, so I think that
> using all of these would give Python operator bloat.
> 
> Is adding new operators to the language even a possibility?

I'm 99% sure that the answer is no.  

I think that we should try to keep this proposal to things that can be
implemented with a new module withion the bounds of the existing
language.

 
> New methods or functions would have to be defined anyway to implement
> the operators, e.g. matrixmultiply(a,b), vectormultiply(a,b),
> leftdivision(a,b), etc.  Without operators that call these functions we
> would probably want shorter names.
> 
> >> 
> >> Why?  For practical reasons.  We here - and I would submit that many
> >> other organizations are like this - do more Matlab-like work.  The way
> >> Matlab defines a matrix is not a problem but a huge advantage for us.
> >> 
> >> But in what way would a more general concept be a disadvantage?
>      
> Dave> Easy - a more general concept might require me to worry about extra
> Dave> things that I'm not interested in (like the number of dimensions, or
> Dave> the "rank" that J uses).  These things are not interesting and can only
> Dave> cause problems by being there to make mistakes on.  We will end up
> Dave> writing a wrapper that gives us the interface we want and hides the
> Dave> things that we're not interested in - but since we're not the only ones
> Dave> who want this and it would be more efficiently done as an intrinsic
> Dave> part of the language I think that's the right thing to do.
> 
> Even if you limit yourself to only two dimensions you still have to
> worry about rank.  In Matlab you can make a mistake using
> one-dimensional vectors when a matrix is required.  Tela is a perfect
> example of a language that took the Matlab syntax and added higher
> dimensional arrays without breaking any of the basic Matlab matrix
> features.  IDL and APL are additional examples with higher dimensional
> arrays that don't limit their capability to do matrix linear algebra.
> Matlab is two-dimensional more because of its limited scope and
> computer resources from historical beginnings.  I even seem to recall
> being informed by Mathworks representatives at a tradeshow that higher
> dimensional arrays would be added in a future release to Matlab.
> 
> The natural implemenation would be a multi-dimensional array class as
> Jim is proposing with a matrix linear algebra module to specialize
> this class [for implementing matrix multiplication, matrix
> inverses/adjoints (square and non-square "matrix division") , linear
> equation solvers, column rank, factorization, spectral/eigenvalue
> computations, special matrices (diagonal, Hankel, toeplitz, Hilbert,
> sparse, etc.), norms, matrix exponential, and on and on].  This would
> easily be a whole additional SIG - the Matrix Linear Algebra (Matlab
> clone) SIG.  Such a SIG wouldn't have to implement another object type
> and external interface except for subclassing to special matrices
> (sparse in particular).
> 
> Is the purpose of this SIG only for implementing a two-dimensional
> matrix linear algebra system within Python or for implementing a more
> general purpose multi-dimensional array class with homogeneous
> elements for easy interface to external scientific and mathematical
> libraries?

The latter.

Jim

=================
MATRIX-SIG  - SIG on Matrix Math for Python

send messages to: matrix-sig@python.org
administrivia to: matrix-sig-request@python.org
=================