[Numpy-discussion] deprecate numpy.matrix
matthew.brett at gmail.com
Mon Feb 10 16:57:10 EST 2014
On Mon, Feb 10, 2014 at 1:52 PM, Charles R Harris
<charlesr.harris at gmail.com> wrote:
> On Mon, Feb 10, 2014 at 2:28 PM, Pauli Virtanen <pav at iki.fi> wrote:
>> 10.02.2014 23:13, Alan G Isaac kirjoitti:
>> > On 2/10/2014 4:03 PM, Pauli Virtanen wrote:
>> >> What sparked this discussion (on Github) is that it is not
>> >> possible to write duck-typed code that works correctly for:
>> > Do you mean one must start out with an 'asarray'? Or more than
>> > that?
>> Starting with asarray won't work: sparse matrices are not subclasses
>> of ndarray. Matrix-free linear operators are not such either.
>> In Python code, you usually very seldom coerce your inputs to a
>> specific type. The situation here is a bit as if there were two
>> different stream object types in Python, and their .write() methods
>> did completely different things, so that code doing I/O would need to
>> always be careful with which type of a stream was in question.
>> > As I detailed in past discussion, the one thing I really do not
>> > like about the `matrix` design is that indexing always returns a
>> > matrix. I speculate this is the primary problem you're running
>> > into?
>> The fact that reductions to 1D return 2D objects is also a problem,
>> but the matrix multiplication vs. elementwise multiplication and
>> division is also an issue.
> Is there a need for every package in numpy/scipy to support matrices? I can
> see leaving in the Matrix object for basic teaching/linear algebra, but
> perhaps it would be reasonable for more advanced applications to forgo
> support. That would fall into the class of not going out of the way to
> accommodate subclasses of ndarray that override methods. I support that
> approach in the long run because trying to keep all subclasses happy is
> extra effort that could be better spent elsewhere.
Yes, I bet there is a solution in that direction that everyone could live with.
Alex - yes - I think it would be hugely useful to write up this
discussion as a wiki page or a NEP or a wiki page that might become a
NEP. It seems to me there is a great deal of agreement here which
could fruitfully be recorded.
More information about the NumPy-Discussion