Their reading is more correct to the actual 16677181699666569

this is a nice can of worms you found btw

Heres a class that (for a performance tradeoff) makes stronger guarantees about rounding: https://docs.oracle.com/javase/7/docs/api/java/lang/StrictMath.html

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: http://mathworld.wolfram.com/NarcissisticNumber.html

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

(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. 😄