Hi all! I've been lurking on this discussion, and don't have too much to add except to encourage a fast deprecation: I can't wait for sparse matrices to have an element-wise multiply operator.
On 7 Jan 2017, 7:52 PM +1100, Ralf Gommers <ralf.gomm...@gmail.com>, wrote: > > > On Sat, Jan 7, 2017 at 9:39 PM, Nathaniel Smith <n...@pobox.com > (mailto:n...@pobox.com)> wrote: > > On Fri, Jan 6, 2017 at 11:59 PM, Ralf Gommers <ralf.gomm...@gmail.com > > (mailto:ralf.gomm...@gmail.com)> wrote: > > > > > > > > > On Sat, Jan 7, 2017 at 2:52 PM, Charles R Harris > > > <charlesr.har...@gmail.com (mailto:charlesr.har...@gmail.com)> > > > wrote: > > >> > > >> > > >> > > >> On Fri, Jan 6, 2017 at 6:37 PM, <josef.p...@gmail.com > > >> (mailto:josef.p...@gmail.com)> wrote: > > >>> > > >>> > > >>> > > >>> > > >>> On Fri, Jan 6, 2017 at 8:28 PM, Ralf Gommers <ralf.gomm...@gmail.com > > >>> (mailto:ralf.gomm...@gmail.com)> > > >>> wrote: > > >>>> > > >>>> > > >>>> > > >>>> On Sat, Jan 7, 2017 at 2:21 PM, CJ Carey <perimosocord...@gmail.com > > >>>> (mailto:perimosocord...@gmail.com)> > > >>>> wrote: > > >>>>> > > >>>>> > > >>>>> On Fri, Jan 6, 2017 at 6:19 PM, Ralf Gommers <ralf.gomm...@gmail.com > > >>>>> (mailto: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
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
