Hi Paul, On Thu, Nov 25, 2021 at 3:24 AM Paul Wise <[email protected]> wrote: > Giulio Paci wrote: > > > 3) what is the most appropriate solution. > > As I understand it, floating point values should not be compared > without some kind of accuracy/precision factor. Zero idea about the > best reference for how to do it correctly, but here is a random one: > > https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
Thanks for this link. It is a very great resource and summarizes very well what I already know about double/float and much more. Since the test case is dealing with timings, I think the most related article is [1]. However even after reading that article it seems to me that in this case it should be reasonable to expect stable behavior of those operators. I have uploaded simplified code that showcase the issue and some of the instabilities [2]. The code seems to behave as if the last value is different from the other 3, supposed equal values. I am not even sure what I am seeing in the debugger, since most of the values are optimized out (and I am not so skilled with debuggers). [1] https://randomascii.wordpress.com/2012/02/13/dont-store-that-in-a-float/ [2] https://pastebin.com/embed_js/T3g560UV Bests, Giulio
