Decimal Arithmetic Specification,
version 1.08 Copyright (c) IBM Corporation, 2003. All rights
reserved. © |
8 Jan 2003 |

[previous | contents | next] |

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 854 §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:

**Conversion syntax**-
This occurs and signals

*invalid-operation*if an 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 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 sign of the dividend. **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
`[0,sNaN]`(*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]` - the right-hand operand of the
**rescale**operation has a non-zero fractional part, or is outside the permitted range - 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 the right-hand operand has a non-zero fractional part, or has more than 9 digits, 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.

`[0,qNaN]`. - an operand to an operation is
**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) would be greater than the largest value that can be handled by the implementation (the value E_{max}). It also occurs if a**rescale**operation would require greater precision than is available.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*, 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.

**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. - For
**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.

The 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, and any Inexact trap takes precedence over Rounded.

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 854 §8.1).

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 854 §7.4. |

[previous | contents | next]