Hi Dima, On Feb 25, 2013, at 1:14 AM, Dmitry Nadezhin wrote:
> I looked at your fix of sunbug=6358355 "Fix Float.parseFloat to round > correctly and preserve monotonicity". > […] > 1) The line in floatValue() method > fValue = (float) doubleValue(); > > fValue can become Float.POSITIVE_INFINITY. > It causes incorrect result on input like this > […] > It can be fixed in such a way > fValue = Math.max(Float.MIN_VALUE, Math.min(Float.MAX_VALUE, (float) > doubleValue())); Thanks for the catch! > 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. > […] > > 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. I was intending to comment on this as well. Once approved, I was thinking that the patch for 7192954 "Fix Float.parseFloat to round correctly and preserve monotonicity" should be applied first followed by patches for 4396272 "Parsing doubles fails to follow IEEE for largest decimal that should yield 0" and "BigInteger.doubleValue() is depressingly slow." I initiated some of these reviews out of this sequence as I had not become aware of all the linkages. I am actually also wondering whether the patch for 7032154 "Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal," which I just learned of today, should perhaps be dealt with prior to any of the above? Thanks, Brian
