Deprecating matrices.

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Deprecating matrices.

Charles R Harris
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

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

ralfgommers


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



_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

josef.pktd


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

 



_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion



_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

Nathaniel Smith
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
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

Charles R Harris
In reply to this post by josef.pktd


On Mon, Jan 2, 2017 at 7: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.


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
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

Charles R Harris


On Mon, Jan 2, 2017 at 8:12 PM, Charles R Harris <[hidden email]> wrote:


On Mon, Jan 2, 2017 at 7: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.


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.

Hmm, matrix-scalar multiplication will be a problem.

Chuck


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

Nathaniel Smith
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
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

Charles R Harris


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...

Chuck

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

Nathaniel Smith
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
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

Todd
In reply to this post by Charles R Harris
On Mon, Jan 2, 2017 at 8: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?

Chuck


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
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

Benjamin Root
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 Root


On Tue, Jan 3, 2017 at 2:31 PM, Todd <[hidden email]> wrote:
On Mon, Jan 2, 2017 at 8: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?

Chuck


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



_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

Bryan Van de Ven-2
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 <[hidden email]> 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).

Ben Root


On Tue, Jan 3, 2017 at 2:31 PM, Todd <[hidden email]> wrote:
On Mon, Jan 2, 2017 at 8: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?

Chuck


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


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

ralfgommers


On Wed, Jan 4, 2017 at 9:07 AM, Bryan Van de Ven <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> wrote:
On Mon, Jan 2, 2017 at 8: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?

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
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

CJ Carey

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, 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
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

ralfgommers


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.

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
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion



_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

josef.pktd


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.

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
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion



_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion



_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

Charles R Harris


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.

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
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

ralfgommers


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.
 
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
[hidden email]
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

Nathaniel Smith
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
Reply | Threaded
Open this post in threaded view
|

Re: Deprecating matrices.

ralfgommers


On Sat, Jan 7, 2017 at 9:39 PM, Nathaniel Smith <[hidden email]> wrote:
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?

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
12