On Thu, Mar 12, 2009 at 3:36 AM, Charles R Harris
<charlesr.har...@gmail.com> wrote:
>
>
> On Wed, Mar 11, 2009 at 12:19 PM, Sturla Molden <stu...@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 ;
static
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,
David
_______________________________________________
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
