[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