Re: [Numpy-discussion] np.sign and object comparisons

[Stephan Hoyer]

On Mon, Aug 31, 2015 at 1:23 AM, Sebastian Berg 
wrote:

> That would be my gut feeling as well. Returning `NaN` could also make
> sense, but I guess we run into problems since we do not know the input
> type. So `None` seems like the only option here I can think of right
> now.
>

My inclination is that return NaN would be the appropriate choice. It's
certainly consistent with the behavior for float dtypes -- my expectation
for object dtype behavior is that it works exactly like applying the
np.sign ufunc to each element of the array individually.

On the other hand, I suppose there are other ways in which an object can
fail all those comparisons (e.g., NaT?), so I suppose we could return None.
But it would still be a weird outcome for the most common case. Ideally, I
suppose, np.sign would return an array with int-NA dtype, but that's a
whole different can of worms...

Stephan
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] np.sign and object comparisons

[Antoine Pitrou]

On Mon, 31 Aug 2015 10:23:10 -0700
Stephan Hoyer  wrote:
> 
> My inclination is that return NaN would be the appropriate choice. It's
> certainly consistent with the behavior for float dtypes -- my expectation
> for object dtype behavior is that it works exactly like applying the
> np.sign ufunc to each element of the array individually.
> 
> On the other hand, I suppose there are other ways in which an object can
> fail all those comparisons (e.g., NaT?), so I suppose we could return None.

Currently:

>>> np.sign(np.timedelta64('nat'))
numpy.timedelta64(-1)

... probably because NaT is -2**63 under the hood. But in this case
returning NaT would sound better.

Regards

Antoine.


___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] np.sign and object comparisons

[Sebastian Berg]

On Mo, 2015-08-31 at 10:23 -0700, Stephan Hoyer wrote:
> On Mon, Aug 31, 2015 at 1:23 AM, Sebastian Berg
>  wrote:
> That would be my gut feeling as well. Returning `NaN` could
> also make
> 
> sense, but I guess we run into problems since we do not know
> the input
> type. So `None` seems like the only option here I can think of
> right
> now.
> 
> 
> My inclination is that return NaN would be the appropriate choice.
> It's certainly consistent with the behavior for float dtypes -- my
> expectation for object dtype behavior is that it works exactly like
> applying the np.sign ufunc to each element of the array individually.
> 

I was wondering a bit if returning the original object could make sense.
It would work for NaN (and also decimal versions of NaN, etc.). But I am
not sure in general.

- Sebastian

> 
> On the other hand, I suppose there are other ways in which an object
> can fail all those comparisons (e.g., NaT?), so I suppose we could
> return None. But it would still be a weird outcome for the most common
> case. Ideally, I suppose, np.sign would return an array with int-NA
> dtype, but that's a whole different can of worms...
> 
> 
> Stephan
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion

Re: [Numpy-discussion] np.sign and object comparisons

[Sebastian Berg]

On So, 2015-08-30 at 21:09 -0700, Jaime Fernández del Río wrote:
> There's been some work going on recently on Py2 vs Py3 object
> comparisons. If you want all the background, see gh-6265 and follow
> the links there.
> 
> 
> There is a half baked PR in the works, gh-6269, that tries to unify
> behavior and fix some bugs along the way, by replacing all 2.x uses of
> PyObject_Compare with several calls to PyObject_RichCompareBool, which
> is available on 2.6, the oldest Python version we support.
> 
> 
> The poster child for this example is computing np.sign on an object
> array that has an np.nan entry. 2.x will just make up an answer for
> us:
> 
> 
> >>> cmp(np.nan, 0)
> -1
> 
> 
> even though none of the relevant compares succeeds:
> 
> 
> >>> np.nan < 0
> False
> >>> np.nan > 0
> 
> False
> >>> np.nan == 0
> 
> False
> 
> 
> The current 3.x is buggy, so the fact that it produces the same made
> up result as in 2.x is accidental:
> 
> 
> >>> np.sign(np.array([np.nan], 'O'))
> array([-1], dtype=object)
> 
> 
> Looking at the code, it seems that the original intention was for the
> answer to be `0`, which is equally made up but perhaps makes a little
> more sense.
> 
> 
> There are three ways of fixing this that I see:
>  1. Arbitrarily choose a value to set the return to. This is
> equivalent to choosing a default return for `cmp` for
> comparisons. This preserves behavior, but feels wrong.
>  2. Similarly to how np.sign of a floating point array with nans
> returns nan for those values, return e,g, None for these
> cases. This is my preferred option.

That would be my gut feeling as well. Returning `NaN` could also make
sense, but I guess we run into problems since we do not know the input
type. So `None` seems like the only option here I can think of right
now.

- Sebastian


>  1. Raise an error, along the lines of the TypeError: unorderable
> types that 3.x produces for some comparisons.
> Thoughts anyone?
> 
> 
> Jaime
> -- 
> 
> (\__/)
> ( O.o)
> ( > <) Este es Conejo. Copia a Conejo en tu firma y ayúdale en sus
> planes de dominación mundial.
> ___
> NumPy-Discussion mailing list
> NumPy-Discussion@scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion



signature.asc
Description: This is a digitally signed message part
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion