Re: GUB and mpfr/mpc

[David Kastrup]

Masamichi HOSODA <address@hidden> writes:

>>>> Also, the mention of optimization reminds me of one of the horrors
>>> of floating point types: a value in a register can quietly be
>>> changed when it is written to memory.  Take a look at some of the
>>> “myths” in section 1 of
>>> https://hal.archives-ouvertes.fr/hal-00128124/en/ .
>> […]
>>> I think that floating point can be used as long as it's used correct.
>>> 
>>> operator== shouldn't be used for comparison of floating point values.
>>> operator!= shouldn't be used too.
>>> operator< and operator> may be used.
>> 
>> The issue is more complex than that.  Sit down and try this:
> [...]
>> Add looping and you’ve got fatal issues.  (And if you’re like me,
>> steam will erupt from your ears any second now...)
>
> You're right of course.
> A floating point operation has a margin of error always.
> When the optimization is different, the margin of error may be also different,
> because the bit width of floating point value is different
> in a register and a memory.
>
> Therefore, robust treating for margin of error is necessary.

That does not help all that much: it just shifts the problem somewhere
else.  It will tend to fix known test cases and create a new set of
previously working failures.

Instead the algorithms have to be rewritten in a manner where their
termination does not depend on the reproducibility of floating point
operations.  There have been a few attempts of rewriting skyline code
that have fixed/created some problems without any real insights into
what caused the fix and what caused the new problems.

-- 
David Kastrup