stillwater-sc / universal / 37004798671

88%

master: 84%

push

github

fix(takum): round + - * / and fma once, not twice through a double (#1621)

Narrow takums evaluated arithmetic in a double and converted back, which
rounds twice: to 53 bits, then to the takum. That is harmless only when
53 >= 2s + 2 for an s-bit significand (Figueroa), i.e. nbits <= 26 + rbits,
29 for rbits = 3. takum<30,3> through takum<57,3> were exposed:
takum<32,3> 0x44000001 * 0x40000001 gave 0x44000002, where the correctly
rounded product is 0x44000003. The gate now reads
2 * (maxCharBits + 1) + 2 > 53, so those widths take the exact integer path
(takum_wide_arithmetic.hpp) that takum<64,3> already used.

fma was worse, and at every width. std::fma rounds to double before the
takum rounding, and no width makes that safe: when a*b is exactly a takum
midpoint and c is tiny, the double drops c and the tie goes to even instead
of to c's side. takum<16,3> fma(a, b, minpos) was wrong for 2822 of the
5648 operand pairs in [1,2) whose product is a midpoint -- below the new
gate, so moving it would not have helped. fma now takes the exact path at
every width.

Tests: random sampling does not find these (0 in 10^8 pairs for
takum<32,3>), so wide_arithmetic.cpp now constructs them and checks them
against its exact 1024-bit reference, at regression level 1:
  near-midpoint products, takum<32,3> and takum<40,3> (with the issue's
  three quoted products)          756 / 789 wrong before, 0 now
  fma midpoint + tiny, takum<16,3> and takum<32,3>
                                  866 / 2000 wrong before, 0 now
The binary-op and fma reference checks are factored out of their sweeps
so the constructed cases reuse them unchanged. All four regression levels
of wide_arithmetic pass, as does the takum and takum_log suite.

Cost on an Apple M-series, takum<32,3>: add 77 -> 98 ns, mul 81 -> 47 ns,
div 69 -> 203 ns, fma 130 -> 91 ns; takum<16,3> fma 120 -> 107 ns.

Still open from #1616: sqrt is double-rounded the same way and has no
integer path yet, and to_ieee754<floa... (continued)

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

45621 of 53033 relevant lines covered (86.02%)

9705198.5 hits per line