3 ms·
sampled from reality i guess I was implying. Whatever model you have that generated 14.7 depends on measurements from reality with a bit of error bars. I admi
by lanstin 3y ago
sampled from reality i guess I was implying. Whatever model you have that generated 14.7 depends on measurements from reality with a bit of error bars.
I admit removing language support for == of floats is a bit of a wild idea, but it is conceptually sound, if not practical. I'd support keeping it in a test/debug package.
Tho if you are looking at bitwise patterns, then I find memcmp or its equivalents to be needed, to handle Nan != NaN.
- sfpotter 3y agoNaN != NaN is very useful when debugging numerical software. NaN is a great placeholder value for things which don't have a clear default value to which they can be initialized. To your point, there are plenty of situations where a floating point number will be initialized to a magic constant (0, 1, infinity, so many others...). Beyond initialization, there are also loads of functions which frequently yield floating point constants which can reliably be tested for equality, like max(0, x). There are no error bars here. Exact floating point equality can usefully tell us things like "has this number changed", or more generally "has this special case occurred"/"have we reached a particular state". Removing floating point == isn't conceptually sound, and it isn't practical.
- lanstin 3y agoI hope you aren’t testing for equality with pi or e or rho or square root of two. One and zero and -zero might be special cases. If you are testing max(0, pi) also you will be sad sometimes. Especially tho if you are doing computation and then testing for equality you will mostly be wrong. What are the cases you are mentioning? Surely something more complex than a float for a loop variable? When the error is less than a threshold, when the sign changes, when the number of objects 8n a partition is one, I can’t think of a calculated float that would be a test for something with equality.