------------------------------ From: James Demmel Date: Fri, 8 Oct 93 17:49:27 -0700 Subject: Comments on IEEE Arithmetic Comments on IEEE Arithmetic Jim Demmel Computer Science Division and Math Dept. University of California Berkeley, CA 94720 demmel@cs.berkeley.edu This is in response to the various comments on IEEE arithmetic in the last few NA-Digests. Many user complaints are a result of the IEEE floating point standards 754 and 854 specifying how systems "should appear" to the user, without specifying any specific language bindings. These binding were not part of the standard, because the committee members felt that writing a standard demanding simultaneous changes in hardware, languages, compilers, and perhaps operating systems (for exception handling) was unlikely to to be accepted, or if accepted, implemented correctly. This "act of cowardice" (in the words of W. Kahan) has unfortunately made it impossible to write portable software which uses features of IEEE like exception handling. This confusion, which is still much better than the pre-IEEE situation of different roundings, etc., has motivated some people to try to standardize language bindings in a proposed Language Independent Arithmetic (LIA) ISO standard. Unfortunately, I believe the LIA still does not give adequate access to IEEE features, and indeed it was recently voted down for this reason by the US/ISO committee. It is currently being redrafted, and may still be accepted, but this is another story. W. Kahan has designed his own set of language bindings for exception handling, which is easier to do than a full set of environmental enquiries. He is interested in exploring implementations with interested parties. The IEEE standard specifically requires that the default behavior of a system should NOT be to trap on exceptions, but to compute and/or propagate infinities and NANs. One reason for this decision was to force manufacturers to implement NAN and infinity arithmetic with reasonable efficiency, since otherwise they would be tempted to take the easy way out (implementation via traps to software) and so make infinities and NANs so slow that they would be impossible to use effectively. Some manufacturers have still chosen to use software traps, and others have not. For a recent paper on how to use infinities and NANs to speed up numeric codes, and the price one pays for implementing them too slowly, see the reference by Demmel and Li below [1]. All IEEE machines permit trapping on exceptions, and it should be a prominently documented feature as to how to do this for any particular system, either via a system subroutine call or compile line option. It is unfortunate that compiler and system library writers do not document this more clearly. [1] Demmel, J. and Li, X., "Faster Numerical Algorithms via Exception Handling", Proceedings of the 11th Symposium on Computer Arithmetic, IEEE Computer Society Press, E. Swartzlander, M. J. Irwin and G. Jullien, eds., June 29 -- July 2, Windsor Canada, 1993. Available as all.ps.Z via anonymous ftp from toe.cs.berkeley.edu, in directory pub/tech-reports/cs/csd-93-728; software is csd-93-728.shar.Z. An extended version is to be submitted to IEEE Trans. Computers. [2] Demmel, J., Underflow and the Reliability of Numerical Software, SIAM J. Sci. Stat. Comput., 1984, v. 5, n. 4, pp 887-919, December ------------------------------ From: Dean Schulze Date: Sat, 09 Oct 1993 14:24:24 -0700 (MST) Subject: Division by Zero is OK in Many Cases Mike Peterson writes (Na Digest Volume 93, Issue 37): >Why anyone would want a default behaviour to allow a program to >continue executing after dividing by 0 (either integer or floating >point), or creating a NaN by whatever means (e.g. fp overflow), is >beyond me. In my many years of programming, I can't think of one >case where I would want this to happen. Performing such operations >is a clear indication of a program(mer) error, You've got to be kidding! Your programming experience through those many years must have been restricted to a very limited class of problems. One common example of when you would want to continue execution after dividing by zero is when computing trigonometric functions. Here is one example where IEEE arithmetic is a godsend: exp(exp(-1.0/cos(chi))) This is not a contrived example. It is used when computing Chapman functions which are used in the theory of planetary atmospheres. The ability of IEEE arithmetic to correctly compute trigonometric functions when the argument is a multiple of pi/2.0 is what made a fan of IEEE arithmetic. Dean Schulze ------------------------------