Hi, On Mon, Feb 10, 2014 at 1:52 PM, Charles R Harris <charlesr.har...@gmail.com> wrote: > > > > On Mon, Feb 10, 2014 at 2:28 PM, Pauli Virtanen <p...@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. Cheers, Matthew _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion