-
-
Notifications
You must be signed in to change notification settings - Fork 11.1k
Closed
Description
I'm writing some additional error handling code in numba/numba#2737 for Numba's np.linalg
implementation, specifically to handle arrays with dimensions of size zero.
In doing this I've noticed that NumPy 1.10, 1.11 and 1.12 have one set of behaviours and NumPy 1.13 and 1.14 another, and this applies to most functions in np.linalg
with 0d
array(s) as input. As a quick example, running this:
import numpy as np
print(np.__version__)
print(np.linalg.pinv(np.empty(shape=(0, 0))))
over NumPy versions 1.10...1.14:
Testing Numpy Version: 10
1.10.4
Traceback (most recent call last):
File "demo.py", line 3, in <module>
print(np.linalg.pinv(np.empty(shape=(0, 0))).shape)
File "<path>lib/python3.5/site-packages/numpy/linalg/linalg.py", line 1615, in pinv
_assertNoEmpty2d(a)
File "<path>lib/python3.5/site-packages/numpy/linalg/linalg.py", line 222, in _assertNoEmpty2d
raise LinAlgError("Arrays cannot be empty")
numpy.linalg.linalg.LinAlgError: Arrays cannot be empty
Testing Numpy Version: 11
1.11.3
Traceback (most recent call last):
File "demo.py", line 3, in <module>
print(np.linalg.pinv(np.empty(shape=(0, 0))).shape)
File "<path>lib/python3.6/site-packages/numpy/linalg/linalg.py", line 1615, in pinv
_assertNoEmpty2d(a)
File "<path>lib/python3.6/site-packages/numpy/linalg/linalg.py", line 222, in _assertNoEmpty2d
raise LinAlgError("Arrays cannot be empty")
numpy.linalg.linalg.LinAlgError: Arrays cannot be empty
Testing Numpy Version: 12
1.12.1
Traceback (most recent call last):
File "demo.py", line 3, in <module>
print(np.linalg.pinv(np.empty(shape=(0, 0))).shape)
File "<path>lib/python3.6/site-packages/numpy/linalg/linalg.py", line 1660, in pinv
_assertNoEmpty2d(a)
File "<path>lib/python3.6/site-packages/numpy/linalg/linalg.py", line 222, in _assertNoEmpty2d
raise LinAlgError("Arrays cannot be empty")
numpy.linalg.linalg.LinAlgError: Arrays cannot be empty
Testing Numpy Version: 13
1.13.3
(0, 0)
Testing Numpy Version: 14
1.14.0
(0, 0)
I think there are three things for discussion:
- Should the current behaviour be considered stable?
- The handling of these
0d
inputs appears to just be an artifact of the implementation and I wonder if in fact it would be better to simply raise if such an input is presented so that the behaviour is invariant of (future) refactoring of the implementation detail. - As far as I'm aware there is no defined mathematical behaviour for these
0d
cases and probably no sensible interpretation. For examplenp.linalg.eig(np.empty((0, 0))
, there's no characteristic polynomial to find the roots of for a system with no dimension, what should happen!?
Thanks.
Metadata
Metadata
Assignees
Labels
No labels