[Numpy-discussion] What is the logical value of nan?

[Charles R Harris]

On Wed, Mar 11, 2009 at 11:06 AM, Christopher Barker
<Chris.Barker at noaa.gov>wrote:

> Sturla Molden wrote:
> > Why not raise an exception when NaN is evaluated in a boolean
> > context? bool(NaN) has no obvious interpretation, so it should be
> > considered an error.
>
> +1
>
> Though there is clearly a lot of legacy around this, so maybe it's best
> to follow C convention (sigh).
>
> Bruce Southey wrote:
> > Also, I think that conversion to an integer should be an error for
> > all of these because there is no equivalent representation of these
> > floating point numbers as integers and I think that using zero for
> > NaN is wrong.
>
> +1
>
> A silent wrong conversion is MUCH worse than an exception!
>
> As for MATLAB, it was entirely doubles for a long time -- I don't think
> it's a good example of well thought-out float<->integer interactions.
>
>
> > Now for the other two special representations, I would presume that
> > Numpy's PZERO (positive zero) and NZERO (negative zero) are treated
> > as nothing. Conversion to integer for these should be zero.
>
> +1
>
> > Note this defines the min/max behavior:
> >
> > * |min(x,NaN) = min(NaN,x) = x| * |max(x,NaN) = max(NaN,x) = x|
>
> nice -- it's nice to have these defined -- of course, who knows how long
> it will be (never?) before compilers/libraries support this.
>

Raising exceptions in ufuncs is going to take some work as the inner loops
are void functions without any means of indicating an error.  Exceptions
also need to be thread safe. So I am not opposed but it is something for the
future.

Casting seems to be implemented in arraytypes.inc.src as void functions also
without provision for errors. I would also like to see casting implemented
as ufuncs but that is a separate discussion.

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