[
https://issues.apache.org/jira/browse/LANG-1444?focusedWorklogId=555419&page=com.atlassian.jira.plugin.system.issuetabpanels:worklog-tabpanel#worklog-555419
]
ASF GitHub Bot logged work on LANG-1444:
----------------------------------------
Author: ASF GitHub Bot
Created on: 21/Feb/21 15:12
Start Date: 21/Feb/21 15:12
Worklog Time Spent: 10m
Work Description: garydgregory commented on pull request #675:
URL: https://github.com/apache/commons-lang/pull/675#issuecomment-782873331
Hi @bndhanush
Thank you for your PR.
In the new test, I do not think it is enough to check that an instance of
right class is created, you want to check that the right _value_ is created to
make sure we do not have the opposite issue: loosing precision.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
[email protected]
Issue Time Tracking
-------------------
Worklog Id: (was: 555419)
Time Spent: 1.5h (was: 1h 20m)
> 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: 1.5h
> 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.3.4#803005)
