commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rob Tompkins (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (LANG-1444) NumberUtils.createNumber() does not create BigDecimal for decimal fractions tending to zero
Date Mon, 08 Apr 2019 18:10:00 GMT

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

Mime
View raw message