Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-4396272

Parsing doubles fails to follow IEEE for largest decimal that should yield 0

    Details

    • Subcomponent:
    • CPU:
      x86
    • OS:
      windows_98, windows_vista

      Backports

        Description

        Name: boT120536 Date: 12/07/2000


        java version "1.3.0"
        Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.0-C)
        Java HotSpot(TM) Client VM (build 1.3.0-C, mixed mode)



        Using java.math.BigDecimal, I found the exact decimal value of Double.MIN_VALUE
        / 2, listed below. This number is exactly halfway between two IEEE754 doubles
        (Double.longBitsToDouble(0x1L) and Double.longBitsToDouble(0x0L)), so it should
        round to the version with least significant bit 0. However, this would mean it
        rounds to 0, which is invalid, by JLS 3.10.2. Therefore, this number should
        produce a compile-time error.

        Adding any non-zero digits at the end of the decimal listing make the literal
        valid, as round to nearest would then round up, and javac correctly accepts
        those values. Likewise, replacing the last digit 5 with anything to make the
        number smaller (for example, 49999), also has the correct behavior where javac
        rejects the number as too small.

        class example {
          // This number must be on one line.
          // It should be a compile-time error, because it rounds to 0
          double d =
        0.000000000000000000000000000000000000000000000000000000000000000000000000000000
        00000000000000000000000000000000000000000000000000000000000000000000000000000000
        00000000000000000000000000000000000000000000000000000000000000000000000000000000
        00000000000000000000000000000000000000000000000000000000000000000000000000000000
        00000247032822920623272088284396434110686182529901307162382212792841250337753635
        10437593264991818081799618989828234772285886546332835517796989819938739800539093
        90631503565951557022639229085839244910518443593180284993653615250031937045767824
        92193656236698636584807570015857692699037063119282795585513329278343384093519780
        15531246597263579574622766465272827220056374006485499977096599470454020828166226
        23785739345073633900796776193057750674017632467360096895134053553745851666113422
        37666786041621596804619144672918403005300575308490487653917113865916462395249126
        23653881879636239373280423891018672348497668235089863388587925628302755995657524
        45550725518931369083625477918694866799496832404970582102851318545139621383772282
        6145437693412532098591327667236328125;
        }

        The similar case of Float.MIN_VALUE / 2,
        0.000000000000000000000000000000000000000000000700649232162408535461864791644958
        065640130970938257885878534141944895541342930300743319094181060791015625f,
        correctly produces the expected compile-time error. Likewise, 4.9e-324 / 2
        produces 0, showing that the value does indeed round to zero.
        (Review ID: 113164)
        ======================================================================

        As the compiler just uses the library, this is a library bug:

        frog$ cat -n T.java
             1 class T {
             2 public static void main(String[] args) {
             3 String s =
             4 "0.000000000000000000000000000000000000000000000000000000000000000000000000000000" +
             5 "00000000000000000000000000000000000000000000000000000000000000000000000000000000" +
             6 "00000000000000000000000000000000000000000000000000000000000000000000000000000000" +
             7 "00000000000000000000000000000000000000000000000000000000000000000000000000000000" +
             8 "00000247032822920623272088284396434110686182529901307162382212792841250337753635" +
             9 "10437593264991818081799618989828234772285886546332835517796989819938739800539093" +
            10 "90631503565951557022639229085839244910518443593180284993653615250031937045767824" +
            11 "92193656236698636584807570015857692699037063119282795585513329278343384093519780" +
            12 "15531246597263579574622766465272827220056374006485499977096599470454020828166226" +
            13 "23785739345073633900796776193057750674017632467360096895134053553745851666113422" +
            14 "37666786041621596804619144672918403005300575308490487653917113865916462395249126" +
            15 "23653881879636239373280423891018672348497668235089863388587925628302755995657524" +
            16 "45550725518931369083625477918694866799496832404970582102851318545139621383772282" +
            17 "6145437693412532098591327667236328125";
            18 double d = Double.parseDouble(s);
            19 System.out.println("" + d);
            20 }
            21 }
        frog$ /usr/local/java/jdk1.4.0/solsparc/bin/javac T.java
        frog$ /usr/local/java/jdk1.4.0/solsparc/bin/java T
        4.9E-324
        frog$

        neal.gafter@Eng 2000-12-08
        ###@###.### 2004-11-11 21:41:02 GMT

          Attachments

            Issue Links

              Activity

                People

                • Assignee:
                  bpb Brian Burkhalter
                  Reporter:
                  bonealsunw Bret O'neal (Inactive)
                • Votes:
                  0 Vote for this issue
                  Watchers:
                  2 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Imported:
                    Indexed: