[Numpy-discussion] proposing a "beware of [as]matrix()" warning

David Warde-Farley dwf@cs.toronto....
Wed Apr 28 16:46:43 CDT 2010


On 2010-04-28, at 2:30 PM, Alan G Isaac wrote:

> Please let us not have this discussion all over again.

Agreed. See my preface to this discussion.

My main objection is that it's not easy to explain to a newcomer what the difference precisely is, how they interact, why two of them exist, how they are sort-of-compatible-but-not...

> The matrix class is very useful for teaching.
> In economics for example, the use of matrix algebra
> is widespread, while algebra with arrays that are
> not matrices is very rare.  I can (and do) use NumPy
> matrices even in undergraduate courses.

Would it be acceptable to retain the matrix class but not have it imported in the default namespace, and have to import e.g. numpy.matlib to get at them?

> If you do not like them, do not use them.

The problem isn't really with seasoned users of NumPy not liking them, but rather new users being confused by the presence of (what seems to be) two primitives, array and matrix.

Two things tend to happen:

a) Example code that expects arrays instead receives matrices. If these aren't "cast" with asarray(), mayhem ensues at the first sight of *.

b) Users of class matrix use a proper function correctly coerces input to ndarray, but returns an ndarray. Users are thus confused that, thinking of the function as a black box, putting matrices 'in' doesn't result in getting matrices 'out'. It doesn't take long to get the hang of if you really sit down and work it through, but it also "doesn't take long" to go back to MATLAB or whatever else. My interest is in having as few conceptual stumbling stones as possible.

c) Complicating the situation further, people try to use functions e.g. from scipy.optimize which expect a 1d array by passing in column or row matrices. Even when coerced to array, these have the wrong rank and you get unexpected results (you could argue that we should instead use asarray(..).squeeze() on all incoming arguments, but this may not generalize well).

> PS There is one change I would not mind: let
> A * M be undefined if A is an ndarray and
> M is a NumPy matrix.

What about the other binary ops? I would say, matrix goes with matrix, array with array, never the two shall meet unless you explicitly coerce. The ability to mix the two in a single expression does more harm than good, IMHO. 

David


More information about the NumPy-Discussion mailing list