Boost logo

Boost :

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


Boost list run by bdawes at, gregod at, cpdaniel at, john at