On Sat, Jan 7, 2017 at 9:39 PM, Nathaniel Smith <n...@pobox.com> wrote:
> On Fri, Jan 6, 2017 at 11:59 PM, Ralf Gommers <ralf.gomm...@gmail.com> > wrote: > > > > > > On Sat, Jan 7, 2017 at 2:52 PM, Charles R Harris < > charlesr.har...@gmail.com> > > wrote: > >> > >> > >> > >> On Fri, Jan 6, 2017 at 6:37 PM, <josef.p...@gmail.com> wrote: > >>> > >>> > >>> > >>> > >>> On Fri, Jan 6, 2017 at 8:28 PM, Ralf Gommers <ralf.gomm...@gmail.com> > >>> wrote: > >>>> > >>>> > >>>> > >>>> On Sat, Jan 7, 2017 at 2:21 PM, CJ Carey <perimosocord...@gmail.com> > >>>> wrote: > >>>>> > >>>>> > >>>>> On Fri, Jan 6, 2017 at 6:19 PM, Ralf Gommers <ralf.gomm...@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? Yes, but that's not very relevant. I'm saying "not doable" since after the debacle with changing diag return to a view my understanding is we decided that it's a bad idea to make changes that don't break code but return different numerical results. There's no good way to work around that here. With something as widely used as np.matrix, you simply cannot rely on people porting code. You just need to phase out np.matrix in a way that breaks code but never changes behavior silently (even across multiple releases). Ralf
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
