Neil Martinsen-Burrell wrote:
On 2009-09-07 07:11 , Robert wrote:
Is there a reason why ndarray truth tests (except scalars) deviates from the convention of other Python iterables list,array.array,str,dict,... ?
Furthermore there is a surprising strange exception for arrays with size 1 (!= scalars).
Historically, numpy's predecessors used "not equal to zero" as the meaning for truth (consistent with numerical types in Python). However, this introduces an ambiguity as both any(a != 0) and all(a != 0) are reasonable interpretations of the truth value of a sequence of numbers.
well, I can familiarize with that "not equal to zero" philosophy for a math-centric array type (different from a container / size>0 philosophy) However I don't see that all(a) (or "all(a != 0)") is something which anybody would ever expect with .__nonzero__() / if a: ... . Does anybody? And the current behavior with all those strange exceptions and exceptions from exceptions still seems awkward and unnecessary. The any() interpretion is outstandingly "right" in my opinion, and doesn't need to be guessed: anything/any part non-zero disturbs the clean "zeroness". Zero must be wholly pure zero. This is so everywhere in math and informatics. a number/memory is zero when all bits/bytes are zero. a matrix is a zero matrix when all elements are zero... This way only the test is also seamlessly consistent with a zero length array (while all(zerolengtharray != 0) would be True surprisingly!) This kind of any(a) truth test (only) is also often needed, and it would be also fast executable this way. It would be compatible with None/False init/default variable tests during code evolution in Python style and would behave well everywhere as far as I can see. It would also not break old code. Would a feature request in that direction have any chance? Robert
Numpy refuses to guess and raises the exception shown below. For sequences with a single item, there is no ambiguity and numpy does the (numerically) ordinary thing.
The ndarray type available in Numpy is not conceptually an extension of Python's iterables. If you'd like to help other Numpy users with this issue, you can edit the documentation in the online documentation editor at http://docs.scipy.org/numpy/docs/numpy-docs/user/index.rst
-Neil