Tom Verhoeff wrote:
It would be a good thing if gpc provided full support of the IEEE 754 Standard.
Unfortunatly (for numerical applications, at least), many compilers either provide no support at all, or provide only partial support. The latter is often even worse than the former.
<long IEEE advertisement snipped>
I have read some texts praising IEEE, but frankly, I am unimpressed. I find some properties of IEEE (denormals) harmfull -- if denormal support is active I really can not rely on hardware detection of overflow/underflow (I can loose acuraccy without any indication).
AFAIK up from i387 Intel FPU complies to the letter (and probably also to the spirit) of the standard -- but if one wants to use IEEE features brain damage show up quickly. Namely, instead of providing separate instructions for different modes of operation processor has mode bits (I think it is what standard encourages) and if one wants to mix modes one has to change processor status word like crazy (costly even on newest processors and really kills performnce on Pentium).
The resistor example is cute, but a number comes from calculation then really w can not assume that it will be non-negative -- if it can be zero the typically it can be of any sign. Yes, Kahan gives examples where IEEE features guarantee sign, but IMHO checking that result can not be negative is more complicated then full error analysis + adding a positive bias which compensates for error. Note also that IEEE division is significantly more expensive then non IEEE one (for non IEEE one can use few steps of Newton aproximation, but IEEE requires extra checking/correction step or slow serial algorithm).
Trying to support fully support IEEE in compiler is really damaging to performance: if x = x then writeln('Noraml number'); else writeln('IEEE creature');
can not be simplified -- and such code appears during optimization of real programs, only programmers can not understand why compiler is not making "obvious" simplifications. And there are really more examples.
Lot of folks doing number crunching say that they do not care about IEEE, but they do care about speed.
For me traditionl Pascal formulation: "real type is a finite approximation to true real numbers" (with understanding that I will get _some_ result within specified error bounds) is quite reasonable. IEEE makes floating point computation exact, but following really complicated rules. I think that trying to predict results using IEEE rules is too complicated for most folks, so they really make no use of exactness. But exactness costs a lot.
Also, Pascal standard leaves real computation as "implementation defined", so relying on IEEE is non-portable. So I would limit effort towards IEEE -- I think it is better to produce reasonable results quickly then trying to follow IEEE in all details.