RFR 7192954+4396272: Fix Float.parseFloat to round correctly and preserve monotonicity

[Brian Burkhalter]

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

* sun/misc/FloatingDecimal
* java/lang/Double
* java/lang/Float
* java/math

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/view_bug.do?bug_id=7192954 - Fix Float.parseFloat to round correctly and preserve monotonicity
> 
> 2) http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=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/2*ULP, and the candidate value <= 2*Double.MIN_NORMAL, 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