On Wed, Jul 02, 2008 at 10:55:12PM +0200, Stéfan van der Walt wrote: > 2008/7/2 Zbyszek Szmek <[EMAIL PROTECTED]>: > >> That's Ticket #709 <http://projects.scipy.org/scipy/numpy/ticket/709>: > >> > >> > I'm faily sure that: > >> > numpy.isnan(datetime.datetime.now() > >> > ...should just return False and not raise an exception. > > IMHO numpy.isnan() makes no sense for non-numerical types. > > I agree with Chuck's rationale [if someone asks me whether a peanut > butter sandwhich is a Koala bear, then I'd say no, without trying to > cast the sandwhich to a mammal], and it seems that other ufuncs try to > be general this way, e.g. np.add handles arbitrary classes with > __add__ methods. Exactly, you can add things only when they are numerical or when you have defined __add__, otherwise it's a TypeError. If it was important and general enough, we could add an attribute __isnan__, and extend isnan-iness to other things, but it probably isn't.
The operator 'is' makes sense for both mammals and sandwiches, so the statement 'a butter sandwich is a Koala' makes sense. I would compare isnan-iness to asking if 'a butter sandwich is even-toed'? It is defined for some mammals, and doesn't have a definite value for other things. Defining isnan for arbitrary objects seems a workaround for passing objects to a wrong place function and pollution of code with a kludge for a special case. Cheers, Zbyszek _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion
