[SciPy-user] change in matrix behavior

Nathan Bell wnbell at gmail.com
Thu May 8 16:32:26 EDT 2008


On Thu, May 8, 2008 at 2:57 PM, Anne Archibald
<peridot.faceted at gmail.com> wrote:
>
> Well, the primary (only?) reason for matrices to exist is the
> multiplication operator. That was unaffected by the current change. I
> would say that most of the people in the discussion thought that
> matrices should behave as much like arrays as possible, with the sole
> difference being the * and ** operators.

IIRC matrices also have attributes for inverses and overload \ for
solving linear system.

If matrix indexing is to be changed I don't know why we don't go the
extra mile and deprecate matrices?  They really don't serve much
purpose and complicate life for both new and experienced users (albeit
in different ways).

> Of course, I use arrays instead of matrices, so I'm not particularly
> aware of any more subtle conveniences they offer.

Aside from supporting them in in scipy.sparse (e.g. A*x -> y, where x
and y are matrices) I don't use matrices either.

> Perhaps you could
> contribute some use cases that demonstrate the utility of the very
> surprising old scalar indexing behaviour?

You misunderstand.  I don't claim to make a case that the old scalar
indexing was the correct/proper/intuitive.  On the contrary, as many
have pointed out it leads to rather unexpected behavior in some cases.
 OTOH the proposed "fix" introduces its own problem (A[1] is now an
array rather than a matrix) and breaks backwards-compatibility.

It's unprofessional to break backwards compatibility unless you have a
 *really good reason* and you are confident that the new method is
*the right way to do it*.  IMO the proposed changes don't meet either
of these standards.

Again, why don't we deprecate numpy.matrix?  Clearly no one here uses
it and it is a major pain to handle correctly in SciPy.

-- 
Nathan Bell wnbell at gmail.com
http://graphics.cs.uiuc.edu/~wnbell/



More information about the SciPy-User mailing list