Re: Partial Double/Float merge with libgcj

[Eric Blake]

Shoot, I meant to hit reply-to-all.

Eric Blake wrote:
> 
> Chris Gray wrote:
> >
> >
> > An interesting twist on this: jikes seems to have its own idea of the 
> > correct
> > bit-pattern for NaN (0xffc00000 instead of 0x7fc0000).  This shouldn't 
> > matter
> > if all NaN's are canonicalized to the same value.
> 
> Which version of jikes? My guess is version 1.13 or sooner, as floating
> point emulation mode was made default in later versions. When doing
> floating point emulation jikes should always spit out 0x7fc00000 for
> Float.NaN, but with native math, it uses whatever the CPU thinks is NaN
> (which for x86 architecture is 0xffc00000).  But you are right, as long
> as Float.floatToLongBits canonicalizes NaN, there should be no problem
> with the current algorithm.
> 
> However, I argue that this is a faster implementation (it avoids a
> native call):
> 
> public static boolean isNaN(double v)
> {
>   return v != v;
> }
> 
> This works since NaN != NaN is the only reflexive inequality comparison
> which returns true.

-- 
This signature intentionally left boring.

Eric Blake             address@hidden
  BYU student, free software programmer