classpath
[Top][All Lists]
Advanced

[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





reply via email to

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