Re: Math patch

[Chris Gray]

On Thu, 27 Feb 2003, David P Grove wrote:

> > [CG]
> > 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).

OTOH JIT *is* a runtime cost. In principle the static method could be 
inlined by a static analysis tool, but I don't believe a bytecode compiler 
is allowed to do it - it should leave open the possibility that the code 
will be deployed against a different version of java.lang.Math to that 
against which it was compiled. SFAIK the only legitimate inlining a 
bytecode compiler can do is for static final constants.

That's why one can sometimes get nostalgic for #define. :)

-- 

Chris Gray

VM Architect, ACUNIA