stillwater-sc / universal / 32520953030

85%

master: 84%

Build Type

push

github

Committed by web-flow

Commit Message

fix(elreal): let div_online reach the depth the caller asks for (#1374)

* fix(elreal): let div_online reach the depth the caller asks for

div_online's dense-divisor path pinned its Newton reciprocal to a depth derived
from the host's exponent range:

    target = (-min_exponent - 2*k) / k     // 17 on double, 3 on float

so every division by a multi-block value stopped at 17 blocks (~271 digits) on a
double host and 3 blocks (~22 digits) on float, no matter how many blocks the
caller pulled. It is the same mistaken premise #1362 removed elsewhere -- a block
carries its scale in a wide integer<256> exponent, so min_exponent bounds nothing
about how deep an expansion may go. #1361/#1362 swept out the min_exponent+2k
guards; this one is a target DEPTH rather than a guard, so it survived.

div_online now takes that depth as a parameter (default kDenseQuotientDepth = 64,
matching the eager div()'s existing default and derived from no host property).
Depth bounds the dense path only: long division is genuinely streaming and
produces blocks for as long as the caller pulls. The dense path cannot be lazy in
the same way -- Newton recomputes the whole reciprocal per depth rather than
extending it, so a deeper pull would not agree block-for-block with a shallower
one -- which is why it takes a budget up front.

Two call sites now pass what they know:
- elreal::operator/= passes precision() plus a small guard, so the class facade's
  division finally honours the precision the object was given. A Newton iteration
  for sqrt(2) written against the facade stalled at 282 digits at any target
  depth; it now doubles per step as Newton should (48 -> 97 -> 195 -> 391 -> 513).
- the Payne-Hanek reduction in trigonometry.hpp passes its own reddepth. It
  computes exactly how many blocks of pi/2 it needs to cover |x|'s binade plus
  the output precision, then divided at 17 blocks regardless -- the comment said
  "full precision" and meant it, but did not get it.

Not fix... (continued)

Coverage Stats

11 of 11 new or added lines in 3 files covered. (100.0%)

10 existing lines in 1 file now uncovered.

43088 of 50469 relevant lines covered (85.38%)

7276229.34 hits per line