On Mon, Sep 29, 2008 at 10:09 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Charles R Harris wrote:
>
> Yes, that too. But I was thinking of the ufunc returning nan when needed

 


I think this is better for consistency, yes. NaN is not a number, so it
has no sign :) More seriously, I think those features should be clearly
listed and thought out before being implemented, particularly wrt error
handling and testing. I would rather see umathmodule.c cleaning first,

umathmodule.c is cleaned/done. Or was until I put in some of the nan handling. But some of the nan comparisons were just odd, in particular the sign function, which was effectively undefined. And since the current behavior is an accident of comparison choices and order, I consider it undefined also. So at a minimum I would fix up sign/maximum/minimum. That would be consistent with both masking and error propagation in common usage. The curiosities arise when using the reduce method. Also returning -1 for the signbit seems like the right thing to do. If the nan comparisons can't be relied on, then using the isnan macro is an option. However, I am not inclined to go on and use isfinite and all those.


wo any functionality change, and then, once integrated in the trunk, do
the NaN changes in a branch, in particular because of broken
implementations which will not do what you expect. Personally, I also
have changes for NaN handling, but on my private git import of numpy.

I'm am currently working off your branch (at your suggestion). Is it safe to use NAN?


Also, if we fix this, we should fix this once for all, and with a lot of
tests, if only to test on buggy implementations.

Yes, the tests will define the standard. There is one test for sign of complex numbers that currently breaks, but I don't consider that important as anyone currently relying on sign when the array contains nans is out of their mind. An option for making the code more portable is to make the various comparison operators macros, then worry about fixing the macros for various compilers. I would be happy to use macros such as lessthan, which in addition to other things are not supposed to raise exceptions. Of course, if MS compilers don't even get the arithmetic right...

Chuck