= 27d567bc2d48d9f40e9ccc20ea370b15)
Vladimir_M comments on Specification failure - Less Wrong Discussion
You are viewing a comment permalink. View the original post to see all comments and the full post content.
= 783df68a0f980790206b9ea87794c5b6)
Loading…= b715d02e85f7b3b4ae65ca3d3e450868)
Subscribe to RSS Feed
Powered by Reddit
= f037147d6e6c911a85753b9abdedda8d)
You are viewing a comment permalink. View the original post to see all comments and the full post content.
Comments (18)
Haha, it really is more tricky than it sounds. I succeeded (it passed a bunch of tests including various corner cases on first compilation), but I'm not sure if it would be correct if I hadn't been more cautious than usual.
I'm not surprised, though. The human capacity for formal logical inference is extremely unreliable and short-sighted, even for very intelligent people.
Did you consider that comparing floating point numbers with '==' doesn't make much sense? (I assume it implements exact value comparison in this language you used, like in C.)
Yeah, I did the same thing with tests. Wrote about ten of them and rigged the suite to scream "YOU FAIL" at me without even printing the line number. Couldn't believe it when they all passed on the first try :-)
No. What do you propose? Use some sort of "comparison tolerance"?
In this context, I think the answer is don't write it for floats!
cousin_it:
That depends on the concrete numerical application. Typically you'd define some threshold for the difference, and use "abs(x-y)<threshold" instead of "x==y", or some variation on that theme. But exact bit-by-bit equality comparisons of floats practically never make sense, since even very simple arithmetic will likely produce rounding errors, so seeing '==' between floats almost always means that something nonsensical is going on. (See e.g. here for some elaboration.)
These issues with limited floating point precision make numerical programming extremely tricky. You have a whole alternative set of rules for arithmetic, very different from those you normally follow on paper.
I think I'd have a different implementation for floats that would return the nearest two it's between, and punt the tolerance decision up a level to the calling code.