[Numpy-discussion] What's wrong with matrices?

[Bill Baxter]

On 7/8/06, Travis Oliphant <oliphant.travis at ieee.org> wrote:
>
> > Okay, here are a few that come to mind.
> > 1) Functions that take a matrix but return an array.  Maybe these are
> > all fixed now.  But they better be fixed not just in numpy but in
> > scipy too.  To me this implies there needs to be some standard idiom
> > for how to write a generic array-protocol-using function so that you
> > don't have to think about it.
>
> A lot of these are fixed.  The mechanism for handling this is in-place:
> either using asanyarray in the function or (more generally) using a
> decorator that wraps the arguments with asarray and returns the output
> with __array_wrap__.


That sounds good.  Is there a description of what that does and how to use
it anywhere you could point me to?

> 5) I've got squeezes like crazy all over my matrix-using code.  Maybe
> > this was a bug in 0.9.5 or so that's been fixed?  I do seem to recall
> > some problem with indexing or c_ or something that was causing
> > matrices to grow extra levels of length 1 axes.  Again, like the
> > scalar*matrix bug, things like that shouldn't happen.
> Sure, but it's going to happen in a beta release...  That's why we need
> testers.   As I recall, most bugs with matrices have been fixed fairly
> quickly as soon as they are reported.


What do you mean by "beta release"?  Are the odds considered betas and evens
releases?  Or do you mean just everything prior to 1.0 is actually beta?  I
haven't seen anything actually labeled as "beta" yet.

And yes, you've done a fantastic job fixing bugs quickly, and getting
releases out in a pretty timely manner too.  Many thanks for that.

>
> > 6) No good way to do elementwise operations?  Sometimes you just want
> > to do an elementwise mult or divide or exponentiation.  I guess you're
> > supposed to do  Z = asmatrix(X.A * Y.A).  Yah, right.
> This is a problem with a dearth of infix operators.   In fact, if we had
> a good way to write matrix multiplication as an infix operator, perhaps
> there wouldn't be any need for matrices.


Actually I was more after what you mentioned later -- the multiply(a,b)
function.  I see they're all there -- multiply, divide, power.  That's all I
wanted, because I know the Python operator overload situation doesn't really
allow more than that.

> ...So I'd like matrices to be able to have ndim>2.
> I suppose this restriction could be lifted.


I think that would be an improvement for people who want to use matrix as
their only ndarray data type.

>     b) On the other end, I think ndim<2 is useful sometimes too.  Take
> > a function like mean(), for example.  With no arguments  the return
> > value is a 1x1 matrix (as opposed to a scalar).
> Have you checked lately.  It's a scalar now...  This has been fixed.


Nope, haven't checked more recently than the latest release. I'm in the
process of trying to build numpy, though.

> Or take indexing.  It seems odd to me that where() reurns a tuple of
> > shape==(1,N) objects instead of just (N,) .




The way to fix some of these is to return arrays for indexing instead of
> allowing matrices.    But, matrices that are less than 2-d just don't
> make sense.


I guess not.  Looking at what matlab does more closely I see that it does
report size (1,1) for all scalars, and either 1,N or N,1 for all vectors.
It just hides it better.  Namely when printing you don't get as many
superfluous brackets (in fact matlab doesn't print any brackets).

> Maybe I can get over that though, as long as it works for indexing
> > (which it seems it does).   But I think the scalar return case is a
> > real issue.  Here's another: sum().  For an array you can do
> > sum(sum(a)) and get a scalar if a is 2-d, but for matrix sum(sum(m))
> > is the same as sum(m).   And along these lines, m[newaxis] just
> > silently doesn't do anything.  That doesn't seem right.
>
> These are just semantic questions.   It's no surprise that sum(sum(m))
> returns the same as sum(m) for a matrix because summing over the same
> axis won't change the result.   You have to sum over both axes in a
> matrix.


Right, it is perfectly logical given how sum is implemented.    I guess I'm
just used to Matlab's way which acts more like sum on arrays.   But maybe
numpy's way is ok too.

--bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20060708/5fce6190/attachment-0001.html>