# Boost :

Subject: Re: [boost] [review][constrained_value] ReviewofConstrainedValueLibrary begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-09 18:42:35

> 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

> 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