Withdraw: Review: 4396272 - Parsing doubles fails to follow IEEE for largest decimal that should yield 0 (original) (raw)

Dmitry Nadezhin dmitry.nadezhin at gmail.com
Fri Feb 22 17:41:08 UTC 2013

Brian,

Class FloatingDecimal contains both conversion from String to float/double and conversion from float/double to String. My change is in conversion from String to float/double. The methods if FloatingDecimal that implement this conversion are: static FloatingDecimal readJavaFormatString( String in ); double doubleValue(); float floatValue(); My change is in method doubleValue().

Class FormattedFloatingDecimal was forked from FloatingDecimal some time ago. This class is used only for conversion from String to float/double. The unused method readJavaFormatString( String in) was deleted from FormattedFloatingDecimal. Methods doubleValue() and floatValued() were not deleted, but they are never used in JDK code.

So I think that the required change in FormattedFloatingDecimal is to delete methods doubleValue(), floatValue() and other unused methods and fields. Am I right ?

-Dima

On Fri, Feb 22, 2013 at 8:46 PM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote:

Hello Dima,

Yes that would be helpful and appreciated. There is another patch to the same files that I will be looking into, but the changes are disjoint so there should not be a significant merge issue. Thanks, Brian On Feb 21, 2013, at 7:27 PM, Dmitry Nadezhin wrote:

Do you want that I prepare this FloatingDecimal/FormattedFloatingDecimal patch ?

-Dima On Fri, Feb 22, 2013 at 2:32 AM, Brian Burkhalter <brian.burkhalter at oracle.com> wrote: I am withdrawing this patch for the time being as properly the changes should also go into the fork sun.misc.FormattedFloatingDecimal. I'll post an updated patch once it is available.

Thanks, Brian On Feb 14, 2013, at 5:23 PM, Brian Burkhalter wrote:

The patch below is as submitted to OpenJDK bugzilla but with enhanced comments. It pertains to the correction loop in the doubleValue() method of FloatingDecimal. The situation appears to arise when the candidate value is less than 2Double.MINNORMAL as for such values the ULP is less than 2Double.MINVALUE so that the intermediate result 0.5*ULP is less than Double.MINVALUE which rounds to zero per FP-strict and the correction is therefore zero. Thus the candidate value is unchanged. The fix is to add the ULP to twice the candidate value, obtain the intermediate result, and then halve it to obtain the adjusted candidate.

I am relatively new to IEEE-754 and this area of the code so any comments would be appreciated. Thanks, Brian diff -r 1405ad6afb1e -r 36482ed9bb7e src/share/classes/sun/misc/FloatingDecimal.java --- a/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 11:09:07 2013 -0800 +++ b/src/share/classes/sun/misc/FloatingDecimal.java Thu Feb 14 16:47:53 2013 -0800

More information about the core-libs-dev mailing list