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
> The epsilon solution has already been proposed, but as I understand
> (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
> > bounds are within a user-defined epsilon of either boundary.
> If I understand correctly, this does not solve the problem either.
> 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
> 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
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk