You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Duncan Jones (JIRA)" <ji...@apache.org> on 2014/09/12 13:54:34 UTC
[jira] [Comment Edited] (LANG-1018) NumberUtils.createNumber(final
String str) Precision will be lost
[ https://issues.apache.org/jira/browse/LANG-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14131439#comment-14131439 ]
Duncan Jones edited comment on LANG-1018 at 9/12/14 11:53 AM:
--------------------------------------------------------------
This issue is caused by the inherent inaccuracies in {{float}} representation. Consider that the following test fails, then you'll see why your patch hasn't solved the problem:
{code:java}
final String example = "-160952.54";
assertEquals(example, Float.valueOf(example).toString());
// org.junit.ComparisonFailure: expected:<-160952.5[4]> but was:<-160952.5[5]>
{code}
If you can find a case where your patch definitely improves the situation, please add a comment. Otherwise, I'm inclined not to apply this.
was (Author: dmjones500):
This issue is caused by the inherent inaccuracies in {{float}} representation. Consider that the following test fails, then you'll see why your patch hasn't solved the problem:
{code:java}
final String example = "-160952.54";
assertEquals(example, Float.valueOf(example));
// java.lang.AssertionError: expected:<-160952.54> but was:<-160952.55>
{code}
If you can find a case where your patch definitely improves the situation, please add a comment. Otherwise, I'm inclined not to apply this.
> NumberUtils.createNumber(final String str) Precision will be lost
> ------------------------------------------------------------------
>
> Key: LANG-1018
> URL: https://issues.apache.org/jira/browse/LANG-1018
> Project: Commons Lang
> Issue Type: Bug
> Components: lang.math.*
> Affects Versions: 3.3.2
> Environment: windows 7
> Reporter: sydng
> Fix For: Review Patch
>
>
> With commons-lang 3.2.2:
> NumberUtils.createNumber("-160952.54");
> The result is "-160952.55".
> Should not be based on the length of the decimal point number to judge whether the floating point number.
> Using the method (createFloat(str)) of dealing with the valid number greater than seven Numbers will cause accuracy loss.
> The source code is as follows:
> {code:java}
> try {
> if(numDecimals <= 7){// If number has 7 or fewer digits past the decimal point then make it a float
> final Float f = createFloat(str);
> if (!(f.isInfinite() || (f.floatValue() == 0.0F && !allZeros))) {
> return f;
> }
> }
> } catch (final NumberFormatException nfe) { // NOPMD
> // ignore the bad number
> }
> try {
> if(numDecimals <= 16){// If number has between 8 and 16 digits past the decimal point then make it a double
> final Double d = createDouble(str);
> if (!(d.isInfinite() || (d.doubleValue() == 0.0D && !allZeros))) {
> return d;
> }
> }
> } catch (final NumberFormatException nfe) { // NOPMD
> // ignore the bad number
> }
> return createBigDecimal(str);
> }
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)