My point is about comparing accelerated code behavior to the standard java Double.

your point is still invalid because it's pointless to attempt what you're suggesting. and that's not how unit tests work.

unit testing doesn't mean that all possible values have to be tested. usually it's about code paths, i.e. standard, error and edge cases.

The successes of fuzzing projects like oss-fuzz have demonstrated significant shortcomings to hand-curating test cases in the manner you describe. Testing every 64bit float value is unrealistic, but testing a huge number of randomly selected values by cross-comparison with other libraries is a very good idea for code like this.

https://github.com/google/oss-fuzz

My point is based on experience. Yes, it's probably too much to ask to test all 2^64 cases, but I've been dealing with code in production that was failing precisely because some values lead to code paths that gave incorrect results.

In this particular case, I would have tested 2^N where N>32 random, unique values, at a minimum.

Of course, it depends on who the customer is. Some customers can tolerate a few bugs here and there; and some would incur million dollar losses.