DecimalFormat regression bug in Java 8?

[Olivier Lagneau]

Hello Lennart,

Sorry for the little belated reply.

The behaviour you see is due to a fix for JDK-7131459 and is the 
expected one.

While working on the DecimalFormat optimization which you noticed in the 
code, we discovered a long-standing bug in the DigitList.java class
(see bug 7131459 <http://bugs.sun.com/view_bug.do?bug_id=7131459>).
We have fixed this bug and the fix is now part of the JDK8 builds 
(starting in b82 IIRC). so b108 and b111 are fixed.

The fact is that most decimal values cannot be represented exactly in a 
binary representation.
For example the closest binary representation to -0.15 is 
-0.1499999999999999944488848768742172978818416595458984375 .

As you can see the absolute value of this representation is "below" the 
tie value "0.15".
So the closest binary representation of -0.15 that can be recorded in a 
computer  is a bit greater than the "tie" value provided in the program 
text ("-0.15"),  and for this reason, as stated by the HALF-EVEN 
rounding rules, we should not round the result, in order to provide an exact
and fair HALF-EVEN rounding of *what is recorded* in the computer.

Thus the correct result to return here is -0.1 because 
maximumFractionDigits is set to 1, and correct rounding leaves the '1' 
digit in 1st
fractional position unchanged.

Approximated closest binary representation is the case of all values you 
provided in your example, except for 0.25 which can be represented 
*exactly*. So there is no change in the output only for that value when 
comparing older and recent builds.

The correct formatting is the one provided by recent JDK8 builds like 
b108 and b111.

To help understanding, I have changed a bit your example to show what is 
the approximated binary representation that is recorded
in the computer memory by using the call "new BigDecimal(d).toString()" 
which provides the exact decimal representation of what is
recorded in the computer :

you will find below the changed code and the corresponding results for 
JDK8 builds that include (or don't include) the fix for
JDK-7131459

Hope that helps.

Best Regards,
Olivier.

changed code :
--------------------------------------
import java.text.DecimalFormat;
import java.math.BigDecimal;

public class Jdk8Formatting {

     public static void main(String[] args) {

         double dd[] = {-0.15, -0.05, 0.05, 0.15, 0.25, 0.35, 0.45, 
0.55, 0.65};
         DecimalFormat fmt = new DecimalFormat("0.#");

         for (double d : dd) {
             // Prints-out first the "approximated" double 
floating-point value
             System.out.println("FloatingDecimal output : " + d);

             // Then the exact binary representation using as much 
memory as needed
             System.out.println("BigDecimal      output : " + new 
BigDecimal(d).toString());

             // And finally the string returned by DecimalFormat.format()
             System.out.println(d + " " + fmt.format(d));
         }
     }
}
--------------------------------------

Output of the above program for JDK8 builds that include the fix:
FloatingDecimal output : -0.15
BigDecimal      output : 
-0.1499999999999999944488848768742172978818416595458984375
-0.15 -0.1
FloatingDecimal output : -0.05
BigDecimal      output : 
-0.05000000000000000277555756156289135105907917022705078125
-0.05 -0.1
FloatingDecimal output : 0.05
BigDecimal      output : 
0.05000000000000000277555756156289135105907917022705078125
0.05 0.1
FloatingDecimal output : 0.15
BigDecimal      output : 
0.1499999999999999944488848768742172978818416595458984375
0.15 0.1
FloatingDecimal output : 0.25
BigDecimal      output : 0.25
0.25 0.2
FloatingDecimal output : 0.35
BigDecimal      output : 
0.34999999999999997779553950749686919152736663818359375
0.35 0.3
FloatingDecimal output : 0.45
BigDecimal      output : 
0.450000000000000011102230246251565404236316680908203125
0.45 0.5
FloatingDecimal output : 0.55
BigDecimal      output : 
0.5500000000000000444089209850062616169452667236328125
0.55 0.6
FloatingDecimal output : 0.65
BigDecimal      output : 
0.65000000000000002220446049250313080847263336181640625
0.65 0.7

---------------------------------------------------------------------------------

Output of the above program for JDK8 builds that *do not* include the fix:
FloatingDecimal output : -0.15
BigDecimal      output : 
-0.1499999999999999944488848768742172978818416595458984375
-0.15 -0.2
FloatingDecimal output : -0.05
BigDecimal      output : 
-0.05000000000000000277555756156289135105907917022705078125
-0.05 -0
FloatingDecimal output : 0.05
BigDecimal      output : 
0.05000000000000000277555756156289135105907917022705078125
0.05 0
FloatingDecimal output : 0.15
BigDecimal      output : 
0.1499999999999999944488848768742172978818416595458984375
0.15 0.2
FloatingDecimal output : 0.25
BigDecimal      output : 0.25
0.25 0.2
FloatingDecimal output : 0.35
BigDecimal      output : 
0.34999999999999997779553950749686919152736663818359375
0.35 0.4
FloatingDecimal output : 0.45
BigDecimal      output : 
0.450000000000000011102230246251565404236316680908203125
0.45 0.4
FloatingDecimal output : 0.55
BigDecimal      output : 
0.5500000000000000444089209850062616169452667236328125
0.55 0.6
FloatingDecimal output : 0.65
BigDecimal      output : 
0.65000000000000002220446049250313080847263336181640625
0.65 0.6
---------------------------------------------------------------------------



Lennart Börjeson said  on date 10/21/2013 11:26 AM:
> I've found what I believe is a DecimalFormat regression bug in Java 8, i.e. Java 8 seems to format some numbers differently than previous releases do.
>
> I've tried submitting a proper bug report using the form at bugreport.sun.com, but it just throws back a "submission error" at me, so I resort to mailing you.
>
> Just try the code below.
> --------------
> import java.text.DecimalFormat;
> public class Jdk8FormattingBug {
>
>     public static void main(String[] args) {
>         double dd[] = {-0.15, -0.05, 0.05, 0.15, 0.25, 0.35, 0.45, 0.55, 0.65};
>      DecimalFormat fmt = new DecimalFormat("0.#");
>
>      for (double d : dd) {
>      System.out.println(d+" "+fmt.format(d));
>      }
>      }
> }
> ----------------
>
> I've tested JDK 1.8 b108 and b111, on Linux and on Mac, and they all print:
>
> -0.15 –0.1
> -0.05 –0.1
> 0.05 0.1
> 0.15 0.1
> 0.25 0.2
> 0.35 0.3
> 0.45 0.5
> 0.55 0.6
> 0.65 0.7
>
>
> Yet the printout using all other Java versions I've tried is:
>
> -0.15 –0.2
> -0.05 -0
> 0.05 0
> 0.15 0.2
> 0.25 0.2
> 0.35 0.4
> 0.45 0.4
> 0.55 0.6
> 0.65 0.6
>
> which is the documented behaviour, respecting RoundingMode.HALF_EVEN.
>
> I'd expect formatting to behave the same in Java 8, or have I missed some change here? I've noticed there has been some optimisation work done on DecimalFormat, but shouldn't the output stay the same?
>
> Best regards,
>
> Lennart Börjeson