On 2/10/2014 7:39 PM, Pauli Virtanen wrote: > The issue here is semantics for basic linear algebra operations, such as > matrix multiplication, that work for different matrix objects, including > ndarrays.
I'll see if I can restate my suggestion in another way, because I do not feel you are responding to it. (I might be wrong.) What is a duck? If you ask it to quack, it quacks. OK, but what is it to quack? Here, quacking is behaving like an ndarray (in your view, as I understand it) when asked. But how do we ask? Your view (if I understand) is we ask via the operations supported by ndarrays. But maybe that is the wrong way for the library to ask this question. If so, then scipy libraries could ask an object to behave like an an ndarray by calling, e.g., __asarray__ on it. It becomes the responsibility of the object to return something appropriate when __asarray__ is called. Objects that know how to do this will provide __asarray__ and respond appropriately. Other types can be coerced if that is the documented behavior (e.g., lists). The libraries will then be written for a single type of behavior. What it means to "quack" is pretty easily documented, and a matrix object already knows how (e.g., m.A). Presumably in this scenario __asarray__ would return an object that behaves like an ndarray and a converter for turning the final result into the desired object type (e.g., into a `matrix` if necessary). Hope that clearer, even if it proves a terrible idea. Alan Isaac _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
