Name: swC45995 Date: 01/28/97


In Windows NT the compiler wrongly converts floating-point literals to
internal representation. In the case of loss of precision it uses the
round to zero mode instead of round to nearest. Meanwhile JLS says:

The details of proper input conversion from a Unicode string representation
of a floating-point number to the internal IEEE 754 binary floating-point
representation are described for the methods valueOf of class Float)
and class Double of the package java.Lang. (#3.10.2)

... exact decimal value is ... conceptually converted to an "infinitely
precise" binary value that is then rounded to type double by the usual
round-to-nearest rule of IEEE 754 floating-point arithmetic (#20.10.16).

Thus compilation and subsequent execution of the test:

public class test
{
public static void main(String argv[])
{
long l = 0x003FFFFFFFFFFFFFl;

System.out.println(
Long.toHexString(
Double.doubleToLongBits(
(double)18014398509481983l)));
System.out.println(
Long.toHexString(
Double.doubleToLongBits((double)l)));
System.out.println(
Long.toHexString(
Double.doubleToLongBits(18014398509481983.0d)));
System.out.println(
Long.toHexString(
Double.doubleToLongBits(
Double.valueOf("18014398509481983.0d").
doubleValue())));
}
}

produces the following output:

novo40% javac test.java
novo40% java test
4350000000000000
4350000000000000
434fffffffffffff
434fffffffffffff

instead of expected:

4350000000000000
4350000000000000
4350000000000000
4350000000000000

======================================================================