> This is an old chestnut. ;) For some VMs, Double.isNaN() will translate
to
> an (expensive) JNI method call. For others it's no big deal. So on the
> whole "a != a" seems like the better bet. Hm, I see Wonka's
java.lang.Math
> contains 21 "a != a" constructs and 2 "Double.isNaN(a)"'s. :-/
>
> What we really need is
> #define isNaN(a) ((a) != (a))
I thought we had this already because the classpath Double.isNaN is defined
as:
/**
* Return <code>true</code> if the <code>double</code> has the same
* value as <code>NaN</code>, otherwise return <code>false</code>.
*
* @param v the <code>double</code> to compare
* @return whether the argument is <code>NaN</code>.
*/
public static boolean isNaN(double v)
{
// This works since NaN != NaN is the only reflexive inequality
// comparison which returns true.
return v != v;
}
So, it seems to me that using isNaN should be preferred as it is clearer
and will have no runtime cost (any JIT should inline a trivial static
method like this).
--dave
_______________________________________________
Classpath mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/classpath