On Dec 6, 2008, at 7:17 PM, Stjepan Rajko wrote:
Another way of describing this would be to say that the library should not necessarily require that the condition test passes if and only if the invariant is satisfied - it should only require that the test fails if the invariant is not satisfied (but if the invariant is satisfied, the test is allowed to fail).
That makes sense to me. I don't know if this is a strict weak ordering as the documentation now requires, but I think it will work for 99.99999999999999% of cases. ;) My intention (when I find some time after the end of the semester) is to use the Boost.Test predicates to define less_eps, greater_eps, etc. I will change the epsilon input into a policy with a reasonable default, although the documentation claims that the appropriate epsilon is always application-dependent. I suppose there should also be runtime changeable versions. IIUC then all the inequality predicates are just combinations of regular < and > with the closeness/equality check, where the latter trumps the former. Intuitively (the way I think ;) this means that if it's too close it "should be considered equal" not just because of float rounding but because there is always error. I also want to find out if there is a way to reliably truncate values on purpose before any comparison - would that not produce consistent results? I don't think I am willing to maintain assembly code for a lot of platforms however. I am no float expert but I always need this. Would appreciate any help, especially poking holes in the design. Robert, it sounds like you're willing to explain the problem better in the documentation and hopefully we'll have some solutions for people too. Gordon