[Numpy-discussion] deprecate numpy.matrix

[josef.pktd at gmail.com]

On Mon, Feb 10, 2014 at 6:29 PM, Pauli Virtanen <pav at iki.fi> wrote:

> 11.02.2014 00:31, Alan G Isaac kirjoitti:
> > On 2/10/2014 5:11 PM, Pauli Virtanen wrote:
> >> The existence of np.matrix messes up the general agreement on ndarray
> >> semantics in Python. The meaning of very basic code such as
> >>
> >>      A * B
> >>      A.sum(0)
> >>      A[0]
> >>
> >> where A and B are NxN matrices of some sort now depends on the types
> >> of A and B. This makes writing duck typed code impossible when both
> >> semantics are in play.
> >
> > I'm just missing the point here; sorry.
> > Why isn't the right approach to require that
> > any object that wants to work with scipy
> > can be called  by `asarray` to guarantee
> > the core semantics? (And the matrix
> > object passes this test.)  For some objects
> > we can agree that `asarray` will coerce them.
> > (E.g., lists.)
> >
> > I just do not see why scipy should care about
> > the semantics an object uses for interacting
> > with other objects of the same type.
>
> I have a couple of points:
>
> (A)
>
> asarray() coerces the input to a dense array. This you do not want to do
> to sparse matrices or matrix-free linear operators, as many linear
> algebra algorithms don't need to know the matrix entries.
>
> (B)
>
> Coercing input types is something that is seldom done in Python code,
> since it breaks duck typing.
>
> Usually, the interface is specified by assumed semantics of the input
> objects. The user is then free to pass in mock objects that fulfill the
> necessary subsection of the assumed interface.
>

Almost all the code in scipy.stats and statsmodels starts with np.asarray.
The numpy doc standard has the term `array_like` to indicate things that
can be converted to a usable object by ndasarray.

ducktyping could be restricted to a very narrow category of ducks.

What about masked arrays and structured dtypes?
Because we cannot usefully convert them by asarray, we have to tell users
that they don't work with a function.
Our ducks that quack in the wrong way. ?

How do you handle list and other array_likes in sparse?

Josef


>
> (C)
>
> This is not only about Scipy, but also a language design question:
>
> Suppose someone, who is not a Python expert, wants to implement a
> linear algebra algorithm in Python.
>
> Will they write it using matrix or ndarray? (Note: np.matrix is not
> uncommon on stackoverflow.)
>
> Will someone who reads the code easily understand what it does (does *
> stand for elementwise or matrix product etc)?
>
> Can they easily make it work both with sparse and dense matrices?
> Matrix-free operators? Does it work both for ndarray and np.matrix inputs?
>
> (D)
>
> The presence of np.matrix invites people to write code using the
> np.matrix semantics. This can further lead to the code spitting out
> dense results as np.matrix, and then it becomes difficult to follow
> what sort of an object you have.
>
> (E)
>
> Some examples of the above semantics diaspora on scipy.sparse:
>
> * Implementation of GMRES et al in Scipy. The implementation reinvents
>   yet another set of semantics that it uses internally.
>
> * scipy.sparse has mostly matrix semantics, but not completely, and the
>   return values vary between matrix and ndarray
>
>
> --
> Pauli Virtanen
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20140210/d87cece9/attachment.html>