[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Math patch (Chris Gray)
From: |
David P Grove |
Subject: |
Re: Math patch (Chris Gray) |
Date: |
Thu, 27 Feb 2003 12:50:39 -0500 |
> 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
- Re: Math patch (Chris Gray),
David P Grove <=