[Numpy-discussion] proposing a "beware of [as]matrix()" warning
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
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion