Hi All, Thoughts?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. _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Tue, Jan 3, 2017 at 2:36 PM, Charles R Harris <[hidden email]> wrote:
Clearly deprecate in the docs now, and warn only later imho. We can't warn before we have a good solution for scipy.sparse matrices, which have matrix semantics and return matrix instances. Ralf _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Mon, Jan 2, 2017 at 9:00 PM, Ralf Gommers <[hidden email]> wrote:
How about dropping python 2 support at the same time, then we can all be in a @ world. Josef
_______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Mon, Jan 2, 2017 at 6:26 PM, <[hidden email]> wrote:
> > > On Mon, Jan 2, 2017 at 9:00 PM, Ralf Gommers <[hidden email]> wrote: >> >> >> >> On Tue, Jan 3, 2017 at 2:36 PM, Charles R Harris >> <[hidden email]> 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? >> >> >> Clearly deprecate in the docs now, and warn only later imho. We can't warn >> before we have a good solution for scipy.sparse matrices, which have matrix >> semantics and return matrix instances. >> >> Ralf > > > How about dropping python 2 support at the same time, then we can all be in > a @ world. > > Josef Let's not yoke together two (mostly) unrelated controversial discussions? I doubt we'll be able to remove either Python 2 or matrix support before 2020 at the earliest, so the discussion now is just about how to communicate to users that they should not be using 'matrix'. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
In reply to this post by josef.pktd
On Mon, Jan 2, 2017 at 7:26 PM, <[hidden email]> wrote:
The "@" operator works with matrices already, what causes problems is the combination of matrices with 1-D arrays. That can be fixed, I think. The big problem is probably the lack of "@" in Python 2.7. I wonder if there is any chance of getting it backported to 2.7 before support is dropped in 2020? I expect it would be a fight, but I also suspect it would not be difficult to do if the proposal was accepted. Then at some future date sparse could simply start returning arrays. Chuck _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Mon, Jan 2, 2017 at 8:12 PM, Charles R Harris <[hidden email]> wrote:
Hmm, matrix-scalar multiplication will be a problem. Chuck _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
In reply to this post by Charles R Harris
On Mon, Jan 2, 2017 at 7:12 PM, Charles R Harris
<[hidden email]> wrote: > > > On Mon, Jan 2, 2017 at 7:26 PM, <[hidden email]> wrote: [...] >> How about dropping python 2 support at the same time, then we can all be >> in a @ world. >> > > The "@" operator works with matrices already, what causes problems is the > combination of matrices with 1-D arrays. That can be fixed, I think. The > big problem is probably the lack of "@" in Python 2.7. I wonder if there is > any chance of getting it backported to 2.7 before support is dropped in > 2020? I expect it would be a fight, but I also suspect it would not be > difficult to do if the proposal was accepted. Then at some future date > sparse could simply start returning arrays. Unfortunately the chance of Python 2.7 adding support for "@" is best expressed as a denormal. -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Mon, Jan 2, 2017 at 8:29 PM, Nathaniel Smith <[hidden email]> wrote: On Mon, Jan 2, 2017 at 7:12 PM, Charles R Harris That's what I figured ;) Hmm, matrices would work fine with the current combination of '*' (works for scalar muiltiplication) and '@' (works for matrices). So for Python3 code currently written for matrices can be reformed to be array compatible. But '@' for Python 2.7 would sure help... Chuck _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Mon, Jan 2, 2017 at 7:54 PM, Charles R Harris
<[hidden email]> wrote: > > > On Mon, Jan 2, 2017 at 8:29 PM, Nathaniel Smith <[hidden email]> wrote: >> >> On Mon, Jan 2, 2017 at 7:12 PM, Charles R Harris >> <[hidden email]> wrote: >> > >> > >> > On Mon, Jan 2, 2017 at 7:26 PM, <[hidden email]> wrote: >> [...] >> >> How about dropping python 2 support at the same time, then we can all >> >> be >> >> in a @ world. >> >> >> > >> > The "@" operator works with matrices already, what causes problems is >> > the >> > combination of matrices with 1-D arrays. That can be fixed, I think. >> > The >> > big problem is probably the lack of "@" in Python 2.7. I wonder if there >> > is >> > any chance of getting it backported to 2.7 before support is dropped in >> > 2020? I expect it would be a fight, but I also suspect it would not be >> > difficult to do if the proposal was accepted. Then at some future date >> > sparse could simply start returning arrays. >> >> Unfortunately the chance of Python 2.7 adding support for "@" is best >> expressed as a denormal. > > > That's what I figured ;) Hmm, matrices would work fine with the current > combination of '*' (works for scalar muiltiplication) and '@' (works for > matrices). So for Python3 code currently written for matrices can be > reformed to be array compatible. But '@' for Python 2.7 would sure help... I mean, it can just use arrays + dot(). It's not as elegant as '@', but given that almost everyone has already switched it's clearly not *that* bad... -n -- Nathaniel J. Smith -- https://vorpus.org _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
In reply to this post by Charles R Harris
On Mon, Jan 2, 2017 at 8:36 PM, Charles R Harris <[hidden email]> wrote:
What if the matrix class was split out into its own project, perhaps as a scikit. 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. _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
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). Ben RootOn Tue, Jan 3, 2017 at 2:31 PM, Todd <[hidden email]> wrote:
_______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
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
_______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Wed, Jan 4, 2017 at 9:07 AM, Bryan Van de Ven <[hidden email]> wrote:
Don't go cold turkey please, that still would break a lot of code. Even with a good message, breaking things isn't great.
Something like "npmatrix" would be a better name, we'd like to keep scikit- for active well-maintained projects I'd think.
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 [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Fri, Jan 6, 2017 at 6:19 PM, Ralf Gommers <[hidden email]> wrote:
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 [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Sat, Jan 7, 2017 at 2:21 PM, CJ Carey <[hidden email]> wrote:
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
_______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Fri, Jan 6, 2017 at 8:28 PM, Ralf Gommers <[hidden email]> wrote:
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
_______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Fri, Jan 6, 2017 at 6:37 PM, <[hidden email]> wrote:
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 [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Sat, Jan 7, 2017 at 2:52 PM, Charles R Harris <[hidden email]> wrote:
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.
I don't think that change in behavior of `*` is doable.
Why if? They are defined, and work as expected as far as I can tell.
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 [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Fri, Jan 6, 2017 at 11:59 PM, Ralf Gommers <[hidden email]> wrote:
> > > On Sat, Jan 7, 2017 at 2:52 PM, Charles R Harris <[hidden email]> > wrote: >> >> >> >> On Fri, Jan 6, 2017 at 6:37 PM, <[hidden email]> wrote: >>> >>> >>> >>> >>> On Fri, Jan 6, 2017 at 8:28 PM, Ralf Gommers <[hidden email]> >>> wrote: >>>> >>>> >>>> >>>> On Sat, Jan 7, 2017 at 2:21 PM, CJ Carey <[hidden email]> >>>> wrote: >>>>> >>>>> >>>>> On Fri, Jan 6, 2017 at 6:19 PM, Ralf Gommers <[hidden email]> >>>>> 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 _______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
On Sat, Jan 7, 2017 at 9:39 PM, Nathaniel Smith <[hidden email]> wrote:
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 [hidden email] https://mail.scipy.org/mailman/listinfo/numpy-discussion |
Free forum by Nabble | Edit this page |