Fork me on GitHub

you could say it’s “Simple” 😏


Might just be enough ;)


something weird i encountered


on my laptop (java 8):
(Math/pow 9 17)
=> 1.667718169966657E16

on a friend laptop (java 11):
(Math/pow 9 17)

Lennart Buit20:12:52

Their reading is more correct to the actual 16677181699666569

Lennart Buit21:12:35

this is a nice can of worms you found btw

Lennart Buit21:12:40

Heres a class that (for a performance tradeoff) makes stronger guarantees about rounding:

Lennart Buit21:12:30

I do wonder, is there an optimisation difference between 8/11 that - within the rules of floating point - produces a slightly different result


In practice, also first creating a BigInteger and then using .pow of that class also produces correct results (in this particular case). Here it was very suprising that number of digits differ between two different java versions. I am wondering how many "wrong" pieces of code will stop to work


Wrong because, at least in the case that i was looking at, having the java8 precision resulted in two errors which cancelled each other :man-facepalming: and of course that wasn't happening with java11. If you switch to exact math it's correct


FYI it was the checking whether 21897142587612075 is a Narcissistic number:

Lennart Buit07:12:23

floating point is not meant to be exact, it is meant to give a pretty good estimate on a wide range of numbers 😛

Lennart Buit07:12:41

(I was fairly close to trying to dump generated machine code on Java 8/11, but decided that it was 11 o’clock and that was not beneficial to this working day)


Of course floating point should not be used for anything that precise.. but I have seen things... floats used to store MONEY...


Anyway, the surprise in my case was mostly that i wasn't aware of a change like that between 8 and 11. 😄

Lennart Buit20:12:10

not running a Pentium 1 is (s)he 😉