RFR 7192954+4396272: Fix Float.parseFloat to round correctly and preserve monotonicity (original) (raw)

Brian Burkhalter brian.burkhalter at oracle.com
Wed Jun 12 19:56:53 UTC 2013

The original patch has been updated such that it also fixes

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7039391 - Use Math.ulp in FloatingDecimal.

The updated patch is at

http://cr.openjdk.java.net/~bpb/7192954_4396272_7039391/

For purposes of comparison, the original patch is left online at the location indicated below.

The specific changes in the update are

  1. Use IEEE-754 primitive long instead of primitive double for the candidate double, thereby removing FloatingDecimal.ulp() without using any Math.* methods.

  2. Remove strictfp from declarations of doubleValue() and floatValue().

  3. In floatValue(), find approximation directly instead of invoking doubleValue().

I have code-reviewed the update and ensured that it passes the JTREG tests in

If there are other pertinent validations which should be performed please point them out.

Once this patch has been officially reviewed I will post the webrev for http://bugs.sun.com/view_bug.do?bug_id=7131192 - BigInteger.doubleValue() is "depressingly" slow.

Thanks,

Brian

On Jun 11, 2013, at 3:47 PM, Brian Burkhalter wrote:

This contributed patch

http://cr.openjdk.java.net/~bpb/4396272%2b7192954/ fixes these two issues: 1) http://bugs.sun.com/bugdatabase/viewbug.do?bugid=7192954 - Fix Float.parseFloat to round correctly and preserve monotonicity 2) http://bugs.sun.com/bugdatabase/viewbug.do?bugid=4396272 - Parsing double fails to follow IEEE for largest decimal the should yield 0 For 7192954, "stickyRound()" is replaced by actual code development containing a correction loop in floatValue() analogous to that in doubleValue(). For 4396272, when the difference between the scaled big-int versions of the exact value and the candidate double value is exactly 1/2ULP, and the candidate value <= 2Double.MINNORMAL, then form the correction statement in a way that avoids rounding the intermediate result to zero thereby preventing correction. For reference see also this thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-February/014788.html Thanks, Brian

More information about the core-libs-dev mailing list