stillwater-sc / universal / 34919720617

86%

master: 84%

Build Type

push

github

Committed by web-flow

Commit Message

fix(areal): saturate past maxpos instead of wrapping into the sign bit (#1508)

Values just above the largest finite exponent came out with the wrong sign or as nan
instead of saturating to (maxpos, inf) (#1503): areal<16,5> maxpos + maxpos was
-6.08e-05, 65536 * 2 was -0, and 65536 + 65472 was nan. Two causes, in every conversion:

- MAX_EXP was 2^es - EXP_BIAS, one more than the largest finite scale. A value of that
  scale passed the overflow checks, and its biased exponent ran into the sign bit. It is
  now 2^es - 1 - EXP_BIAS.
- In the top binade, values past maxpos + ulp truncate onto the all-ones fraction, which
  encodes inf (ubit clear) or nan (ubit set). saturate_reserved() maps a finite result
  that lands there to (maxpos, inf) or (maxneg, -inf), the interval larger values already
  get. It runs at the end of the integer, float and double assignments and of
  convert(blocktriple), so +, -, *, / and parse() saturate too.

The new static/range/areal/conversion/saturation.cpp checks against a reference that uses
no areal conversion: every encoding of a small configuration is enumerated and its exact
value tabulated. Conversion from double and float is checked for every exact value, every
midpoint, and a sweep of the top binade and beyond; +, - and * of every pair of exact
values against their exact double result; and the boundary of areal<32,8>, the native
integer path of areal<64,6>, and areal<128,15>. The arithmetic check runs on single-limb
configurations, since + - * are wrong where the exponent field straddles two limbs
(#1506), and accepts either sign on an exact zero (#1507).

fix(areal): convert from long double without narrowing to double

CodeRabbit on #1508. operator=(long double) narrowed to double first, which rounds: a
finite value past DBL_MAX became inf, one below double's range an exact zero, and bits
below double's precision were gone before truncation could see them, so 1 + 2^-60 and
1 - 2^-60 both read as exactly [1] inste... (continued)

Coverage Stats

60 of 60 new or added lines in 1 file covered. (100.0%)

9 existing lines in 1 file now uncovered.

44048 of 51302 relevant lines covered (85.86%)

8128140.41 hits per line