Adriaan van Os wrote:

Frank Heckenbach wrote:

...

ISO Pascal wants an error (though, in principle, I think we could use NaN and document the error as "not detected" -- we might do this sometime, perhaps optionally). For now, I'm making it runtime errors. (emil27*.pas)

Special cases for the pow function in IEEE 754 (see e.g. Apple Numerics Manual, second edition, page 64, or the PowerPC Numerics manual available from <http://developer.apple.com/documentation/mac/PPCNumerics/PPCNumerics- 2.html>).

Operation Result Exceptions raised

[ List suppressed ] 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. (Apple has indeed been a loyal supporter of the standard from the very beginning.) The need for some features in the IEEE 754 standard is less obvious to the uninitiated. Good articles in this respect are Kahan, W. Lecture Notes on the Status of IEEE Standard 754 for Binary Floating-Point Arithmetic. May 1996. <http://www.cs.berkeley.edu/~wkahan/ieee754status/IEEE754.PDF> and Kahan, W. Why do we need a floating-point arithmetic standard? Unpublished note, February 1981. <http://www.cs.berkeley.edu/~dbindel/class/cs279/why-ieee.pdf> William Kahan is the intellectual father of the standard. Another important references is (the title says it all): Goldberg, D. ``What every computer scientist should know about floating-point arithmetic'', Appendix~D in Numerical Computation Guide. Sun Microsystems, Revision A, May 2000; originally published in ACM Computing Surveys (March 1991). <http://docs.sun.com/source/806-3568/ncg_goldberg.html> The following (short) book is a good introduction to the use of IEEE 754: Overton, M. L. Numerical Computing with IEEE Floating Point Arithmetic. SIAM, 2001. For those with less time, I recommend an article I recently wrote: Gyula Horvath, Tom Verhoeff. ``Numerical Difficulties in Pre-University Informatics Education and Competitions'', Informatics in Education, Vol. 2, Number 1, pp.21-38. <http://www.win.tue.nl/~wstomv/publications/INFE012.pdf> Here is one simple example contained in that article, to explain the need for avoiding unnecessary exception raising. Suppose you want to write a piece of program to calculate the effective resistance of two (and later more than two) parallel resistors, R_1 and R_2, both non-negative real numbers (Ohms). The basic formula is 1 R_Eff = --------- (i.e. the "harmonic" mean of R_1 and R_2) 1 1 --- + --- R_1 R_2 Of course, it fails (under normal math rules), when R_1 or R_2 (or both) are zero. However, when either (or both) are zero, the effective resistance is well-defined, viz. zero. A slightly better formula may seem to be R_1 * R_2 R_Eff = --------- R_1 + R_2 because it also "works" when either of R_1 and R_2 are zero. However, there are two problems with that formula: (1) when both are zero, it gives 0/0, and (2) it does not generalize easily to more than two resistors. Now, under the IEEE 754 Standard, the first formula works perfectly well. Why? Because the standard includes signed infinities and NaN (not-a-number) that are well-behaved: 1 / +0 = +inf (zero is also signed!) a + inf = inf 1 / +inf = +0 0 / 0 = NaN 0 * +inf = NaN NaN <any-operator> a = NaN With these rules, the first formula works correctly under all circumstances, without requiring any case analysis in the program. However, if division by zero would raise an exception, then you need to catch it in the program, and you get a clumsy program. The second formula fails under these rules for R_1 = R_2 = 0, because it involves 0 / 0. In (numerical) practice, there are even "worse" examples (such as rational function with multiple "false" poles; see Kahan's articles), where a case analysis would be horrible compared to the straightforward approach via IEEE 754. All in all, the committee that developed the IEEE 754 Standard thought hard about the features, and they came up with a carefully balanced set. Partial implementation is not recommended, because it destroys some important properties. Tom