[PYTHON MATRIX-SIG] Re: Bug in matrixMultiply, and once more names

[James Hugunin]

   From: hinsenk@ERE.UMontreal.CA (Hinsen Konrad)
   Here's a bug (or two) that I just found:

   >>> from Numeric import *
   >>> x = array([1,2,3.])
   >>> add.reduce(x*x)
   14.0

I assume this isn't a bug.

   >>> x.matrixMultiply(x)
   array(14.0, 'd')

This is a bug all right.  The standing agreement is that all array
functions will return a python scalar instead of a 0d array.  Perhaps
you're right and this should only happen for returned arrays of type
long, double and double complex.  It's all in one function so this
would be an easy change, the final decision on the right thing to do
here depends critically on the decisions made regarding type
coercions.  I just forgot to call this function for matrixMultiply.

   >>> 2.*x.matrixMultiply(x)
   Segmentation fault

I'll fix this too. (once I figure it out)

   About names:

   >From the recent discussion I remember that there are supposed to be
   two array types: a low-level type "array" and a high-level type
   "Array". The latter may have become unnecessary now that "array"s have
   automatic coercion again. But should the remaining one be called
   "array" or "Array"? I don't really care, but certainly we should have
   either "array" and "matrix" or "Array" and "Matrix", not "array" and
   "Matrix" as it is now.

I actually rather like the way that things stand now.  Here's what we
have:

A low level type named array that is what I expect 90% of the people
who use this system to use.  This is entirely implemented in C.

A wrapper class called UserArray that provides a wrapper around this
new built-in array type.  The theory here is that so long as we don't
break any old code, we are free to ignore the old array type as
obsolete.

A subclass of UserArray called Matrix that implements matrixMultiply
instead of array multiply for the "*" operator.  This is mainly
provided for people who do entirely linear algebra work.  Personally I
think that using a.matrixMultiply(b) is a better solution for people
who want to work with both arrays and matrices.

   Also, I have some more objections against the name of the module
   UserArray. I don't like the "UserXxx" names at all (because they don't
   relate to the user any more than any other module), but that's not my
   point now. UserList is a Python class that is equivalent to the
   built-in list type, UserDict similarly wraps dictionaries.  So one
   should conclude that UserArray is an analogous wrapping of the old
   array type, but that is not true. The new arrays have different
   functionality, so they should have another name. One possibility would
   be "NumericArray", since the main new feature is numerical
   operations. On the other hand, there are no numerical operations on
   e.g. character arrays. Maybe someone else finds a better name.

To reiterate, UserArray is a wrapper class around the new C level
type of array.  There is a little bit of baggage in this wrapper
involved in the fact that arrays are a fairly complicated class.  In
fact, I was able to substitute UserArrays into Benchmark.py with
about 10 lines of code as a replacement for arrays, I used this for
testing the speed of the wrapper class.

   And now back to testing...

Keep those bugs coming!

-Jim

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

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