On Sun, Jul 20, 2008 at 3:47 PM, Robert Kern <robert.kern@gmail.com> wrote:

On Sun, Jul 20, 2008 at 17:42, Charles R Harris
<charlesr.harris@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:

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)


Hmmm,

Chuck