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: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2008-12-05 07:13:56

John Maddock skrev:
> 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.

I guess p. 34 (Intervals) provides some hints to how we write such a 
careful predicate. If I understand this correctly, then we should at 
least use bounds that are exactly representable in the type involved.

For example, to create a bound for probabilities we can use 0 (can be 
exactly represented), and then for 1 we must can the nearest number 
larger than 1 representable in the type (e.g. float).

-Thorsten