FULL PRODUCT VERSION :
Windows:
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing)
Linux:
java version "1.5.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
* Microsoft Windows XP [Version 5.1.2600]
* Linux ernie 2.4.30 #1 Wed Apr 13 14:59:04 CEST 2005 i586 unknown
EXTRA RELEVANT SYSTEM CONFIGURATION :
Seems to be CPU independent: Happens on AMD Athlon XP, AMD K6, Intel Celeron and Pentium 4.
A DESCRIPTION OF THE PROBLEM :
Description by example:
0.050000002607703200f converts to 0.05 (3D4CCCCD internal)
0.050000002607703201f converts to 0.05
0.050000002607703202f converts to 0.050000004 (3D4CCCCE internal)
0.050000002607703203f converts to 0.050000004
0.050000002607703204f converts to 0.050000004
0.050000002607703205f converts to 0.050000004
0.050000002607703206f converts to 0.05
0.050000002607703207f converts to 0.05
0.050000002607703208f converts to 0.05
0.050000002607703209f converts to 0.050000004
As this is obviously not a simple rounding issue, I think that the note on direct String-to-float conversions in the documentation of Float#valueOf(ava.lang.String) does not apply here. Even if the conversion is not guaranteed to produce correctly rounded float values, I would at least expect that the conversion of sequences of floating point literals preserves monotony.
This problem also affects the javac compiler as float literals are converted the same way.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile & run the test case.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Depending on what the note on direct String-to-float conversion in Float#valueOf(String) wants to tell me, I would expect different results.
The dream result would be:
0.05
0.050000004
But as it seems that round-to-nearest is not guaranteed to take place as expected in direct String-to-float conversion, I would also accept:
0.05
0.05
or
0.050000004
0.050000004
ACTUAL -
0.050000004
0.05
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public class FloatProblem {
public static void main( String[] args) {
float a = 0.050000002607703203f;
float b = 0.050000002607703207f;
System.out.println( a );
System.out.println( b );
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Avoiding direct String-to-float conversion by using intermediate doubles.
Compile time:
float a = (float) 0.050000002607703203;
instead of
float a=0.050000002607703203f;
Run time:
(float)Double.parseDouble( someString );
instead of
Float.parseFloat( someString );
Windows:
java version "1.5.0_05"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_05-b05)
Java HotSpot(TM) Client VM (build 1.5.0_05-b05, mixed mode, sharing)
Linux:
java version "1.5.0_03"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_03-b07)
Java HotSpot(TM) Client VM (build 1.5.0_03-b07, mixed mode)
ADDITIONAL OS VERSION INFORMATION :
* Microsoft Windows XP [Version 5.1.2600]
* Linux ernie 2.4.30 #1 Wed Apr 13 14:59:04 CEST 2005 i586 unknown
EXTRA RELEVANT SYSTEM CONFIGURATION :
Seems to be CPU independent: Happens on AMD Athlon XP, AMD K6, Intel Celeron and Pentium 4.
A DESCRIPTION OF THE PROBLEM :
Description by example:
0.050000002607703200f converts to 0.05 (3D4CCCCD internal)
0.050000002607703201f converts to 0.05
0.050000002607703202f converts to 0.050000004 (3D4CCCCE internal)
0.050000002607703203f converts to 0.050000004
0.050000002607703204f converts to 0.050000004
0.050000002607703205f converts to 0.050000004
0.050000002607703206f converts to 0.05
0.050000002607703207f converts to 0.05
0.050000002607703208f converts to 0.05
0.050000002607703209f converts to 0.050000004
As this is obviously not a simple rounding issue, I think that the note on direct String-to-float conversions in the documentation of Float#valueOf(ava.lang.String) does not apply here. Even if the conversion is not guaranteed to produce correctly rounded float values, I would at least expect that the conversion of sequences of floating point literals preserves monotony.
This problem also affects the javac compiler as float literals are converted the same way.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
Compile & run the test case.
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Depending on what the note on direct String-to-float conversion in Float#valueOf(String) wants to tell me, I would expect different results.
The dream result would be:
0.05
0.050000004
But as it seems that round-to-nearest is not guaranteed to take place as expected in direct String-to-float conversion, I would also accept:
0.05
0.05
or
0.050000004
0.050000004
ACTUAL -
0.050000004
0.05
REPRODUCIBILITY :
This bug can be reproduced always.
---------- BEGIN SOURCE ----------
public class FloatProblem {
public static void main( String[] args) {
float a = 0.050000002607703203f;
float b = 0.050000002607703207f;
System.out.println( a );
System.out.println( b );
}
}
---------- END SOURCE ----------
CUSTOMER SUBMITTED WORKAROUND :
Avoiding direct String-to-float conversion by using intermediate doubles.
Compile time:
float a = (float) 0.050000002607703203;
instead of
float a=0.050000002607703203f;
Run time:
(float)Double.parseDouble( someString );
instead of
Float.parseFloat( someString );
- duplicates
-
JDK-7093777 Float.parseFloat does not round correctly
- Closed
-
JDK-7192954 Fix Float.parseFloat to round correctly and preserve monotonicity.
- Closed
- relates to
-
JDK-4191279 Float.toString() produces incorrect results
- Closed
-
JDK-7192954 Fix Float.parseFloat to round correctly and preserve monotonicity.
- Closed