Re: Math patch (Chris Gray)

[David P Grove]

> 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