commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Duncan Jones (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (LANG-1018) NumberUtils.createNumber(final String str) Precision will be lost
Date Mon, 15 Sep 2014 07:57:34 GMT

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

Mime
View raw message