On Jan 3, 2014, at 11:54 , Asiga Nael <email@hidden> wrote:
The point is that a fp comparison for equality isn't safe unless both operands aren't the result of fp math.
The trouble with this statement (and the floating point “morality” driving it) is that it goes way too far. And, the issue of comparisons actually has nothing *inherently* to do with the issue of representation.
Assume for a moment that there’s a magical floating point representation that can hold *any* real number exactly. (That’s an infinite number of values, which is why it’d be magical.) In that case, you certainly wouldn’t have a problem with 1.0/3.0*3.0 == 3.0, but you still *would* have the problem that exact comparisons may be too pedantic. If a simulated car has a speed of 0.1e-10000000, does the simulation *really* want to call that moving, or should it treat the speed as zero? 0.1e-10? 0.1e-3? It’s an app design issue.
Conversely, imagine a situation where an object has a CGFloat property, and you want to skip re-saving the object at document-save time, if the object hasn’t changed since the last save, including this property’s value. In this case, an exact comparison seems perfectly reasonable. The larger question of whether the value has changed *meaningfully* just isn’t relevant here.
In the first scenario, comparison can be “unsafe” (in your terminology) even with an exact representation. In the second, comparison can be “safe” even with an inexact representation.
|