[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Partial Double/Float merge with libgcj
From: |
Chris Gray |
Subject: |
Re: Partial Double/Float merge with libgcj |
Date: |
Mon, 15 Oct 2001 09:55:34 +0200 |
Tom Tromey wrote:
> >>>>> "Mark" == Mark Wielaard <address@hidden> writes:
>
> Mark> Maybe someone who knows a bit about float/doubles in java can
> Mark> comment on these differences.
>
> I don't know if I qualify, but ...
>
I too am not worthy ...
>
> Mark> public static boolean isNaN (double v)
> Mark> {
> Mark> - return (doubleToLongBits (v) == 0x7ff8000000000000L);
> Mark> + long bits = doubleToLongBits (v);
> Mark> + long e = bits & 0x7ff0000000000000L;
> Mark> + long f = bits & 0x000fffffffffffffL;
> Mark> +
> Mark> + return e == 0x7ff0000000000000L && f != 0L;
> Mark> }
>
> I think this is a remnant of when libgcj's doubleToLongBits would
> return the actual raw value instead of turning all NaNs into a single
> value. Both implementations are correct, but the Classpath
> implementation is more desirable.
>
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.
Chris Gray
VM Architect, ACUNIA