[Numpy-discussion] Sign of NaN

Allan Haldane allanhaldane at gmail.com
Tue Sep 29 18:28:12 EDT 2015


On 09/29/2015 02:16 PM, Nathaniel Smith wrote:
> On Sep 29, 2015 8:25 AM, "Anne Archibald" <archibald at astron.nl
> <mailto:archibald at astron.nl>> wrote:
>>
>> IEEE 754 has signum(NaN)->NaN. So does np.sign on floating-point
> arrays. Why should it be different for object arrays?
> 
> The argument for doing it this way would be that arbitrary python
> objects don't have a sign, and the natural way to implement something
> like np.sign's semantics using only the "object" interface is
> 
> if obj < 0:
>     return -1
> elif obj > 0:
>     return 1
> elif obj == 0:
>     return 0
> else:
>     raise
> 
> In general I'm not a big fan of trying to do all kinds of guessing about
> how to handle random objects in object arrays, the kind that ends up
> with a big chain of type checks and fallback behaviors. Pretty soon we
> find ourselves trying to extend the language with our own generic
> dispatch system for arbitrary python types, just for object arrays. (The
> current hack where for object arrays np.log will try calling obj.log()
> is particularly horrible. There is no rule in python that "log" is a
> reserved method name for "logarithm" on arbitrary objects. Ditto for the
> other ufuncs that implement this hack.)
> 
> Plus we hope that many use cases for object arrays will soon be
> supplanted by better dtype support, so now may not be the best time to
> invest heavily in making object arrays complicated and powerful.

Even though I submitted the PR to make object arrays more powerful, this
makes a lot of sense to me.

Let's say we finish a new dtype system, in which (I imagine) each dtype
specifies how to calculate each ufunc elementwise for that type. What
are the remaining use cases for generic object arrays? The only one I
see is having an array with elements of different types, which seems
like a dubious idea anyway. (Nested ndarrays of varying length could be
implemented as a dtype, as could the PyFloatDtype Sebastian mentioned,
without need for a generic 'object' dtype which has to figure out how
to call ufuncs on individual objects of different type).

Allan



More information about the NumPy-Discussion mailing list