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

David Cournapeau cournape@gmail....
Wed Mar 11 14:28:14 CDT 2009

On Thu, Mar 12, 2009 at 3:36 AM, Charles R Harris
<charlesr.harris@gmail.com> wrote:
> On Wed, Mar 11, 2009 at 12:19 PM, Sturla Molden <sturla@molden.no> wrote:
>> Charles R Harris wrote:
>> >
>> > 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.
>> >
>> I just saw David Cournapeau's post regarding a NPY_NAN macro. As it uses
>> the IEEE754 binary format, at least NPY_NAN should be True in a boolean
>> context. So bool(nan) is True then.
>> And that's what happens now on my computer as well:
>>  >>> bool(nan)
>> True
>> I don't like Python exception's raised inside ufuncs. In the future we
>> NumPy might add OpenMP support to ufuncs (multicore CPUs are getting
>> common), and Python exceptions would prevent that, or at least make it
>> difficult (cf. the GIL).
> I think numpy needs someway to raise these errors, but error handling is
> always tricky. Do you have any suggestions as to how you would like to do
> it? I was thinking that adding an int return to the loops would provide some
> way of indicating errors without specifying how they were to be handled at
> this point.

I think that we should think carefully about how to set up a good
error system within numpy. If we keep adding ad-hoc error handling, I
am afraid it will be hard to read and maintain. We could have
something like:

typedef struct
    int             error ;
    const char      *str ;
} ErrorStruct ;

ErrorStruct UfuncErrors [] =
{ {CODE1, "error 1 string"}, ...};

and the related functions to get strings from code. Currently, we
can't really pass errors through several callees because we don't have
a commonly agreed set of errors. If we don't use an errno, I don't
think there are any other options,


More information about the Numpy-discussion mailing list