Hi All, The diag, diagonal, and ravel functions have recently been changed to preserve subtypes. However, this causes lots of backward compatibility problems for matrix users, in particular, scipy.sparse. One possibility for fixing this is to special case matrix and so that these functions continue to return 1-d arrays for matrix instances. This is kind of ugly as `a..ravel` will still return a matrix when a is a matrix, an ugly inconsistency. This may be a case where practicality beats beauty. Thoughts? Chuck
Would this really be practicality beating purity? It would be nice to have know the principle governing this. For example, is there a way to convincingly group these as array operations vs matrix operations? Personally I am puzzled by preserving subtype of `diagonal` and very especially of `ravel`. Has anyone requested this? (I can see the argument for `diag`.) Alan Isaac On 1/2/2015 9:04 PM, Charles R Harris wrote:
The diag, diagonal, and ravel functions have recently been changed to preserve subtypes. However, this causes lots of backward compatibility problems for matrix users, in particular, scipy.sparse. One possibility for fixing this is to special case matrix and so that these functions continue to return 1-d arrays for matrix instances. This is kind of ugly as `a..ravel` will still return a matrix when a is a matrix, an ugly inconsistency. This may be a case where practicality beats beauty.
On Sat, Jan 3, 2015 at 8:05 AM, Alan G Isaac <alan.isaac@gmail.com> wrote:
Would this really be practicality beating purity? It would be nice to have know the principle governing this. For example, is there a way to convincingly group these as array operations vs matrix operations?
Personally I am puzzled by preserving subtype of `diagonal` and very especially of `ravel`. Has anyone requested this? (I can see the argument for `diag`.)
Alan Isaac
In [1]: from astropy import units as u In [2]: a = eye(2) * u.m In [3]: a Out[3]: <Quantity [[ 1., 0.], [ 0., 1.]] m> In [4]: diagonal(a) Out[4]: <Quantity [ 1., 1.] m> In [5]: diag(a) Out[5]: <Quantity [ 1., 1.] m> In [6]: ravel(a) Out[6]: <Quantity [ 1., 0., 0., 1.] m> None of those examples keep the units without the recent changes. Chuck
On Sat, Jan 3, 2015 at 8:05 AM, Alan G Isaac wrote:
Would this really be practicality beating purity? It would be nice to have know the principle governing this. For example, is there a way to convincingly group these as array operations vs matrix operations? Personally I am puzzled by preserving subtype of `diagonal` and very especially of `ravel`. Has anyone requested this? (I can see the argument for `diag`.)
On 1/3/2015 10:32 AM, Charles R Harris wrote:
In [1]: from astropy import units as u
In [2]: a = eye(2) * u.m
In [3]: a Out[3]: <Quantity [[ 1., 0.], [ 0., 1.]] m>
In [4]: diagonal(a) Out[4]: <Quantity [ 1., 1.] m>
In [5]: diag(a) Out[5]: <Quantity [ 1., 1.] m>
In [6]: ravel(a) Out[6]: <Quantity [ 1., 0., 0., 1.] m>
None of those examples keep the units without the recent changes.
Thanks for a nice example. It seems that the core principle you are proposing is that design considerations generally require that subtypes determine the return types of numpy functions. If that is correct, then it seems matrices should then be subject to this; more special casing of the behavior of matrix objects seems highly undesirable. Cheers, Alan
On Sat, Jan 3, 2015 at 10:54 AM, Alan G Isaac <alan.isaac@gmail.com> wrote:
On Sat, Jan 3, 2015 at 8:05 AM, Alan G Isaac wrote:
Would this really be practicality beating purity? It would be nice to have know the principle governing this. For example, is there a way to convincingly group these as array operations vs matrix operations? Personally I am puzzled by preserving subtype of `diagonal` and very especially of `ravel`. Has anyone requested this? (I can see the argument for `diag`.)
On 1/3/2015 10:32 AM, Charles R Harris wrote:
In [1]: from astropy import units as u
In [2]: a = eye(2) * u.m
In [3]: a Out[3]: <Quantity [[ 1., 0.], [ 0., 1.]] m>
In [4]: diagonal(a) Out[4]: <Quantity [ 1., 1.] m>
In [5]: diag(a) Out[5]: <Quantity [ 1., 1.] m>
In [6]: ravel(a) Out[6]: <Quantity [ 1., 0., 0., 1.] m>
None of those examples keep the units without the recent changes.
Thanks for a nice example. It seems that the core principle you are proposing is that design considerations generally require that subtypes determine the return types of numpy functions. If that is correct, then it seems matrices should then be subject to this; more special casing of the behavior of matrix objects seems highly undesirable
I would agree with you, except that the changes breaks code that uses matrices because matrices are always 2-d whereas the previous results were 1-d. If it were a few not widely used projects I'd stick with it, but scipy.sparse is one of the packages that is broken. Numpy/scipy are not released together, and numpy is often used to compile older versions of scipy, so breaking scipy is undesirable. Becaus we are hoping to phase matrices out over time, preserving the old behavior for matrices until we can dispense with them looks to be the easiest solution. Chuck
On 03/01/15 03:04, Charles R Harris wrote:
The diag, diagonal, and ravel functions have recently been changed to preserve subtypes. However, this causes lots of backward compatibility problems for matrix users, in particular, scipy.sparse. One possibility for fixing this is to special case matrix and so that these functions continue to return 1-d arrays for matrix instances. This is kind of ugly as `a..ravel` will still return a matrix when a is a matrix, an ugly inconsistency. This may be a case where practicality beats beauty.
Thoughts?
What about fixing scipy.sparse? Sturla
On Sat, Jan 3, 2015 at 4:54 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
On 03/01/15 03:04, Charles R Harris wrote:
The diag, diagonal, and ravel functions have recently been changed to preserve subtypes. However, this causes lots of backward compatibility problems for matrix users, in particular, scipy.sparse. One possibility for fixing this is to special case matrix and so that these functions continue to return 1-d arrays for matrix instances. This is kind of ugly as `a..ravel` will still return a matrix when a is a matrix, an ugly inconsistency. This may be a case where practicality beats beauty.
Thoughts?
What about fixing scipy.sparse?
PR already in. The problem is that versions of scipy <=15 will not work with numpy 1.10 if we don't fix this in numpy. Chuck
On Sun, Jan 4, 2015 at 1:28 AM, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Sat, Jan 3, 2015 at 4:54 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
On 03/01/15 03:04, Charles R Harris wrote:
The diag, diagonal, and ravel functions have recently been changed to preserve subtypes. However, this causes lots of backward compatibility problems for matrix users, in particular, scipy.sparse. One possibility for fixing this is to special case matrix and so that these functions continue to return 1-d arrays for matrix instances. This is kind of ugly as `a..ravel` will still return a matrix when a is a matrix, an ugly inconsistency. This may be a case where practicality beats beauty.
Thoughts?
I think it makes sense to special-case matrix here. Arguable, ravel() is an operation that should return a 1-D array (ndarray or other array-like object). np.matrix doesn't allow 1-D objects, hence can't be returned. The method is also documented to return a 1-D array, so maybe the matrix.ravel method is wrong here: In [1]: x = np.matrix(np.eye(3)) In [2]: x.ravel() Out[2]: matrix([[ 1., 0., 0., 0., 1., 0., 0., 0., 1.]]) # 2-D In [3]: print(x.ravel.__doc__) a.ravel([order]) Return a flattened array. Refer to `numpy.ravel` for full documentation. Ralf
What about fixing scipy.sparse?
PR already in. The problem is that versions of scipy <=15 will not work with numpy 1.10 if we don't fix this in numpy.
Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
On Sun, Jan 4, 2015 at 1:44 AM, Ralf Gommers <ralf.gommers@gmail.com> wrote:
On Sun, Jan 4, 2015 at 1:28 AM, Charles R Harris < charlesr.harris@gmail.com> wrote:
On Sat, Jan 3, 2015 at 4:54 PM, Sturla Molden <sturla.molden@gmail.com> wrote:
On 03/01/15 03:04, Charles R Harris wrote:
The diag, diagonal, and ravel functions have recently been changed to preserve subtypes. However, this causes lots of backward compatibility problems for matrix users, in particular, scipy.sparse. One possibility for fixing this is to special case matrix and so that these functions continue to return 1-d arrays for matrix instances. This is kind of ugly as `a..ravel` will still return a matrix when a is a matrix, an ugly inconsistency. This may be a case where practicality beats beauty.
Thoughts?
I think it makes sense to special-case matrix here. Arguable, ravel() is an operation that should return a 1-D array (ndarray or other array-like object). np.matrix doesn't allow 1-D objects, hence can't be returned.
The method is also documented to return a 1-D array, so maybe the matrix.ravel method is wrong here:
In [1]: x = np.matrix(np.eye(3))
In [2]: x.ravel() Out[2]: matrix([[ 1., 0., 0., 0., 1., 0., 0., 0., 1.]]) # 2-D
In [3]: print(x.ravel.__doc__) a.ravel([order])
Return a flattened array.
Refer to `numpy.ravel` for full documentation.
Just to clarify the previous behavior for matrix m. 1) m.diagonal() and m.ravel() both return matrices 2) diagonal(m) and ravel(m) both return 1-D arrays Currently in master, which is incompatible with scipy master 1) m.diagonal() and m.ravel() both return matrices 2) diagonal(m) and ravel(m) both return matrices There is a PR to revert to the previous behavior. Another option is to change m.ravel() to return a 1-D array and leave diagonal(m) returning a matrix. The incompatibilites with diagonal didn't seem to be as troublesome. Chuck
participants (4)
-
Alan G Isaac -
Charles R Harris -
Ralf Gommers -
Sturla Molden