[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