You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Rob Tompkins (JIRA)" <ji...@apache.org> on 2019/04/08 18:10:00 UTC

[jira] [Commented] (LANG-1444) NumberUtils.createNumber() does not create BigDecimal for decimal fractions tending to zero

    [ https://issues.apache.org/jira/browse/LANG-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16812672#comment-16812672 ] 

Rob Tompkins commented on LANG-1444:
------------------------------------

This happens because {{Double.valueOf("1.000000000000001") = 1.000000000000001}} and {{Double.valueOf("1.0000000000000001") = 1.0}}. In the latter case because we've lost the precision, it no longer matters whether we store the number as a Double or a Float, so we use a Float because it's been truncated.

> NumberUtils.createNumber() does not create BigDecimal for decimal fractions tending to zero
> -------------------------------------------------------------------------------------------
>
>                 Key: LANG-1444
>                 URL: https://issues.apache.org/jira/browse/LANG-1444
>             Project: Commons Lang
>          Issue Type: Bug
>          Components: lang.math.*
>    Affects Versions: 3.8.1
>            Reporter: Costa Theodosiou
>            Priority: Major
>
> The following code demonstrates the issue:
> {{System.out.println(NumberUtils.createNumber("1.1").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.00001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.0000001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.000000001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.00000000001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.0000000000001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.000000000000001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.00000000000000001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.0000000000000000001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.000000000000000000001").getClass().getName());}}
> {{System.out.println(NumberUtils.createNumber("1.00000000000000000000001").getClass().getName());}}
> will print:
> {{java.lang.Float}}
> {{java.lang.Float}}
> {{java.lang.Float}}
> {{java.lang.Float}}
> {{java.lang.Double}}
> {{java.lang.Double}}
> {{java.lang.Double}}
> {{java.lang.Double}}
> {{java.lang.Float}}
> {{java.lang.Float}}
> {{java.lang.Float}}
> {{java.lang.Float}}
> It seems the problem is towards the bottom of the createNumber method that compares the float to double string representation:
> f.toString().equals(d.toString())
> For the misbehaving tests, the string "1.0".equals("1.0")



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)