Boost logo

Boost :

Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Stjepan Rajko (stjepan.rajko_at_[hidden])
Date: 2008-12-05 10:40:01


On Fri, Dec 5, 2008 at 8:07 AM, Robert Kawulak <robert.kawulak_at_[hidden]> wrote:
> Hi,
>
> 2008/12/5 Neal Becker <ndbecker2_at_[hidden]>:
>> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk