JDK-4154042 : java.lang.FloatingDecimal could be eliminated
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.lang
  • Affected Version: 2.0
  • Priority: P5
  • Status: Closed
  • Resolution: Future Project
  • OS: generic
  • CPU: generic
  • Submitted: 1998-07-01
  • Updated: 2021-09-03
  • Resolved: 2010-11-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8
8Resolved
Related Reports
Relates :  
JDK-4428022 - System.out.println(0.001) outputs 0.0010
Relates :  
JDK-4511638 - Double.toString(double) sometimes produces incorrect results
Description
...  Saving a fair amount of code.  This package-private class is only
used for Float.toString() and Double.toString(), and I bet those methods
could be implemented more compactly.
Comments
CONVERTED DATA BugTraq+ Release Management Values COMMIT TO FIX: dragon
14-06-2004
EVALUATION Much of the complexity of FloatingDecimal is to deal with speed and with accuracy and correctess. I) FloatingDecimal tries to do all calculations in float/int, else in double/long, and as a last resort in FDBigInt. BigDecimal goes immediately to a Big format, using expressions such as intVal = BigInteger.valueOf(sign*mantissa); if (exponent < 0) { intVal = intVal.multiply(BigInteger.valueOf(5).pow(-exponent)); scale = -exponent; } else if (exponent > 0) { intVal = intVal.multiply(BigInteger.valueOf(2).pow(exponent)); } II) Much of the complexity of the algorithm in FloatingDecimal is the stopping test, of which BigDecimal has no notion. To understand the ramifications, start by reading http://javaweb.eng/~anandp/notes/float/ and the JLS sections referenced by it. Here's a simple program to illustrate the difficulty: import java.math.BigDecimal; class tbd { public static void main( String args[] ){ for ( int i = 0 ; i < args.length; i++ ){ String a = args[i]; float f = Float.valueOf( a ).floatValue(); BigDecimal bd = new BigDecimal( f ); System.out.println( a + ":"); System.out.println( " as float: "+f ); System.out.println( " float=>BigDecimal: "+bd ); double d = Double.valueOf( a ).doubleValue(); bd = new BigDecimal( d ); System.out.println( " as double: "+d ); System.out.println( " double=>BigDecimal: "+bd ); } } } And here's a simple example of running it: java tbd 1e37 1e-37 1e37: as float: 1.0E37 float=>BigDecimal: 9999999933815812510711506376257961984 as double: 1.0E37 double=>BigDecimal: 9999999999999999538762658202121142272 1e-37: as float: 1.0E-37 float=>BigDecimal: 0.0000000000000000000000000000000000000999999991097578965450144252348949782882164643167775990861842615891642849224041356137604452669620513916015625 as double: 1.0E-37 double=>BigDecimal: 0.0000000000000000000000000000000000001000000000000000066324273227849160063246821413449472343705781641680227552882474171018285786819118458879085409307663212530314922332763671875 As you can see, BigDecimal output conversion would have to be agumented with a fairly subtle notion of appropriate-number-of-digits, and some rounding. This would make it much more complex than at present. III) Finally, as Hideya has pointed out, Luna uses an extended verions of FloatingDecimal to do input as well as output conversion. JDK1.2 will as well. This is because this Java version is much more portable than the equivalent correct C code. (And about the same size. For comparison, compiling David Gay's dtoa.c -- the most well-known, well-respected, widely-available, portable conversion package -- for Sparc with -O gives 12560 bytes instructions + 264 bytes read-only data.) To instead use BigDecimal for floating input conversion would mean changing this member to actually do some work, rather than just counting on Double.valueOf to do the right thing: public double doubleValue(){ /* Somewhat inefficient, but guaranteed to work. */ return Double.valueOf(this.toString()).doubleValue(); } But don't let me discourage you. There are certainly savings to be had by an energetic programmer willing to understand the semantics. richard.tuck@Eng 1998-07-13 The decimal <-> binary conversion routines need to be re-examined; replacing FloatingDecimal with another class (or replacing FDint with BigInteger) should be considered. ###@###.### 2002-05-14 Decommitting from Tiger, issue should still be addressed in a future release. ###@###.### 2003-09-08
14-05-2002