[Numpy-discussion] Deprecating matrices.

[Nathaniel Smith]

On Fri, Jan 6, 2017 at 11:59 PM, Ralf Gommers <ralf.gommers at gmail.com> wrote:
>
>
> On Sat, Jan 7, 2017 at 2:52 PM, Charles R Harris <charlesr.harris at gmail.com>
> wrote:
>>
>>
>>
>> On Fri, Jan 6, 2017 at 6:37 PM, <josef.pktd at gmail.com> wrote:
>>>
>>>
>>>
>>>
>>> On Fri, Jan 6, 2017 at 8:28 PM, Ralf Gommers <ralf.gommers at gmail.com>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On Sat, Jan 7, 2017 at 2:21 PM, CJ Carey <perimosocordiae at gmail.com>
>>>> wrote:
>>>>>
>>>>>
>>>>> On Fri, Jan 6, 2017 at 6:19 PM, Ralf Gommers <ralf.gommers at gmail.com>
>>>>> wrote:
>>>>>>
>>>>>> This sounds like a reasonable idea. Timeline could be something like:
>>>>>>
>>>>>> 1. Now: create new package, deprecate np.matrix in docs.
>>>>>> 2. In say 1.5 years: start issuing visible deprecation warnings in
>>>>>> numpy
>>>>>> 3. After 2020: remove matrix from numpy.
>>>>>>
>>>>>> Ralf
>>>>>
>>>>>
>>>>> I think this sounds reasonable, and reminds me of the deliberate
>>>>> deprecation process taken for scipy.weave. I guess we'll see how successful
>>>>> it was when 0.19 is released.
>>>>>
>>>>> The major problem I have with removing numpy matrices is the effect on
>>>>> scipy.sparse, which mostly-consistently mimics numpy.matrix semantics and
>>>>> often produces numpy.matrix results when densifying. The two are coupled
>>>>> tightly enough that if numpy matrices go away, all of the existing sparse
>>>>> matrix classes will have to go at the same time.
>>>>>
>>>>> I don't think that would be the end of the world,
>>>>
>>>>
>>>> Not the end of the world literally, but the impact would be pretty
>>>> major. I think we're stuck with scipy.sparse, and may at some point will add
>>>> a new sparse *array* implementation next to it. For scipy we will have to
>>>> add a dependency on the new npmatrix package or vendor it.
>>>
>>>
>>> That sounds to me like moving maintenance of numpy.matrix from numpy to
>>> scipy, if scipy.sparse is one of the main users and still depends on it.
>
>
> Maintenance costs are pretty low, and are partly still for numpy (it has to
> keep subclasses like np.matrix working. I'm not too worried about the
> effort. The purpose here is to remove np.matrix from numpy so beginners will
> never see it. Educating sparse matrix users is a lot easier, and there are a
> lot less such users.
>
>>
>> What I was thinking was encouraging folks to use `arr.dot(...)` or `@`
>> instead of `*` for matrix multiplication, keeping `*` for scalar
>> multiplication.
>
>
> I don't think that change in behavior of `*` is doable.

I guess it would be technically possible to have matrix.__mul__ issue
a deprecation warning before matrix.__init__ does, to try and
encourage people to switch to using .dot and/or @, and thus make it
easier to later port their code to regular arrays? I'm not immediately
seeing how this would help much though, since there would still be
this second porting step required. Especially since there's still lots
of room for things to break at that second step due to matrix's
insistence that everything be 2d always, and my impression is that
users are more annoyed by two-step migrations than one-step
migrations.

-n

-- 
Nathaniel J. Smith -- https://vorpus.org