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.
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion