4 ms·

> You also shouldn't treat exact floating point values as if they are approximate—floating point is not approximate, some floating point operations are (conditi

> You also shouldn't treat exact floating point values as if they are approximate—floating point is not approximate, some floating point operations are (conditionally) approximate. Depending on your domain, they usually are. Perhaps your floating point number represents a reading from a sensor which has much less precision than your floating point type. It would be more correct to model all of your approximate variables with error bars (and perhaps even error distributions) but in practice, treating the closest floating point number as a point estimate and doing all your comparisons to within some reasonable tolerance may be an acceptable approach.

sacrosancty 5y ago
But why would you need to compare such measurements for equality with an arbitrary tolerance? If your algorithm is doing something like producing a yes/no answer from some measured data then it should be obvious what tolerance to use according to the domain. I would code that explicitly using inequalities instead of depending on some mystery default epsilon.
- sfvisser 5y ago
  You’re right here I think, but it is a hard problem in practice I noticed. Hard in the engineering sense, because you’re sometimes writing generic library-level code that needs a domain specific notion of error bars and tolerances. So you need to parametrize everything, sometimes for multiple dimensions. Becomes messy quickly. I must admit putting a mystery epsilon in my code here and there for that reason. Admittedly the wrong thing to do.
Veedrac 5y ago
This is a completely legitimate concern but it isn't about floating point. You could be getting integer readings from your sensor and you would have exactly the same concern. In such cases you need to provide tolerances in your code that correspond to the tolerances of your measurement. You might need to implement hysteresis, you might need to take multiple samples and track moving averages, you might need to take empirical measurements of the variance you expect and suppress readings below a threshold. It is very rare however for the solution to just be to say two values compare equal if they are within a billionth part from the other.

sacrosancty 5y ago

But why would you need to compare such measurements for equality with an arbitrary tolerance? If your algorithm is doing something like producing a yes/no answer from some measured data then it should be obvious what tolerance to use according to the domain. I would code that explicitly using inequalities instead of depending on some mystery default epsilon.

sfvisser 5y ago
You’re right here I think, but it is a hard problem in practice I noticed. Hard in the engineering sense, because you’re sometimes writing generic library-level code that needs a domain specific notion of error bars and tolerances. So you need to parametrize everything, sometimes for multiple dimensions. Becomes messy quickly. I must admit putting a mystery epsilon in my code here and there for that reason. Admittedly the wrong thing to do.

Veedrac 5y ago

This is a completely legitimate concern but it isn't about floating point. You could be getting integer readings from your sensor and you would have exactly the same concern. In such cases you need to provide tolerances in your code that correspond to the tolerances of your measurement. You might need to implement hysteresis, you might need to take multiple samples and track moving averages, you might need to take empirical measurements of the variance you expect and suppress readings below a threshold. It is very rare however for the solution to just be to say two values compare equal if they are within a billionth part from the other.