Subject: Re: [boost] [review][constrained_value] Review of Constrained Value Library begins today
From: Gordon Woodhull (gordon_at_[hidden])
Date: 2008-12-10 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