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

[Martin Buchholz]

This change Looks Good To Me.

It would be good in future to cc the contributors.

Just to show that I'm paying attention, add an extra asterisk below
to make this a proper javadoc comment (not that it matters much).

1048         /*
1049          * Takes a FloatingDecimal, which we presumably just scanned
in,
1050          * and finds out what its value is, as a double.
1051          *
1052          * AS A SIDE EFFECT, SET roundDir TO INDICATE PREFERRED
1053          * ROUNDING DIRECTION in case the result is really destined
1054          * for a single-precision float.
1055          */
1056         @Override
1057         public double doubleValue() {



On Wed, Jun 12, 2013 at 12:56 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> 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
>
>