Re: [boost] [review][constrained_value] Review of Constrained ValueLibrary begins today

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]]
On
> Behalf Of Gordon Woodhull
> Sent: 06 December 2008 23:51
> To: boost_at_[hidden]
> Subject: Re: [boost] [review][constrained_value] Review of Constrained
ValueLibrary
> 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

---
Paul A. Bristow
Prizet Farmhouse
Kendal, UK   LA8 8AB
[phone], mobile [phone]
pbristow_at_[hidden]