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

Travis Oliphant oliphant@enthought....
Wed Apr 28 17:18:38 CDT 2010


On Apr 28, 2010, at 4:46 PM, David Warde-Farley wrote:

> 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.

This could be done in NumPy 2.0.      I'm +1 on not allowing a mix of  
the two.

-Travis




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/numpy-discussion/attachments/20100428/b8cb1ffb/attachment.html 


More information about the NumPy-Discussion mailing list