Re: [Numpy-discussion] Deprecating matrices.
On Fri, Jan 6, 2017 at 11:59 PM, Ralf Gommers wrote: > > > 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. 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 NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating matrices.
On Sat, Jan 7, 2017 at 9:39 PM, Nathaniel Smith wrote: > On Fri, Jan 6, 2017 at 11:59 PM, Ralf Gommers > 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, 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. > > 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
Re: [Numpy-discussion] Deprecating matrices.
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 , wrote: > > > On Sat, Jan 7, 2017 at 9:39 PM, Nathaniel Smith (mailto:n...@pobox.com)> wrote: > > On Fri, Jan 6, 2017 at 11:59 PM, Ralf Gommers > (mailto:ralf.gomm...@gmail.com)> wrote: > > > > > > > > > On Sat, Jan 7, 2017 at 2:52 PM, Charles R Harris > > > mailto:charlesr.har...@gmail.com)> > > > wrote: > > >> > > >> > > >> > > >> On Fri, Jan 6, 2017 at 6:37 PM, > >> (mailto:josef.p...@gmail.com)> wrote: > > >>> > > >>> > > >>> > > >>> > > >>> On Fri, Jan 6, 2017 at 8:28 PM, Ralf Gommers > >>> (mailto:ralf.gomm...@gmail.com)> > > >>> wrote: > > > > > > > > On Sat, Jan 7, 2017 at 2:21 PM, CJ Carey > (mailto:perimosocord...@gmail.com)> > > wrote: > > > > > > > > > On Fri, Jan 6, 2017 at 6:19 PM, Ralf Gommers > > (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
Re: [Numpy-discussion] Deprecating matrices.
Hi All, It seems there are two steps that can be taken now and are needed no matter what: 1. Add numpy documentation describing the preferred way to handle matrices, extolling the virtues of @, and move np.matrix documentation to a deprecated section 2. Start on a new `sparse` class that is based on regular arrays (and uses `__array_func__` instead of prepare/wrap?). All the best, Marten ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating matrices.
On Jan 6, 2017 20:28, "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. 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 So what about this: 1. Create a sparse array class 2. (optional) Refactor the sparse matrix class to be based on the sparse array class (may not be feasible) 3. Copy the spare matrix class into the matrix package 4. Deprecate the scipy sparse matrix class 5. Remove the scipy sparse matrix class when the numpy matrix class I don't know about the timeline, but this would just need to be done by 2020. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating matrices.
On Sun, Jan 8, 2017 at 8:33 AM, Marten van Kerkwijk < m.h.vankerkw...@gmail.com> wrote: > Hi All, > > It seems there are two steps that can be taken now and are needed no > matter what: > > 1. Add numpy documentation describing the preferred way to handle > matrices, extolling the virtues of @, and move np.matrix documentation > to a deprecated section > That would be good to do asap. Any volunteers? > > 2. Start on a new `sparse` class that is based on regular arrays There are two efforts that I know of in this direction: https://github.com/perimosocordiae/sparray https://github.com/ev-br/sparr (and > uses `__array_func__` instead of prepare/wrap?). > Getting __array_func__ finally into a released version of numpy will be a major improvement for sparse matrix behavior (like making np.dot(some_matrix) work) in itself. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating matrices.
On Sun, Jan 8, 2017 at 9:31 AM, Todd wrote: > > > On Jan 6, 2017 20:28, "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. > > 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 > > > So what about this: > > 1. Create a sparse array class > 2. (optional) Refactor the sparse matrix class to be based on the sparse > array class (may not be feasible) > 3. Copy the spare matrix class into the matrix package > 4. Deprecate the scipy sparse matrix class > 5. Remove the scipy sparse matrix class when the numpy matrix class > It looks to me like we're getting a bit off track here. The sparse matrices in scipy are heavily used, and despite rough edges pretty good at what they do. Deprecating them is not a goal. The actual goal for the exercise that started this thread (at least as I see it) is to remove np.matrix from numpy itself so users (that don't know the difference) will only use ndarrays. And the few users that prefer np.matrix for teaching can now switch because of @, so their preference should have disappeared. To reach that goal, no deprecation or backwards incompatible changes to scipy.sparse are needed. Ralf ___ 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:29 PM, Ralf Gommers wrote: > > > On Sun, Jan 8, 2017 at 9:31 AM, Todd wrote: > >> >> >> On Jan 6, 2017 20:28, "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. >> >> 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 >> >> >> So what about this: >> >> 1. Create a sparse array class >> 2. (optional) Refactor the sparse matrix class to be based on the sparse >> array class (may not be feasible) >> 3. Copy the spare matrix class into the matrix package >> 4. Deprecate the scipy sparse matrix class >> 5. Remove the scipy sparse matrix class when the numpy matrix class >> > > It looks to me like we're getting a bit off track here. The sparse > matrices in scipy are heavily used, and despite rough edges pretty good at > what they do. Deprecating them is not a goal. > > The actual goal for the exercise that started this thread (at least as I > see it) is to remove np.matrix from numpy itself so users (that don't know > the difference) will only use ndarrays. And the few users that prefer > np.matrix for teaching can now switch because of @, so their preference > should have disappeared. > > To reach that goal, no deprecation or backwards incompatible changes to > scipy.sparse are needed. > What is the way forward with sparse? That looks like the biggest blocker on the road to a matrix free NumPy. I don't see moving the matrix package elsewhere as a solution for that. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating matrices.
On Sun, Jan 8, 2017 at 12:26 PM, Charles R Harris wrote: > > > On Sat, Jan 7, 2017 at 2:29 PM, Ralf Gommers > wrote: > >> >> It looks to me like we're getting a bit off track here. The sparse >> matrices in scipy are heavily used, and despite rough edges pretty good at >> what they do. Deprecating them is not a goal. >> >> The actual goal for the exercise that started this thread (at least as I >> see it) is to remove np.matrix from numpy itself so users (that don't know >> the difference) will only use ndarrays. And the few users that prefer >> np.matrix for teaching can now switch because of @, so their preference >> should have disappeared. >> >> To reach that goal, no deprecation or backwards incompatible changes to >> scipy.sparse are needed. >> > > What is the way forward with sparse? That looks like the biggest blocker > on the road to a matrix free NumPy. I don't see moving the matrix package > elsewhere as a solution for that. > Why not? Ralf ___ 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 4:35 PM, Ralf Gommers wrote: > > > On Sun, Jan 8, 2017 at 12:26 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Sat, Jan 7, 2017 at 2:29 PM, Ralf Gommers >> wrote: >> >>> >>> It looks to me like we're getting a bit off track here. The sparse >>> matrices in scipy are heavily used, and despite rough edges pretty good at >>> what they do. Deprecating them is not a goal. >>> >>> The actual goal for the exercise that started this thread (at least as I >>> see it) is to remove np.matrix from numpy itself so users (that don't know >>> the difference) will only use ndarrays. And the few users that prefer >>> np.matrix for teaching can now switch because of @, so their preference >>> should have disappeared. >>> >>> To reach that goal, no deprecation or backwards incompatible changes to >>> scipy.sparse are needed. >>> >> >> What is the way forward with sparse? That looks like the biggest blocker >> on the road to a matrix free NumPy. I don't see moving the matrix package >> elsewhere as a solution for that. >> > > Why not? > > Because it doesn't get rid of matrices in SciPy, not does one gain a scalar multiplication operator for sparse. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating matrices.
On Sun, Jan 8, 2017 at 12:42 PM, Charles R Harris wrote: > > > On Sat, Jan 7, 2017 at 4:35 PM, Ralf Gommers > wrote: > >> >> >> On Sun, Jan 8, 2017 at 12:26 PM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> >>> >>> On Sat, Jan 7, 2017 at 2:29 PM, Ralf Gommers >>> wrote: >>> It looks to me like we're getting a bit off track here. The sparse matrices in scipy are heavily used, and despite rough edges pretty good at what they do. Deprecating them is not a goal. The actual goal for the exercise that started this thread (at least as I see it) is to remove np.matrix from numpy itself so users (that don't know the difference) will only use ndarrays. And the few users that prefer np.matrix for teaching can now switch because of @, so their preference should have disappeared. To reach that goal, no deprecation or backwards incompatible changes to scipy.sparse are needed. >>> >>> What is the way forward with sparse? That looks like the biggest blocker >>> on the road to a matrix free NumPy. I don't see moving the matrix package >>> elsewhere as a solution for that. >>> >> >> Why not? >> >> > Because it doesn't get rid of matrices in SciPy, not does one gain a > scalar multiplication operator for sparse. > That's a different goal though. You can reach the "get matrix out of numpy" goal fairly easily (docs and packaging work), but if you insist on coupling it to major changes to scipy.sparse (a lot more work + backwards compat break), then what will likely happen is: nothing. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating matrices.
I agree with Ralf; coupling these changes to sparse is a bad idea. I think that scipy.sparse will be an important consideration during the deprecation process, though, perhaps as an indicator of how painful the transition might be for third party code. I'm +1 for splitting matrices out into a standalone package. On Jan 7, 2017 5:51 PM, "Ralf Gommers" wrote: On Sun, Jan 8, 2017 at 12:42 PM, Charles R Harris wrote: > > > On Sat, Jan 7, 2017 at 4:35 PM, Ralf Gommers > wrote: > >> >> >> On Sun, Jan 8, 2017 at 12:26 PM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> >>> >>> On Sat, Jan 7, 2017 at 2:29 PM, Ralf Gommers >>> wrote: >>> It looks to me like we're getting a bit off track here. The sparse matrices in scipy are heavily used, and despite rough edges pretty good at what they do. Deprecating them is not a goal. The actual goal for the exercise that started this thread (at least as I see it) is to remove np.matrix from numpy itself so users (that don't know the difference) will only use ndarrays. And the few users that prefer np.matrix for teaching can now switch because of @, so their preference should have disappeared. To reach that goal, no deprecation or backwards incompatible changes to scipy.sparse are needed. >>> >>> What is the way forward with sparse? That looks like the biggest blocker >>> on the road to a matrix free NumPy. I don't see moving the matrix package >>> elsewhere as a solution for that. >>> >> >> Why not? >> >> > Because it doesn't get rid of matrices in SciPy, not does one gain a > scalar multiplication operator for sparse. > That's a different goal though. You can reach the "get matrix out of numpy" goal fairly easily (docs and packaging work), but if you insist on coupling it to major changes to scipy.sparse (a lot more work + backwards compat break), then what will likely happen is: nothing. 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
Re: [Numpy-discussion] Deprecating matrices.
On Sat, Jan 7, 2017 at 5:31 PM, CJ Carey wrote: > I agree with Ralf; coupling these changes to sparse is a bad idea. > > I think that scipy.sparse will be an important consideration during the > deprecation process, though, perhaps as an indicator of how painful the > transition might be for third party code. > > I'm +1 for splitting matrices out into a standalone package. > Decoupled or not, sparse still needs to be dealt with. What is the plan? Chuck ___ 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 4:51 PM, Ralf Gommers wrote: > > > On Sun, Jan 8, 2017 at 12:42 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Sat, Jan 7, 2017 at 4:35 PM, Ralf Gommers >> wrote: >> >>> >>> >>> On Sun, Jan 8, 2017 at 12:26 PM, Charles R Harris < >>> charlesr.har...@gmail.com> wrote: >>> On Sat, Jan 7, 2017 at 2:29 PM, Ralf Gommers wrote: > > It looks to me like we're getting a bit off track here. The sparse > matrices in scipy are heavily used, and despite rough edges pretty good at > what they do. Deprecating them is not a goal. > > The actual goal for the exercise that started this thread (at least as > I see it) is to remove np.matrix from numpy itself so users (that don't > know the difference) will only use ndarrays. And the few users that prefer > np.matrix for teaching can now switch because of @, so their preference > should have disappeared. > > To reach that goal, no deprecation or backwards incompatible changes > to scipy.sparse are needed. > What is the way forward with sparse? That looks like the biggest blocker on the road to a matrix free NumPy. I don't see moving the matrix package elsewhere as a solution for that. >>> >>> Why not? >>> >>> >> Because it doesn't get rid of matrices in SciPy, not does one gain a >> scalar multiplication operator for sparse. >> > > That's a different goal though. You can reach the "get matrix out of > numpy" goal fairly easily (docs and packaging work), but if you insist on > coupling it to major changes to scipy.sparse (a lot more work + backwards > compat break), then what will likely happen is: nothing. > Could always remove matrix from the top level namespace and make it private. It still needs to reside someplace as long as sparse uses it. Fixing sparse is more work, but we have three years and it won't be getting any easier as time goes on. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating matrices.
On Sun, Jan 8, 2017 at 2:09 PM, Charles R Harris wrote: > > > On Sat, Jan 7, 2017 at 5:31 PM, CJ Carey > wrote: > >> I agree with Ralf; coupling these changes to sparse is a bad idea. >> >> I think that scipy.sparse will be an important consideration during the >> deprecation process, though, perhaps as an indicator of how painful the >> transition might be for third party code. >> >> I'm +1 for splitting matrices out into a standalone package. >> > > Decoupled or not, sparse still needs to be dealt with. What is the plan? > My view would be: - keep current sparse matrices as is (with improvements, like __numpy_func__ and the various performance improvements that regularly get done) - once one of the sparse *array* implementations progresses far enough, merge that and encourage people to switch over - in the far future, once packages like scikit-learn have switched to the new sparse arrays, the sparse matrices could potentially also be split off as a separate package, in the same way as we did for weave and now can do for npmatrix. Ralf ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Deprecating matrices.
> Decoupled or not, sparse still needs to be dealt with. What is the plan? > My view would be: - keep current sparse matrices as is (with improvements, like __numpy_func__ and the various performance improvements that regularly get done) - once one of the sparse *array* implementations progresses far enough, merge that and encourage people to switch over - in the far future, once packages like scikit-learn have switched to the new sparse arrays, the sparse matrices could potentially also be split off as a separate package, in the same way as we did for weave and now can do for npmatrix. I think that's the best way forward as well. This can happen independently of numpy matrix changes, and doesn't leave users with silently broken code. ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
