Re: Floating point trouble with x86's extended precision

[Jim Wilson <wilson at tuliptree dot org>]

I don't do FP for a living, and I don't want to spend hours composing
every response to this thread, so it is hard for me to be precise.  I
think it will also be hard for me to explain to you why there are
problems with the x86.  It isn't clear to me that you have a good enough
understanding of the issues involving numerical analysis on computers.

You seem to think that extra precision is always good.  It isn't. 
Numerical algorithms are designed assuming certain properties of
computer arithmetic.  If they are evaluated using a different kind of
computer arithmetic, for instance with extra precision, some of them
will fail and give incorrect results.  Possibly even widely incorrect
results.

If you really want extra precision, then you need to use different
algorithms that take the extra precision into account.

However, there is still the problem that you have to know when you have
extra precision and when you don't.  If you can never be sure what
precision you have, then you can't design an algorithm that is
guaranteed to work.  And that is the problem with the current state, we
can never guarantee any particular precision, and hence we can't
guarantee correct results.  This is a serious problem.  The random
rounding that occurs with extra precision introduces unavoidable errors,
and prevents you from getting correct results.  This is a very serious
problem, and is probably unfixable.

Double rounding is a basic concept of computer arithmetic.  It gives
errors that are larger than 0.5ulp.  They are only slightly larger than
0.5ulp, but the difference is significant, and it is enough to cause a
numerical algorithm to fail and produce incorrect results.

Here is a bad analogy for why extra precision is bad.  Suppose I write a
program using 8-bit chars, and the compiler decides to use 16-bit short
instead of 8-bit char because extra precision is good.  Does the program
still work?  No, it is trivial to write programs that fail if "char" is
replaced with "short".  Now, if you know that the compiler will always
use 16-bits for a char, then you can write a program that will work,
because this is easy to compensate for.  But suppose the compiler
randomly chooses to use 8-bits or 16-bits for each char variable.  Can
you still write a program that works?  Maybe you can, maybe you can't. 
The same is true for floating point.  The situation is rather different,
and a lot more complicated to prove, but if the compiler randomly
replaces double with long double, you get different results, which will
sometimes be incorrect results, and there may be no way to rewrite the
code to guarantee that you always get correct results.

That is the current situation with x86 FP code.  The "randomness"
introduced by register allocation prevents one from getting correct
results.  Even if you get rid of the "randomness", you still have the
problem that you need different algorithms for x86 because of the
different computer arithmetic properties.  That is assuming that we can
get rid of the randomness, I am not convinced that we can.  This is such
a big mess that it is best avoided.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com