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

["Hetul Bhatt (Jira)" <ji...@apache.org>]

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

Hetul Bhatt commented on LANG-1444:
-----------------------------------

[~chtompki], it appears that the later 4 cases encountered a scenario where the decimal representation in the input string exceeded the range of both Float and Double data types. As a result, both Float and Double values produced the same result, leading to the method returning a float.

However, this approach introduces a precision loss for the number itself. To address this issue, I propose converting the number to a BigDecimal instead and returning it. By using BigDecimal, we can preserve the precision of the number, even when the decimal representation goes beyond the limits of Float and Double.

This adjustment ensures that the returned value accurately represents the original input string, avoiding any precision loss that would occur with a float return type.

> 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
>          Time Spent: 1h 50m
>  Remaining Estimate: 0h
>
> 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
(v8.20.10#820010)