gwyn@brl-smoke.ARPA (Doug Gwyn ) (04/09/87)
Jim Valerio nicely summed up the intent of the IEEE extended f.p. values. My disagreement with this approach is both practical and philosophical. Generally, in the vast majority of floating-point code that I have seen, overflow (to take one example) indicates that the programmer did not take all possible situations into account when designing the algorithm or writing the code. Although it is true that SOME calculations will produce the correct answer if computation proceeds using extended values such as infinity, far more often meaningless or even harmful results will be produced. Without knowing the specific application, one cannot say whether generation of an arithmetic exception, abnormal termination, extended value substitution, or some other approach would be the best way to deal with the situation. I very much fear that the "typical" programmer will simply use the extended values by default and be blissfully UNAWARE that the code is producing garbage. Since real-world operations depend on such code, there is great potential for serious injury. (The person who jokingly mentioned starting World War III was not as far off the mark as one might think.) I would MUCH rather that programmers learn about possible pitfalls and how to avoid and/or deal with them. The "extended value" approach appears to me to encourage them to ignore the issues instead of facing up to them. By the way, does anyone need some examples of the computational problems associated with floating-point arithmetic, or has it been clear what we've been talking about?