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

Martin Buchholz martinrb at google.com
Thu Jun 20 23:24:10 UTC 2013

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/viewbug.do?bugid=7039391 - Use Math.ulp in FloatingDecimal. The updated patch is at http://cr.openjdk.java.net/~bpb/719295443962727039391/ 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/viewbug.do?bugid=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/2*ULP, and the candidate value <= 2*Double.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