Mailing-List: contact issues-help@commons.apache.org; run by ezmlm
Precedence: bulk
Reply-To: issues@commons.apache.org
Date: Mon, 15 Sep 2014 07:57:34 +0000 (UTC)
From: "Duncan Jones (JIRA)" <jira@apache.org>
To: issues@commons.apache.org
Message-ID: <JIRA.12716767.1401186293000.33536.1410767854078@Atlassian.JIRA>
In-Reply-To: <JIRA.12716767.1401186293000@Atlassian.JIRA>
References: <JIRA.12716767.1401186293000@Atlassian.JIRA>
 <JIRA.12716767.1401186293722@arcas>
Subject: [jira] [Updated] (LANG-1018) NumberUtils.createNumber(final String
 str)  Precision will be lost
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/LANG-1018?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Duncan Jones updated LANG-1018:
-------------------------------
    Assignee: Duncan Jones

After further research (and a [Stack Overflow question on the subject|http://stackoverflow.com/q/25831817/474189]), I've concluded that making decisions based on significand length is nigh-on impossible, not least because the significand length must be calculated when in binary form (not decimal).

The correct approach depends upon what we intend to achieve with this method. The Javadocs are not specific on this topic, but I presume we want to guarantee (where possible) the following test result:

{code:java}
assertEquals(inputString, NumberUtils.createNumber(inputString).toString());
{code}

If so, a simple approach is to convert to {{float}} and test the {{toString()}} representation. If this doesn't match, use {{double}}. Finally we use {{BigDecimal}} if neither matches. Does anyone have any thoughts on that approach?

> 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
>            Assignee: Duncan Jones
>             Fix For: Patch Needed
>
>
> 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)