Robert wrote: > 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. >>
coming to mind another way to see it: I'm not aware of any other python type which doesn't definitely know if it is __nonzero__ or not (unless there is an IOError or so). And everywhere: if there is *any* logical doubt at all, the default is: True! - not an Exception. For example .__nonzero__/.__bool__ for a custom class defaults to True. A behavior where an object throws an exception upon __nonzero__ test just because of principal doubts seems not to fit into the Python world. The non-zero test must definitely go through. Only 2 ways seem to be consistently Pythonic and logical: "size > 0"; or "any(a)" (*); and the later option may be more 'numerical'. Robert * .__nonzero__() and perhaps .any() too should not fail upon flexible types like currently: >>> np.array(["","",""]).any() Traceback (most recent call last): File "<interactive input>", line 1, in <module> TypeError: cannot perform reduce with flexible type >>> _______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
