Re: [boost] [review][constrained_value] ReviewofConstrainedValueLibrary begins today

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
nothing paticularily important about this example.

> 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