[Numpy-discussion] Uncomfortable with matrix change

Charles R Harris charlesr.harris@gmail....
Fri May 9 13:44:14 CDT 2008

On Fri, May 9, 2008 at 10:06 AM, Charles R Harris <charlesr.harris@gmail.com>

> On Fri, May 9, 2008 at 9:56 AM, Jonathan Wright <wright@esrf.fr> wrote:
>> Timothy Hochberg wrote:
>> > +0
>> >
>> > My personal opinion is that current matrix class is pretty useless and
>> > the change won't help much from my point of view. My preference would
>> > be to leave the matrix class alone, design a new matrix class, with a
>> > different name, for 1.2 and then deprecate the old matrix class
>> +1
> The problem here is the workarounds in the numpy code, which we would have
> to maintain. I am against messing with the numpy code just to accommodate a
> matrix class that shouldn't have inherited from ndarray in the first place.
> So I am OK with backing out the changes as long as we also leave all the
> bugs in place.

So to start a different line here, what properties *should* a base class
have? I would posit that the scalar types,  strided memory,  ufuncs, and
broadcasting would be the fundamental properties. The strided memory and
ufuncs, and perhaps broadcasting, probably can't be directly used by sparse
arrays, so this may be too general already. Things like constructors (array,
matrix), display (print), and operator choices (+,-,*, indexing), should
not. The problem with operators is that we want Python to do the parsing and
want to use sequences and such. One possibility here is to provide separate
functions with different names to replace PySequence_GetItem and
PySequence_Length internally in numpy, that is, we no longer consider arrays
as nested Python sequences. Instead, we provide a standalone function to
translate nested sequences to arrays, which is pretty much what we have now.
So we don't just special case matrices, we special case arrays in general
and only use PySequence_GetItem internally for genuine Python sequences.
>From this common base we can then derive ndarray which defines __getitem__
to use the new functions and can also derive matrices which define
__getitem__ differently.

I'm just thinking out loud here where folks might notice to start a
different thread. This doesn't solve the problem of what matrices should be,
but it does remove the problem of decreasing dimensions.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20080509/8027a6fa/attachment-0001.html 

More information about the Numpy-discussion mailing list