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-07 16:25:59

On Dec 6, 2008, at 7:17 PM, Stjepan Rajko wrote:
> Another way of describing this would be to say that the library should
> not necessarily require that the condition test passes if and only if
> the invariant is satisfied - it should only require that the test
> fails if the invariant is not satisfied (but if the invariant is
> satisfied, the test is allowed to fail).

That makes sense to me.  I don't know if this is a strict weak  
ordering as the documentation now requires, but I think it will work  
for 99.99999999999999% of cases. ;)

My intention (when I find some time after the end of the semester) is  
to use the Boost.Test predicates to define less_eps, greater_eps, etc.

I will change the epsilon input into a policy with a reasonable  
default, although the documentation claims that the appropriate  
epsilon is always application-dependent.  I suppose there should also  
be runtime changeable versions.

IIUC then all the inequality predicates are just combinations of  
regular < and > with the closeness/equality check, where the latter  
trumps the former.  Intuitively (the way I think ;) this means that if  
it's too close it "should be considered equal" not just because of  
float rounding but because there is always error.

I also want to find out if there is a way to reliably truncate values  
on purpose before any comparison - would that not produce consistent  
results?  I don't think I am willing to maintain assembly code for a  
lot of platforms however.

I am no float expert but I always need this.  Would appreciate any  
help, especially poking holes in the design.

Robert, it sounds like you're willing to explain the problem better in  
the documentation and hopefully we'll have some solutions for people  
too.

Gordon