Boost logo

Boost :

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
floating-point type.

Or even physical measurement uncertainty, or both.

This is why BOOST_CHECK_CLOSE has a parameter for 'close enough' - and has
proved invaluable.

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

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