On Mon, Sep 29, 2008 at 11:20 PM, Robert Kern <robert.kern@gmail.com> wrote:
On Mon, Sep 29, 2008 at 20:22, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Mon, Sep 29, 2008 at 4:28 PM, Robert Kern <robert.kern@gmail.com>
wrote:
On Mon, Sep 29, 2008 at 17:13, Charles R Harris <charlesr.harris@gmail.com> wrote:
On Mon, Sep 29, 2008 at 3:52 PM, Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
I've been cleaning up the ufunc loops and the sign function currently doesn't have a defined behavior for nans. This makes the results
depend
on the order/type of comparisons in the code, which looks fragile to me. So what should it return? I vote for nan but am open for suggestions.
And while we're at it, lets decide how to treat max/min when nans are involved. Or should we just say the behavior is undefined.
When feasible, I would like float(s)->float functions to return NaN when given a NaN as an argument. At least as the main versions of the function. Specific NaN-ignoring functions can also be introduced, but as separate functions. I don't know what exactly to do about float->int functions (e.g. argmin). I also don't know how these should interact with the current seterr() state.
OK, maximum, minimum, and sign now return NaN.
Oops!
F.9.9.2 The fmax functions 1 If just one argument is a NaN, the fmax functions return the other argument (if both arguments are NaNs, the functions return a NaN). 2 The body of the fmax function might be {return (isgreaterequal(x, y) || isnan(y)) ? x : y; }
If we want to follow C99 semantics rather than our own NaN-always-propagates semantics, then we should do this instead.
That would have the virtue that amax/amin would return the actual max and min of the non nan numbers. Unless all of them were nans, in which case we would get the starting value, which should probabably be nan in this case ;) Hey, that would work nicely. So, I think I should use the comparison macros for the floats. However, if I read correctly, they don't raise exceptions. Would that be a problem? Chuck