[Numpy-discussion] deprecate numpy.matrix
josef.pktd at gmail.com
josef.pktd at gmail.com
Mon Feb 10 18:45:38 EST 2014
On Mon, Feb 10, 2014 at 6:39 PM, <josef.pktd at gmail.com> wrote:
>
>
> 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.
>
I thought once it would be nice to have a flag on the classes that indicate
`array_semantic` versus `matrix_semantic` so it would be easy to check the
quack instead of the duck.
Josef
>
> 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/d9a25041/attachment.html>
More information about the NumPy-Discussion
mailing list