[Numpy-discussion] deprecate numpy.matrix

[Todd]

On Feb 11, 2014 3:23 AM, "Alan G Isaac" <alan.isaac at gmail.com> wrote:
>
> 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

I don't currently use the matrix class, but having taken many linear
algebra classes I can see the appeal, and if I end up teaching the subject
I think I would appreciate having it available.

On the other hand, I certainly can see the possibility for confusion, and I
don't think it is something that should be used unless someone has a really
good reason.

So I come out somewhere in the middle here.  So, although this may end up
being a terrible idea, I would like to purpose what I think is a
compromise: instead of just removing matrix, split it out into a scikit.
That way, it it's still available for those who need it, but will be less
likely to be used accidentally, and won't be interfering with the rest of
numpy and scipy development.

Specifically, I would split matrix into a scikit, while in the same release
deprecate np.matrix.  They can then exist in parallel for a few releases to
allow code to be ported away from it.

However, I would suggest that before the split, all linear algebra routines
should be available as functions or methods in numpy proper.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140211/bfdafb2e/attachment.html>