[Numpy-discussion] deprecate numpy.matrix

[Pauli Virtanen]

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.

(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