8000 Zero sized dimension array handling in np.linalg · Issue #10573 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

Zero sized dimension array handling in np.linalg #10573

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Closed
stuartarchibald opened this issue Feb 12, 2018 · 7 comments
Closed

Zero sized dimension array handling in np.linalg #10573

stuartarchibald opened this issue Feb 12, 2018 · 7 comments

Comments

@stuartarchibald
Copy link
Contributor

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:

  1. Should the current behaviour be considered stable?
  2. 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.
  3. As far as I'm aware there is no defined mathematical behaviour for these 0d cases and probably no sensible interpretation. For example np.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.
@stuartarchibald stuartarchibald mentioned this issue Feb 12, 2018
Merged
@pv
Copy link
Member
pv commented Feb 12, 2018 via email

@stuartarchibald
Copy link
Contributor Author

@pv thanks, looks like:

  1. No. There are outstanding implementations to be dealt with?
  2. No. Try and use correct definitions instead.
  3. I stand corrected, there are some definitions that are applicable. It is unusual but in some places valid, even if e.g. LAPACK doesn't always handle it natively.

If this ticket is of no value let's close it?

@eric-wieser
Copy link
Member
eric-wieser commented Feb 12, 2018 via email

@stuartarchibald
Copy link
Contributor Author

Thanks @eric-wieser, I'll try and remember to use the terminology/syntax you use for next time :)

FWIW I've finished patching Numba and it now replicates what happens in np>=1.13 only, as behaviour before #8368 was less well defined.

@seberg
Copy link
Member
seberg commented Feb 15, 2018

Yeah, I think by now with Erics last bit of work we got the empty array cases to where we want them (mostly earlier, this is also a trend for some other functions, though probably less likely to run into that).

If you find something we should rethink please say so, otherwise it seems we are all happy with the new behaviour and agree it is what numba should try to replicate. I am not sure that those we have not yet defined always have an "obvious" result for empty arrays, but if they do, can you open a new issue about it (or maybe we have one already, heh)?

Cl A95C osing this I think, but a new issue for functions that do not yet have proper empty array handling would be great. Thanks!

@seberg seberg closed this as completed Feb 15, 2018
@stuartarchibald
Copy link
Contributor Author

Thanks for the info @seberg. I think I've managed to replicate everything that went into #8368 and continue to replicate the exceptions for functions that are not currently patched. If it's useful I can open a ticket based on the script I wrote to probe the behaviour of all the linalg functions for empty 2d arrays, disregarding those that have already been patched?

@seberg
Copy link
Member
seberg commented Feb 15, 2018

Sure, we won't change old behaviour. IIRC for some functions it was not quite trivial to find the "correct" non-error behaviour though, but I guess not all remaining ones fall into that category.

I think the simple list would suffice, its not like we are likely to add many new functions soon anyway.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@pv @seberg @eric-wieser @stuartarchibald
0