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

Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: John Maddock (john_at_[hidden])
Date: 2008-12-05 04:21:41

Thorsten Ottosen wrote:
>> 6. My main use case would be to use constrained floating point
>> values,
>> but the docs state:
>>
>> "Why C++'s floating point types shouldn't be used with bounded
>> objects? [...] there exist a number of myths of what IEEE-compliance
>> really
>> entails from the point of view of program semantics. We shall discuss
>> the following myths, among others: [...] "If x < 1 tests true at one
>> point, then x < 1 stays true later if I never modify x."
>>
>> I don't fully understand this...AFAIK, this is not allowed for an
>> IEEE complient implementation. How could we ever implement
>> *anything* with
>> respect to floats then?

With difficulty :-(

Here's the thought experiment I came up with to verify that this is a real 
issue:

* Imagine that the constraint is that the value is > 1, and that we're 
working with double's.
* Imagine that the value being assigned is the result of some complex 
computation, and that the assignment function is inlined.
* The compiler may now take the value being assigned as it exists in a 
register (from the computation), and perform a the check on that.
* If the register containing the result is wider than a double (say Intels 
80-bit long double), and the result is very slightly > 1, then the 
comparison will succeed.
* The value is now stored in the object - and rounded down to double 
precision in the process.
* The value may have been rounded down to exactly 1, and the constrait is 
now broken!

Obviously if the constraint had been >= 1 then we'd be OK in this case (but 
then values very slightly < 1 may get rounded up, so we could eroniously 
reject a value).

I think of any worse situations than these at present - which doesn't mean 
they don't exist - so whether or not you consider this an issue may depend 
on the use case.

Presumably, a carefully written predicate that forces any rounding to occur 
prior to constraint checking would fix the issue, and I 100% agree that use 
with floating-point types is a very important use case.

John.