[Numpy-discussion] Ticket #794 and can o' worms.

Charles R Harris charlesr.harris at gmail.com
Mon Jul 21 00:45:14 EDT 2008


On Sun, Jul 20, 2008 at 10:41 PM, Charles R Harris <
charlesr.harris at gmail.com> wrote:

>
>
> On Sun, Jul 20, 2008 at 8:32 PM, Timothy Hochberg <tim.hochberg at ieee.org>
> wrote:
>
>>
>>
>> On Sun, Jul 20, 2008 at 3:47 PM, Robert Kern <robert.kern at gmail.com>
>> wrote:
>>
>>> On Sun, Jul 20, 2008 at 17:42, Charles R Harris
>>> <charlesr.harris at gmail.com> wrote:
>>> > Hi All,
>>> >
>>> > I "fixed" ticket #754, but it leads to a ton of problems. The original
>>> > discussion is here. The problems that arise come from conversion to
>>> > different types.
>>> >
>>> > In [26]: a
>>> > Out[26]: array([ Inf, -Inf,  NaN,   0.,   3.,  -3.])
>>> >
>>> > In [27]: sign(a).astype(int)
>>> > Out[27]:
>>> > array([          1,          -1, -2147483648,           0,           1,
>>> >                 -1])
>>> >
>>> > In [28]: sign(a).astype(bool)
>>> > Out[28]: array([ True,  True,  True, False,  True,  True], dtype=bool)
>>> >
>>> > In [29]: sign(a)
>>> > Out[29]: array([  1.,  -1.,  NaN,   0.,   1.,  -1.])
>>> >
>>> > In [30]: bool(NaN)
>>> > Out[30]: True
>>> >
>>> > So there are problems with at minimum the following.
>>> >
>>> > 1) The way NaN is converted to bool. I think it should be False.
>>>
>>> It's not really our choice. That's Python's bool(). For the things
>>> that are our choice (e.g. array([nan]).astype(bool)) I think we should
>>> stay consistent with Python.
>>>
>>
>> <DELURK>
>>
>> I agree that this is a good goal. However, in the past, Python's treatment
>> of NaNs has been rather platform dependent and add hock. In this case, I
>> suspect that you are OK since the section  "Truth Value Testing" in the
>> Python docs is pretty clear that any non-zero value of a numerical type is
>> True.
>>
>> However...
>>
>>
>>>
>>> > 2) The way NaN is converted to int types. I think it should be 0.
>>>
>>> I agree. That's what int(nan) gives:
>>>
>>> >>> int(nan)
>>> 0L
>>
>>
>>
>> This is GvR in
>> http://mail.python.org/pipermail/python-dev/2008-January/075865.html:
>>
>
> Well, now, that opens a whole other bag of toasted scorpions.
>
> It looks like long(inf) and int(inf) already raise OverflowError and
>> that should stay.
>>
>
> In [3]: (ones(2)*float(inf)).astype(int8)
> Out[3]: array([0, 0], dtype=int8)
>
> In [4]: (ones(2)*float(inf)).astype(int32)
>
> Out[4]: array([-2147483648, -2147483648])
>
> In [5]: (ones(2)*float(inf)).astype(int64)
> Out[5]: array([-9223372036854775808, -9223372036854775808], dtype=int64)
>
>
Also,

In [8]: (ones(2)*float(inf)).astype(uint8)
Out[8]: array([0, 0], dtype=uint8)

In [9]: (ones(2)*float(inf)).astype(uint16)
Out[9]: array([0, 0], dtype=uint16)

In [10]: (ones(2)*float(inf)).astype(uint32)
Out[10]: array([0, 0], dtype=uint32)

In [11]: (ones(2)*float(inf)).astype(uint64)
Out[11]: array([0, 0], dtype=uint64)

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080720/15f26cf6/attachment.html>


More information about the NumPy-Discussion mailing list