Re: [boost] [review][constrained_value] Review of ConstrainedValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] Review of ConstrainedValueLibrary begins today
From: Stjepan Rajko (stjepan.rajko_at_[hidden])
Date: 2008-12-08 12:35:17

On Mon, Dec 8, 2008 at 9:12 AM, Robert Kawulak <robert.kawulak_at_[hidden]> wrote:
>
> So what's the conclusion in the context of separation of invariant and the test?
> That we may end up having bounded float with value a bit greater than the upper
> bound, but that's fine, because the difference will never exceed some
> user-defined epsilon? Is the epsilon constant? The "delta" (difference between
> extended and truncated value) may have a very big value for big numbers and very
> small for small ones, so epsilon should rather be scaled according to the
> magnitude of compared numbers.

I know little about floats and what the values of the deltas are and
how they depend on the value of the float, but:

The invariant is still: x < y
The exact outcome depends on the policy. If the policy forces
truncation and retests, there is no epsilon in the outcome either (it
only exists in the test).

>
> Did I get things right so far?
>

I think so.

> Then why complicate things with epsilon at all? If we allow for values outside
> of the bounds but only a "delta" away, we may simply stay with the "<"
> comparison. Even better, I would love to see a solution to force truncation of a
> value, so the comparisons are always performed on truncated values and we may
> stay with the "test == invariant" approach.
>

If you are sticking with test == invariant just for the sake of test
== invariant (rather than a lack of time to investigate and document
the other case), I think you are settling to sell your library for way
shorter than you can.  And like I've pointed out before, there is no
reason why you shouldn't make this a focus of the library and treat it
specially (the test==invariant case provides some really nice
benefits, like you can test for the invariant exactly and assert after
the policy check).  You can reserve the word "constraint" for when
constraint=test=invariant.  You can even do this:

constrained_value<T, constraint, policy> expands to
what_is_now_constrained_value_minus_the_assert<T, constraint,
always_assert_after<policy> >

> And another issue is NaN -- it breaks the strict weak ordering, so it may or may
> not be allowed as a valid value depening on the direction of comparison ("<" or
> ">"). I guess NaN should not be an allowed value in any case, but I have no idea
> yet how to enforce this without float-specific implementation of within_bounds.
>

I haven't taken a close look at bounded values, I'm just thinking of
them as a specific case of constrained values.  What is your invariant
here?  That ((min <= value) && (value <= max)) or that !((value < min)
|| (max < value))?  Why do you need a strict weak ordering for either
one?  I believe NaN will fail the first test but pass the second one -
if that is true, why is NaN a problem if you use the first test?
(sorry if I'm missing something, like I said I'm not well versed in
the details of floats)

Best,

Stjepan