Using Rexx NUMERIC DIGITS and FUZZ for Exact Financial Calculations

Problem

Financial applications often require exact decimal arithmetic to avoid the rounding errors inherent in binary floating-point representations. When a program adds monetary values such as 0.10 and 0.20, a binary float may produce 0.30000000000000004, which is unacceptable for accounting or tax calculations.

Requirements

• Exact decimal representation with user-defined precision.
• Predictable rounding behavior for intermediate results.
• Ability to trap arithmetic errors without crashing the program.
• Isolation of numeric context so that subroutines can change precision without affecting callers.

Minimal Suitable Design

Rexx satisfies these requirements through two built-in controls:

1. NUMERIC DIGITS n – sets the number of significant decimal digits used for all arithmetic operations in the current scope.
2. NUMERIC FUZZ f – defines the tolerance for numeric comparisons; two numbers are considered equal if their difference is less than 10-f of the larger operand.

Both controls are part of the language core; no external libraries are required. The default DIGITS is 9, which may be too small for large financial aggregates, so it should be set explicitly.

Trust / Data Boundary

The interpreter maintains a numeric context per scope. Upon entering a subroutine or internal function, the current DIGITS and FUZZ values are saved; upon exit they are restored automatically. This means a subroutine can safely execute NUMERIC DIGITS 12 without altering the caller's precision, providing a clear trust boundary between caller and callee. Note that within a single scope, NUMERIC settings affect all arithmetic, including intermediate results, so an unexpected precision change can propagate through later calculations.

Operational Checks

Programs can query the active settings with the built-in functions DIGITS() and FUZZ(). If an arithmetic operation exceeds the precision implied by DIGITS, the interpreter raises the SYNTAX condition, which can be trapped with:

SIGNAL ON SYNTAX NAME handle_error
...
EXIT
handle_error:
    SAY 'Arithmetic error at line' SIGL
    EXIT 1

Thus, developers can verify that the configured precision is sufficient before performing critical calculations and fail safely when it is not.

Failure Modes

• Insufficient DIGITS – results are rounded to the specified number of significant digits; overflow of the digit limit raises a SYNTAX condition.
• Excessive DIGITS – increases memory usage and CPU time because each operation works with longer decimal strings; performance degrades as the digit count grows.
• Invalid FUZZ – specifying NUMERIC FUZZ f where f >= DIGITS or f < 0 triggers a SYNTAX condition.
• Misunderstood FUZZ – FUZZ affects only numeric comparisons, not arithmetic results; treating it as a rounding control leads to subtle bugs.
• Cross-platform consistency – decimal arithmetic semantics are defined by ANSI X3.274-1996 and TRL-2, so the same script should yield identical results on Regina Rexx, ooRexx, and IBM Rexx; verify on your target interpreters.

When the Design Would Change

Consider revising the design if any of the following arise:

• The application needs binary floating-point speed (e.g., massive scientific simulations) – then an external library or a compiled language would be preferable.
• Specific rounding modes (banker's rounding, round-up, round-down) are required beyond the default rounding implied by NUMERIC DIGITS; Rexx does not expose those directly.
• Performance profiling shows decimal arithmetic is a bottleneck and hardware-accelerated floating-point is acceptable after applying integer-scaled fixed-point techniques.

Example Configuration

The following script sets a precision of 10 digits, adds two monetary amounts, and checks the result. Run it with any ANSI-compliant Rexx interpreter (e.g., rexx exact_calc.rexx on Unix with Regina, or rexx.exe exact_calc.rexx on Windows). No special privileges are required.

/* exact_calc.rexx */
NUMERIC DIGITS 10
NUMERIC FUZZ   2   /* comparison tolerance of 1e-2 */

a = 0.10
b = 0.20
c = a + b
SAY 'Sum:' c

IF c = 0.30 THEN
    SAY 'Result matches expected value within fuzz.'
ELSE
    SAY 'Result differs: ' c

SAY 'Active precision:' DIGITS() 'digits, fuzz' FUZZ()
EXIT 0

Expected behavior: the sum displays as 0.3 (no binary floating-point artifacts), the comparison succeeds, and the final line confirms the active numeric context. If you set NUMERIC DIGITS 3 and then compute a value with more significant digits than the limit allows, the SYNTAX condition fires and can be trapped as shown above.

Verification Steps

1. Install a recent build of Regina Rexx or ooRexx.
2. Save the script above as exact_calc.rexx.
3. Execute it with the appropriate command for your platform.
4. Observe the output and compare with the description above.
5. Repeat the execution on a second interpreter to confirm cross-platform consistency.

Limitations and Practical Check

Rexx decimal arithmetic eliminates binary rounding errors but is slower than native floating-point because each operation works with variable-length decimal strings. To verify that the chosen DIGITS is sufficient for a given workload:

• Instrument the script to call DIGITS() before and after a series of calculations; ensure the value never changes unintentionally.
• Measure execution time with a simple timer (e.g., the TIME built-in function) and compare against a baseline with lower DIGITS.
• If latency exceeds acceptable thresholds, consider scaling to integer arithmetic (e.g., work in cents) or moving the heavy loop to a compiled language.

Summary

Rexx's built-in NUMERIC DIGITS and NUMERIC FUZZ provide a self-contained, scoped mechanism for exact decimal arithmetic suitable for financial applications. The language automatically saves and restores these settings across subroutine calls, offering a clear trust boundary. Operational checks via DIGITS(), FUZZ(), and SYNTAX trapping let developers validate precision and catch overflows. The design remains appropriate as long as the application tolerates the performance cost and does not require specialized rounding modes or binary floating-point speed.