[Numpy-discussion] untenable matrix behavior in SVN

[Charles R Harris]

On Tue, Apr 29, 2008 at 7:24 AM, Stéfan van der Walt <stefan at sun.ac.za>
wrote:

> Hi Charles
>
> 2008/4/29 Charles R Harris <charlesr.harris at gmail.com>:
> > May I add that if I edit defmatrix.py to act like an array for scalar
> > indexing, then the following works.
> >
> > In [1]: a = matrix(eye(2))
> >
> > In [2]: array([a,a])
> > Out[2]:
> > array([[[ 1.,  0.],
> >          [ 0.,  1.]],
> >
> >        [[ 1.,  0.],
> >         [ 0.,  1.]]])
> >
> > This generates an error with the current version of matrix and, frankly,
> I
> > am not going to be bothered going all through the numpy c sources to
> special
> > case matrices to fix that. Someone else can do it if they wish. There
> are
> > recursive routines that expect the dimensions to decrease on each call.
>
> I'd also like to see matrices become proper hierarchical containers --
> the question is just how to do that.  Thus far, I'm most convinced by
> the arguments for RowVectors/Columns, which leaves us with a sane
> model for doing linear algebra, while providing the enhancements you
> mentioned here and in comments to another ticket.
>
> We were thinking of raising a warning on scalar indexing for 1.1, but
> given the above, would that be sensical?
>

Hi Stefan,

The numpy c routines call PySequence_GetItem(s,i) as well as ask for the
length (first index), so I think these should be left as they are for arrays
in order to guarantee that matrices are compatible with all the normal array
operations. This means either returning special row objects that index as
expected, or returning 1D arrays. I don't think the '*' operator has these
problems, but in any case that is a well documented feature of matrices.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080429/ffd2a1f0/attachment.html>