Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2008-12-06 18:07:59

Robert wrote:
> The epsilon solution has already been proposed, but as I understand  
> this
> (correct me if I'm wrong) it wouldn't work either:
>
> 	> From: Zach Laine
>
> 	> Yet another use case would be "close enough is good enough".  If  
> the
> 	> bounds are within a user-defined epsilon of either boundary.
>
> 	If I understand correctly, this does not solve the problem either.  
> Let's
> assume you have two values: x and y, where x = y + eps (eps being the
> user-defined margin of error). One comparison of x and y would  
> indicate their
> equality (the difference is not greater than eps), while another one  
> might not
> if x got truncated in the meantime (and y didn't).

Thanks, I understand the problem now.

I think we are all agreed that the library is orthogonal to any  
concerns about floating point and nothing needs to be changed in the  
code.  IMO the warning should be toned down in the documentation.  I  
wish the definition that Stjepan suggests were possible, but I don't  
see how a test can be designed that only only switches from  
unsatisfied to satisfied.

Boost.Test has a good start on float predicates http://tinyurl.com/57u2sf 
  - but no inequality and they require epsilon to be passed in or  
stored.  I'll see if I can adapt them before Constrained Value is  
finalized...  might be opening a can of worms, and any advice would be  
appreciated.

> If I write everywhere that a feature implies no space cost, everyone  
> will take
> this for granted and may be surprised when it turns out that on  
> their compiler
> it is much worse than expected.

In that case, I would like it if the documentation said a feature  
"should not" take any extra space, linking to the explanation.  In  
turn, the explanation can mention the sizeof test and link to the  
results so that people can find out quickly whether their platform  
will cooperate.

I know it's a drag, but I think the features which do take extra space  
should mention that too.

Also it might be worthwhile to point out that shared runtime mutable  
constraints with no overhead per constrained object are possible,  
using static members.  (Or maybe that's too weird.)  I might implement  
epsilon this way, as my impression is that numeric_limits<>::epsilon()  
is not useful for this purpose.

Gordon