`BigDecimal("1.199999988079071").floatValue shouldBe 1.199999988079071f` fails
See original GitHub issueSource of the issue is using of an intermediate Double
value with subsequent rounding.
Issue Analytics
- State:
- Created a year ago
- Comments:5 (4 by maintainers)
Top Results From Across the Web
No results found
Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I’m not questioning whether this bug is worth fixing. It’s a bug, and we fix all bugs.
I’m wondering if doing
java.lang.Float.parseFloat(toString())
is an acceptable implementation. Because it does fix the issue (I tried).Why do circe and play-json use
BigDecimal
to then lose all their precision to floats, of all things? Is that the expected fast path people will use in the common case?I can’t speak for play-json, but IIRC Circe uses
BigDecimal
for its internalJson
representation to maintain precision. Of course, a user is then free todecode
that to any numerical type (which may beFloat
).