[Numpy-discussion] Should we fix Ticket #709?

Zbyszek Szmek zbyszek@in.waw...
Thu Jul 3 04:25:08 CDT 2008

On Wed, Jul 02, 2008 at 10:55:12PM +0200, Stéfan van der Walt wrote:
> 2008/7/2 Zbyszek Szmek <zbyszek@in.waw.pl>:
> >> 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.


More information about the Numpy-discussion mailing list