Re: [Numpy-discussion] Deprecating matrices.
On Sat, Jan 7, 2017 at 2:52 PM, Charles R Harris wrote: > > > On Fri, Jan 6, 2017 at 6:37 PM, wrote: > >> >> >> >> On Fri, Jan 6, 2017 at 8:28 PM, Ralf Gommers >> wrote: >> >>> >>> >>> On Sat, Jan 7, 2017 at 2:21 PM, CJ Carey >>> wrote: >>> On Fri, Jan 6, 2017 at 6:19 PM, Ralf Gommers 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. > If those operations were defined for matrices, > Why if? They are defined, and work as expected as far as I can tell. > then at some point sparse could go to arrays and it would not be > noticeable except for the treatment of 1-D arrays -- which admittedly might > be a bit tricky. > I'd like that to be feasible, but especially given that any such change would not break code but rather silently change numerical values, it's likely not a healthy idea. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating matrices.
On Fri, Jan 6, 2017 at 6:37 PM, wrote: > > > > On Fri, Jan 6, 2017 at 8:28 PM, Ralf Gommers > wrote: > >> >> >> On Sat, Jan 7, 2017 at 2:21 PM, CJ Carey >> wrote: >> >>> >>> On Fri, Jan 6, 2017 at 6:19 PM, Ralf Gommers >>> 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. > What I was thinking was encouraging folks to use `arr.dot(...)` or `@` instead of `*` for matrix multiplication, keeping `*` for scalar multiplication. If those operations were defined for matrices, then at some point sparse could go to arrays and it would not be noticeable except for the treatment of 1-D arrays -- which admittedly might be a bit tricky. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating matrices.
On Fri, Jan 6, 2017 at 8:28 PM, Ralf Gommers wrote: > > > On Sat, Jan 7, 2017 at 2:21 PM, CJ Carey > wrote: > >> >> On Fri, Jan 6, 2017 at 6:19 PM, Ralf Gommers >> 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. Josef > > Ralf > > > >> but it's definitely something that should happen while scipy is still >> pre-1.0, if it's ever going to happen. >> >> ___ >> 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 > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating matrices.
On Sat, Jan 7, 2017 at 2:21 PM, CJ Carey wrote: > > On Fri, Jan 6, 2017 at 6:19 PM, Ralf Gommers > 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. Ralf > but it's definitely something that should happen while scipy is still > pre-1.0, if it's ever going to happen. > > ___ > 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
Re: [Numpy-discussion] Deprecating matrices.
On Fri, Jan 6, 2017 at 6:19 PM, Ralf Gommers 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, but it's definitely something that should happen while scipy is still pre-1.0, if it's ever going to happen. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating matrices.
On Wed, Jan 4, 2017 at 9:07 AM, Bryan Van de Ven wrote: > There's a good chance that bokeh.charts will be split off into a > separately distributed package as well. Hopefully being a much smaller, > pure Python project makes it a more accessible target for anyone interested > in maintaining it, and if no one is interested in it anymore, well that > fact becomes easier to judge. I think it would be a reasonable approach > here for the same reasons. > > Bryan > > On Jan 3, 2017, at 13:54, Benjamin Root wrote: > > That's not a bad idea. Matplotlib is currently considering something > similar for its mlab module. It has been there since the beginning, but it > is very outdated and very out-of-scope for matplotlib. However, there are > still lots of code out there that depends on it. So, we are looking to > split it off as its own package. The details still need to be worked out > (should we initially depend on the package and simply alias its import with > a DeprecationWarning, or should we go cold turkey and have a good message > explaining the change). > > Don't go cold turkey please, that still would break a lot of code. Even with a good message, breaking things isn't great. > > Ben Root > > > On Tue, Jan 3, 2017 at 2:31 PM, Todd wrote: > >> On Mon, Jan 2, 2017 at 8:36 PM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> Hi All, >>> >>> Just throwing this click bait out for discussion. Now that the `@` >>> operator is available and things seem to be moving towards Python 3, >>> especially in the classroom, we should consider the real possibility of >>> deprecating the matrix type and later removing it. No doubt there are old >>> scripts that require them, but older versions of numpy are available for >>> those who need to run old scripts. >>> >>> Thoughts? >>> >>> Chuck >>> >>> >> What if the matrix class was split out into its own project, perhaps as a >> scikit. >> > Something like "npmatrix" would be a better name, we'd like to keep scikit- for active well-maintained projects I'd think. > That way those who really need it can still use it. If there is >> sufficient desire for it, those who need it can maintain it. If not, it >> will hopefully it will take long enough for it to bitrot that everyone has >> transitioned. >> > 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 ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
