[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Partial Double/Float merge with libgcj

From: Eric Blake
Subject: Re: Partial Double/Float merge with libgcj
Date: Mon, 15 Oct 2001 15:51:32 -0600

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]