Subject: Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2008-12-08 15:14:47
> -----Original Message-----
> From: boost-bounces_at_[hidden] [mailto:boost-bounces_at_[hidden]]
> Behalf Of Gordon Woodhull
> Sent: 06 December 2008 23:51
> To: boost_at_[hidden]
> Subject: Re: [boost] [review][constrained_value] Review of Constrained
> begins today
> I wrote:
> > 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.
> Of course I won't use this technique but something more like what's
> described in "Compile-time fixed bounds" - don't know what I was
> thinking. Runtime modification of epsilon is just silly.
I'd just like to point out that there are more than the 'near-epilson
computational noise' reasons, discussed so far, why it is useful to be able
to make 'fuzzier' floating-point comparisons.
There are many computations that involve iteration - but for speed only to a
user-chosen precision - which may be *much* more than epsilon for the
Or even physical measurement uncertainty, or both.
This is why BOOST_CHECK_CLOSE has a parameter for 'close enough' - and has
There are times when fixing this both at compile time or at run-time might
be most useful.
--- Paul A. Bristow Prizet Farmhouse Kendal, UK LA8 8AB +44 1539 561830, mobile +44 7714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk