From: Stjepan Rajko
Are we still talking about the case when test ==> invariant? I'm confused -- if we allow for a value (x) being a "delta" bigger than the upper bound (y), then why the invariant should be "x < y" rather than "x - delta < y"?
OK, if you make your test be "x < y" then you can guarantee "x - delta < y". But the user doesn't want to deal with the deltas - that is the whole issue here. So, you make your test "x + epsilon < y" and you can guarantee "x < y".
OK, got it.
So far you've shown one application that is dealing with the FP issue using epsilon, but we don't know yet if this approach is leading to (best or any) solution of the problem.Are there any other use cases that I should consider?
Hmm.. I think I mentioned more examples than just the FP case (e.g, monitored values with no invariant
Sorry, I must have had a temporary amnesia. ;-)
This violates the rules of strict weak ordering, which guarantee that we can perform tests for bounds inclusion without surprises. For example, when x == NaN, the following "obvious" statement may be false:
(l < x && x < u) ==> (l < u)
Why would I care that l < u? If I'm using a bounded type with lower bound l and upper bound u, presumably I just care that (l < x && x < u).
I just wanted to show that NaN comparison produces surprising results, there's nothing paticularily important about this example.
If you want boundaries excluded, use < for compare. If you want them included, use <=. If the type doesn't offer <=, use "<(a, b) || ==(a, b)".
The problem is that we want to compare the values using the supplied comparison predicate, which represents the "<" relation. This is a simple and generic approach used, for examle, in STL. However, comparison with NaN doesn't quite fit in this model.
And you don't have to worry about NaNs. Unless I'm missing something.
But if I find a way to make the test behave consistently in the presence of NaNs (e.g., always indicating that NaN doesn't belong to a range), then why not. ;-) Best regards, Robert