
Boost : 
Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Gordon Woodhull (gordon_at_[hidden])
Date: 20081210 14:29:35
On Dec 10, 2008, at 7:24 AM, Johan Råde wrote:
> Thorsten Ottosen wrote:
>> John Maddock gave two examples: one where we accapted wrong values
>> and one where we rejected correct values. I found the latter
>> somewhat better (because the invariant of bounded_float would be
>> preserved), and if we are able to get that behavior consistently, I
>> would be quite happy.
>> So maybe most of our problems will be fixed by using >= and <=
>> instead of < and >?
>> Thorsten
> Is the following true: if x and y satisfy x <= y (or x >= y)
> then they will still do so after any truncation from 80 to 64 bits?
Nope, as John pointed out later in his message, if the test is x<=y
and x is just slightly greater than y, then x can flip either way.
Epsilon doesn't help here; it just moves the problem around. Now x<=y
is going to have the same problem with x very close to y+eps. The
only nicer thing about it is that if you are testing *inequality* x<y
then you can be sure that it will only accept x<y if x really is less
than y and will remain so after rounding (even though the predicate
may later fail). This is the distinction Stjepan was making between
the invariant and the test.
> Then, as Thorsten suggests, <= and >= will never erroneously accept
> any value.
Rejecting correct values is indeed better than accepting incorrect
values. It seems that you will have to be careful which predicate you
choose when dealing with floats.
> We could then maybe implement < and > using <=, >= and the
> std::nextafter function,
> and achieve the same guarantee there.
That's interesting.
I'm really glad to see the discussion of the problems with floating
point, and I'll make a stab at a few predicates implementing epsilon
and forced truncation in a couple of weeks when school is out  or if
anyone else wants to start this, please do.
I believe that this group of people has the ability to get this
problem right.
Gordon
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk