-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Gordon Woodhull Sent: 06 December 2008 23:51 To: boost@lists.boost.org 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 +44 1539 561830, mobile +44 7714330204 pbristow@hetp.u-net.com