Boost logo

Boost :

From: Fernando Cacciola (fernando_cacciola_at_[hidden])
Date: 2003-07-07 10:31:44


IMHO, the problem with test_fp_comparisons is that it is
fundamentally flawed.
As Guillaume said, ULPs just don't add.
The approach of trying to bound the relaive error based
on the number of roundings, which is what is intended,
just doesn't work, and it won't work no matter how
you try the adjust the 'number of errors' factor.

I tried to explain this before but didn't had the
time to go with a throughout explanation.
But I'll give it another shot:

ULPs are _relative_ quantities, so you cannot just
add them as such becasue normally each ulp is relative to
a different number.
Altough for a _single_ operation the relative error
is bounded by 1/2ulp, the idea that for an expression
with N binary operands, the relative error is bounded
by N * 1/2ulp is simply wrong.
And the whole test is designed with this wrong idea.

I've told this to Gennadiy back then, but he needed to
understand why and I didn't have the time to explain
it so the flaw just slipped through
(so in a way this problem is my fault).

The test library tries to mimic a static error analyzer.
But this is way too complex and way off the test library
scope.

I still think that the test library should not offer a built-in
FP comparison check.
The argument in favor of it was that with an external user
supplied test, we loose the possibility of outputing the
offending operands.
But I argued that fixing an fp comparison scheme
right into the test library might lead to false expectations
about how the test works.
The poblems we are having now shows precisely the sort
of misconceptions I was referring to, so I suggest again
to uncouple the fp comparisons from the test library.

Fernando Cacciola


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk