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

[Timothy Hochberg]

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:

*If long(nan) or int(nan) returns 0 on most platforms in 2.5, we should*
*fix them to always return 0 in 2.5 *and* 2.6. In 3.0 they should raise*
*ValueError.*

This implies that in version 2.4 and earlier, the Python behaviour is
platform dependent. And that 3.0 this is going to change to raise a
ValueError. Whether it's more important to match current behaviour (return
0) or future behaviour (raise ValueError), I'm not certain. I would lean
towards a ValueError since it's less long term pain and it's IMO more
correct.




>
>
> --
> Robert Kern
>
> "I have come to believe that the whole world is an enigma, a harmless
> enigma that is made terrible by our own mad attempt to interpret it as
> though it had an underlying truth."
>  -- Umberto Eco
> _______________________________________________
> Numpy-discussion mailing list
> Numpy-discussion at scipy.org
> http://projects.scipy.org/mailman/listinfo/numpy-discussion
>



-- 
. __
. |-\
.
. tim.hochberg at ieee.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20080720/fc3891ec/attachment.html>