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

[Charles R Harris]

On Wed, Mar 11, 2009 at 11:41 AM, Charles R Harris <
charlesr.harris at gmail.com> wrote:

>
>
> 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.
>

Hmm, I don't really want to see type conversions go through all the calling
machinery of ufuncs.
Let's say I'd like to see the kind of inner loops used for ufuncs also used
for type conversions. So I would see introducing exceptions starting with at
least two steps:

1) Have ufunc type loops return an integer error code. This should just
involve replacing void with int and returning 0 in the current loops.

2) Change the type conversion loops to ufunc type loops.

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