[Numpy-discussion] deprecate numpy.matrix
Charles R Harris
charlesr.harris at gmail.com
Mon Feb 10 20:45:36 EST 2014
On Mon, Feb 10, 2014 at 6:11 PM, Charles R Harris <charlesr.harris at gmail.com
> On Mon, Feb 10, 2014 at 5:39 PM, Pauli Virtanen <pav at iki.fi> wrote:
>> 11.02.2014 01:39, josef.pktd at gmail.com kirjoitti:
>> > Almost all the code in scipy.stats and statsmodels starts with
>> > The numpy doc standard has the term `array_like` to indicate things that
>> > can be converted to a usable object by ndasarray.
>> > ducktyping could be restricted to a very narrow category of ducks.
>> > What about masked arrays and structured dtypes?
>> > Because we cannot usefully convert them by asarray, we have to tell
>> > that they don't work with a function.
>> > Our ducks that quack in the wrong way.?
>> The issue here is semantics for basic linear algebra operations, such as
>> matrix multiplication, that work for different matrix objects, including
>> What is there now in scipy.sparse is influenced by np.matrix, and this
>> is proving to be sub-optimal, as it is incompatible with ndarrays.
>> > How do you handle list and other array_likes in sparse?
>> if isinstance(t, (list, tuple)): asarray(...)
>> Sure, np.matrix can be dealt with as an input too.
>> But as said, I'm not arguing so much about asarray'in np.matrices as
>> input, but the fact that agreement on the meaning of "*" in linear
>> algebra code in Python is muddled. This should be fixed, and deprecating
>> np.matrix would point the way.
>> (I also suspect that this argument has been raised before, but as long
>> as there's no canonical write-up...)
> This would require deprecating current sparse as well, no?
> I could be convinced to follow this route if there were a pedagogic
> version of a matrix type that was restricted to linear algebra available as
> a separate project. It could even have some improvements, row and column
> vectors, inv, etc, but would not be as full featured as numpy arrays. The
> idea is that it would serve for teaching matrices rather than numerical
> programming in python. Hopefully that would satisfy Alan's teaching use
> case. There is the danger of students getting tied to that restricted
> implementation, but that may not be something to worry about for the sort
> of students Alan is talking about.
Another possibility is to provide an infix matrix multiplication operator.
from sage.misc.decorators import infix_operator
v=vector([5,4,3])print(u *dot* v)# => 22
return x*yprint(2 |plus| 4)# => 6
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion