Editing Floating-point arithmetic (section)

==Dealing with exceptional cases {{anchor|Floating point exception|Exception handling}}== <!-- linked from a couple of places within the article -->
{{further|IEEE 754#Exception handling}}

Floating-point computation in a computer can run into three kinds of problems:
* An operation can be mathematically undefined, such as ∞/∞, or [[division by zero]].
* An operation can be legal in principle, but not supported by the specific format, for example, calculating the [[square root]] of −1 or the inverse sine of 2 (both of which result in [[complex number]]s).
* An operation can be legal in principle, but the result can be impossible to represent in the specified format, because the exponent is too large or too small to encode in the exponent field. Such an event is called an overflow (exponent too large), [[arithmetic underflow|underflow]] (exponent too small) or [[Subnormal number|denormalization]] (precision loss).

Prior to the IEEE standard, such conditions usually caused the program to terminate, or triggered some kind of [[trap (computing)|trap]] that the programmer might be able to catch. How this worked was system-dependent, meaning that floating-point programs were not [[porting|portable]]. (The term "exception" as used in IEEE 754 is a general term meaning an exceptional condition, which is not necessarily an error, and is a different usage to that typically defined in programming languages such as a C++ or Java, in which an "[[Exception handling|exception]]" is an alternative flow of control, closer to what is termed a "trap" in IEEE 754 terminology.)

Here, the required default method of handling exceptions according to IEEE 754 is discussed (the IEEE 754 optional trapping and other "alternate exception handling" modes are not discussed). Arithmetic exceptions are (by default) required to be recorded in "sticky" status flag bits. That they are "sticky" means that they are not reset by the next (arithmetic) operation, but stay set until explicitly reset. The use of "sticky" flags thus allows for testing of exceptional conditions to be delayed until after a full floating-point expression or subroutine: without them exceptional conditions that could not be otherwise ignored would require explicit testing immediately after every floating-point operation. By default, an operation always returns a result according to specification without interrupting computation. For instance, 1/0 returns +∞, while also setting the divide-by-zero flag bit (this default of ∞ is designed to often return a finite result when used in subsequent operations and so be safely ignored).

The original IEEE 754 standard, however, failed to recommend operations to handle such sets of arithmetic exception flag bits. So while these were implemented in hardware, initially programming language implementations typically did not provide a means to access them (apart from assembler). Over time some programming language standards (e.g., [[C99]]/C11 and Fortran) have been updated to specify methods to access and change status flag bits. The 2008 version of the IEEE 754 standard now specifies a few operations for accessing and handling the arithmetic flag bits. The programming model is based on a single thread of execution and use of them by multiple threads has to be handled by a [[Concurrency (computer science)|means]] outside of the standard (e.g. [[C11 (C standard revision)|C11]] specifies that the flags have [[thread-local storage]]).

IEEE 754 specifies five arithmetic exceptions that are to be recorded in the status flags ("sticky bits"):
* '''inexact''', set if the rounded (and returned) value is different from the mathematically exact result of the operation.
* '''underflow''', set if the rounded value is tiny (as specified in IEEE 754) ''and'' inexact (or maybe limited to if it has denormalization loss, as per the 1985 version of IEEE 754), returning a subnormal value including the zeros.
* '''overflow''', set if the absolute value of the rounded value is too large to be represented. An infinity or maximal finite value is returned, depending on which rounding is used.
* '''divide-by-zero''', set if the result is infinite given finite operands, returning an infinity, either +∞ or −∞.
* '''invalid''', set if a finite or infinite result cannot be returned e.g. sqrt(−1) or 0/0, returning a quiet NaN.
[[File:Resistors in Parallel.svg|thumb|left|200px|Fig. 1: resistances in parallel, with total resistance <math>R_{tot}</math>]]The default return value for each of the exceptions is designed to give the correct result in the majority of cases such that the exceptions can be ignored in the majority of codes. ''inexact'' returns a correctly rounded result, and ''underflow'' returns a value less than or equal to the smallest positive normal number in magnitude and can almost always be ignored.<ref name="Kahan_1997_Status"/> ''divide-by-zero'' returns infinity exactly, which will typically then divide a finite number and so give zero, or else will give an ''invalid'' exception subsequently if not, and so can also typically be ignored. For example, the effective resistance of n resistors in parallel (see fig. 1) is given by <math>R_\text{tot}=1/(1/R_1+1/R_2+\cdots+1/R_n)</math>. If a short-circuit develops with <math>R_1</math> set to 0, <math>1/R_1</math> will return +infinity which will give a final <math>R_{tot}</math> of 0, as expected<ref name="Intel"/> (see the continued fraction example of [[Floating point#IEEE 754: floating point in modern computers|IEEE 754 design rationale]] for another example).
''Overflow'' and ''invalid'' exceptions can typically not be ignored, but do not necessarily represent errors: for example, a [[Zero of a function|root-finding]] routine, as part of its normal operation, may evaluate a passed-in function at values outside of its domain, returning NaN and an ''invalid'' exception flag to be ignored until finding a useful start point.<ref name="Kahan_1997_Status"/>