[Numpy-discussion] Why is the truth value of ndarray not simply size>0 ?

Robert kxroberto at googlemail.com
Sun Sep 13 06:30:58 EDT 2009


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




More information about the NumPy-Discussion mailing list