On Fri, Dec 5, 2008 at 8:07 AM, Robert Kawulak <robert.kawulak@gmail.com> wrote:
Hi,
2008/12/5 Neal Becker <ndbecker2@gmail.com>:
How about, floating point is allowed, but the results may sometimes be surprising?
If the surprise consists of breaking the invariant, I'm not convinced...
Your currently require that the condition should not "spontaneously" change. If you also allow conditions that can spontaneously change from unsatisfied to satisfied (but not the other way around), your guarantee/invariant is no weaker, but you allow the possibility of triggering the error policy in cases where the condition is initially unsatisfied but would eventually spontaneously change to satisfied. You then provide a continuum of behavior. On one extreme, a condition that never spontaneously changes will trigger the policy exactly when the condition is broken. This is the behavior that your library provides right now. In the middle, a condition that can spontaneously change from unsatisfied to satisfied can trigger in "gray zone" conditions determined by the specifics of the condition. On the other end, a condition always initially reports that it is not satisfied even though it will always eventually spontaneously become satisfied (e.g., the condition that x>0 seconds has elapsed on a timer that starts timing on construction). A solution for the floating point problem can then be provided (as I think has been suggested earlier in this thread, using a platform-specific delta value to adjust the comparisons, where delta is greater than the amount by which a floating point value can spontaneously change). This would fit into the library as a "grey zone" constraint, where the magnitude of the grey zone is determined by the delta, and usefulness by how accurate delta is. Stjepan