Decimal Arithmetic Specification, version 1.70 Copyright (c) IBM Corporation, 2009. All rights reserved. ©	7 Apr 2009
[previous \| contents \| next]

Exceptional conditions

This section lists, in the abstract, the exceptional conditions that may arise during the operations defined in this specification.

For each condition, the corresponding signal in the context is given, along with the defined result. The value of the trap-enabler for each signal in the context determines whether an operation is completed after the condition is detected or whether the condition is trapped and hence not necessarily completed (see IEEE 754 §7 and §8).

This specification does not define the manner in which exceptions are reported or handled. For example, in a object-oriented language, an Arithmetic Exception object might be signalled or thrown, whereas in a calculator application an error message or other indication might be displayed.

The following exceptional conditions can occur:

Clamped

This occurs and signals clamped if the exponent of a result has been altered in order to fit the constraints of a specific concrete representation. This may occur when the exponent of a zero result would be outside the bounds of a representation, or (in the IEEE 754 interchange formats) when a large normal number would have an encoded exponent that cannot be represented. In this latter case, the exponent is reduced to fit and the corresponding number of zero digits are appended to the coefficient (‘fold-down’). The condition always occurs when a subnormal value rounds to zero.

Conversion syntax

This occurs and signals invalid-operation if a string is being converted to a number and it does not conform to the numeric string syntax. The result is [0,qNaN].

Division by zero

This occurs and signals division-by-zero if division of a finite number by zero was attempted (during a divide-integer or divide operation, or a power operation with negative right-hand operand), and the dividend was not zero.

The result of the operation is [sign,inf], where sign is the exclusive or of the signs of the operands for divide, or is 1 for an odd power of –0, for power.

Division impossible

This occurs and signals invalid-operation if the integer result of a divide-integer or remainder operation had too many digits (would be longer than precision). The result is [0,qNaN].

Division undefined

This occurs and signals invalid-operation if division by zero was attempted (during a divide-integer, divide, or remainder operation), and the dividend is also zero. The result is [0,qNaN].

Inexact

This occurs and signals inexact whenever the result of an operation is not exact (that is, it needed to be rounded and any discarded digits were non-zero), or if an overflow or underflow condition occurs. The result in all cases is unchanged.

The inexact signal may be tested (or trapped) to determine if a given operation (or sequence of operations) was inexact.^[1]

Insufficient storage

For many implementations, storage is needed for calculations and intermediate results, and on occasion an arithmetic operation may fail due to lack of storage. This is considered an operating environment error, which can be either be handled as appropriate for the environment, or treated as an Invalid operation condition. The result is [0,qNaN].

Invalid context

This occurs and signals invalid-operation if an invalid context was detected during an operation. This can occur if contexts are not checked on creation and either the precision exceeds the capability of the underlying concrete representation or an unknown or unsupported rounding was specified. These aspects of the context need only be checked when the values are required to be used. The result is [0,qNaN].

Invalid operation

This occurs and signals invalid-operation if:

an operand to an operation is [s,sNaN] or [s,sNaN,d] (any signaling NaN)
an attempt is made to add [0,inf] to [1,inf] during an addition or subtraction operation
an attempt is made to multiply 0 by [0,inf] or [1,inf]
an attempt is made to divide either [0,inf] or [1,inf] by either [0,inf] or [1,inf]
the divisor for a remainder operation is zero
the dividend for a remainder operation is either [0,inf] or [1,inf]
either operand of the quantize operation is infinite, or the result of a quantize operation would require greater precision than is available
the operand of the ln or the log10 operation is less than zero
the operand of the square-root operation has a sign of 1 and a non-zero coefficient
both operands of the power operation are zero, or if the left-hand operand is less than zero and the right-hand operand does not have an integral value or is infinite
an operand is invalid; for example, certain values of concrete representations may not correspond to numbers – an implementation is permitted (but is not required) to detect these invalid values and raise this condition.

The result of the operation after any of these invalid operations is [0,qNaN] except when the cause is a signaling NaN, in which case the result is [s,qNaN] or [s,qNaN,d] where the sign and diagnostic are copied from the signaling NaN.

Overflow

This occurs and signals overflow if the adjusted exponent of a result (from a conversion or from an operation that is not an attempt to divide by zero), after rounding, would be greater than the largest value that can be handled by the implementation (the value E_max).

The result depends on the rounding mode:

For round-half-up and round-half-even (and for round-half-down and round-up, if implemented), the result of the operation is [sign,inf], where sign is the sign of the intermediate result.
For round-down, (and round-05up, if implemented), the result is the largest finite number that can be represented in the current precision, with the sign of the intermediate result.
For round-ceiling, the result is the same as for round-down if the sign of the intermediate result is 1, or is [0,inf] otherwise.
For round-floor, the result is the same as for round-down if the sign of the intermediate result is 0, or is [1,inf] otherwise.

In all cases, Inexact and Rounded will also be raised.

Note: IEEE 854 §7.3 requires that the result delivered to a trap handler be different, depending on whether the overflow was the result of a conversion or of an arithmetic operation. This specification deviates from IEEE 854 in this respect; however, an implementation could comply with IEEE 854 by providing a separate mechanism for the special result to a trap handler. IEEE 754 has no such requirement.

Rounded

This occurs and signals rounded whenever the result of an operation is rounded (that is, some zero or non-zero digits were discarded from the coefficient), or if an overflow or underflow condition occurs. The result in all cases is unchanged.

The rounded signal may be tested (or trapped) to determine if a given operation (or sequence of operations) caused a loss of precision.

Subnormal

This occurs and signals subnormal whenever the result of a conversion or operation is subnormal (that is, its adjusted exponent is less than E_min, before any rounding). The result in all cases is unchanged.

The subnormal signal may be tested (or trapped) to determine if a given or operation (or sequence of operations) yielded a subnormal result.

Underflow

This occurs and signals underflow if a result is inexact and the adjusted exponent of the result would be smaller (more negative) than the smallest value that can be handled by the implementation (the value E_min). That is, the result is both inexact and subnormal.^[2]

The result after an underflow will be a subnormal number rounded, if necessary, so that its exponent is not less than E_tiny. This may result in 0 with the sign of the intermediate result and an exponent of E_tiny.

In all cases, Inexact, Rounded, and Subnormal will also be raised.

Note: IEEE 854 §7.4 requires that the result delivered to a trap handler be different, depending on whether the underflow was the result of a conversion or of an arithmetic operation. This specification deviates from IEEE 854 in this respect; however, an implementation could comply with IEEE 854 by providing a separate mechanism for the result to a trap handler. IEEE 754 has no such requirement.

It is recommended that implementations distinguish the different conditions listed above, and also provide additional information about exceptional conditions where possible (for example, the operation being attempted and the values of the operand or operands involved – see also IEEE 754 §8).

Precedence of exceptions

The Clamped, Inexact, Rounded, and Subnormal conditions can coincide with each other or with other conditions. In these cases then any trap enabled for another condition takes precedence over (is handled before) all of these, any Subnormal trap takes precedence over Inexact, any Inexact trap takes precedence over Rounded, and any Rounded trap takes precedence over Clamped.

Footnotes:

[1]	Note that IEEE 854 is inconsistent in its treatment of Inexact in that it states in §7 that the Inexact exception can coincide with Underflow, but does not allow the possibility of Underflow signaling Inexact in §7.5. It is assumed that the latter is an accidental omission.
[2]	See IEEE 754 §7.5.

[previous | contents | next]