Boost logo

Boost :

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).


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