Hi Louis, I looked at your fix of sunbug=6358355 "Fix Float.parseFloat to round correctly and preserve monotonicity". https://bugs.openjdk.java.net/show_bug.cgi?id=100208 I like how you separate String->double and String->float conversions. They both become more clear. However I found two issues.
1) The line in floatValue() method fValue = (float) doubleValue(); fValue can become Float.POSITIVE_INFINITY. It causes incorrect result on input like this String s = "340282356779733661637539395458142568447"; // 2^128 - 2^103 - 1 floatValue() returns Float.POSITIVE_INFINITY, the correct result is Float.MAX_VALUE . fValue can also become 0. It causes assertion error on input like this String s = "7.00649232162408535461864791644958065640130970938257885878534141944895541342930300743319094181060791015625E-46"; // 2^(-150) It can be fixed in such a way fValue = Math.max(Float.MIN_VALUE, Math.min(Float.MAX_VALUE, (float) doubleValue())); 2) The line in floatValue() method. // difference is exactly half an ULP // round to some other value maybe, then finish fValue += 0.5f*ulp( fValue, overvalue ); When fValue is subnormal, the right-hand sign evaluates to 0, fValue remains unchanged. This is similar to the bug 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0. The result of String s = "7.00649232162408535461864791644958065640130970938257885878534141944895541342930300743319094181060791015625E-46"; // 2^(-150) is Float.MIN_VALUE, the correct result is 0. It can be fixed in such a way fValue = (float) (fValue + 0.5*ulp(fValue, overvalue)); Constant 0.5 instead of 0.5f causes double evaluation of right-hand side, so it doesn'nt underflow. Best Regards, -Dima
