[Numpy-discussion] deprecate numpy.matrix
Alan G Isaac
alan.isaac at gmail.com
Mon Feb 10 21:23:12 EST 2014
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
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.
More information about the NumPy-Discussion