Repository navigation
numpy.sign behaves oddly when dtype is numpy.object #6229
Description
In [1]: import numpy
In [2]: foo = numpy.array([-.1, 0, .1])
In [3]: numpy.sign(foo)
Out[3]: array([-1., 0., 1.])
In [4]: numpy.sign(foo.astype(numpy.object))
Out[4]: array([1, -1, -1], dtype=object)
The underlying data is still just a float:
In [5]: type(foo.astype(numpy.object)[0])
Out[5]: float
This result when using an array of numpy.object does not seem desirable. Either it should operate correctly on the underlying numbers or if called with invalid data (strings, etc) it should throw an exception. This way I could populate an array with heterogeneous data, say a mix of integers and floats, and still get a valid result.
I tested this on:
Mac OS 10.6.8
Python 3.4.2
numpy 1.9.2
Activity
ewmoore commentedon Aug 21, 2015
Looks like
OBJECT_signis missing the logic to return0for0. Compare with BYTE_sign.atomicpirate commentedon Aug 21, 2015
Right--zero didn't get a zero result, negative results in +1, positive results in -1. The results for numpy.object seem incorrect on all counts.
pv commentedon Aug 21, 2015
I can't reproduce your example. get:
.
In [7]: numpy.sign(foo.astype(numpy.object))
array([-1, 0, 1], dtype=object)
In [12]: numpy.version
'1.9.2'
pv commentedon Aug 21, 2015
Ah ok, the incorrect results occur on Python 3 only.
pv commentedon Aug 21, 2015
Hah, it's a stupid bug, the
== 0should be== 1here https://github.com/numpy/numpy/blob/master/numpy/core/include/numpy/npy_3kcompat.h#L328jaimefrio commentedon Aug 21, 2015
There, and it the two other checks below it, right?
pv commentedon Aug 21, 2015
springcoil commentedon Aug 26, 2015
Is this still open - it looks like an easy fix could be done.
charris commentedon Feb 20, 2016
Closed by #6269.
MAINT: Deprecated PyObject_Compare in favor of PyObject_RichCompareBo…