stillwater-sc / universal / 32449306562
85%
master: 84%

LAST BUILD BRANCH: refactor/1334-phase-n-integer-core
DEFAULT BRANCH: master
Ran
Jobs 1
Files 620
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 85.375% (+0.004%) from 85.371%
32449306562

push

github

web-flow 
test(elreal): sparse expansions are exact -- and the #1364 caveat was wrong (#1367)

* test(elreal): sparse expansions are exact -- and the #1364 caveat was wrong

#1364 asked whether agreed_decimal_digits credits how far an expansion REACHES
rather than what it CARRIES, on the evidence that a bfloat16 e had 52 of 52 gaps
wider than k while its agreeing digits exceeded blocks*k*log10(2). I raised that
caveat and put it in the v4.9.0 release notes. It was wrong, for two reasons.

Wide gaps are not a narrow-host phenomenon. A depth-32 e has 35 of 35 gaps above
k on DOUBLE (k=53, gaps reaching 59) and 29 of 29 on bfloat16. It is simply the
shape of a 0-overlap expansion, so there was never an anomaly to explain.

And blocks*k is not a bound on agreement, because an expansion is a signed SUM
rather than a concatenation of bit fields. Six of the thirty components of a
bfloat16 e are negative; a low component borrows from a higher one, so the sum's
bit pattern is not the union of the components' patterns and the block exponents
carry information alongside the significands. My first attempt to check this by
bit-coverage reported "17 of 60 uncovered bits are nonzero, real information
loss" -- that model was simply inapplicable to a signed sum, and it contradicted
the exact arithmetic, which is what should have been believed.

Checked outside the library instead: the depth-32 expansions were rebuilt in
exact rational arithmetic and compared against a 3000-digit reference generated
by exact integer arithmetic (sum 1/n!, 1160 terms). bfloat16 claimed 78 digits
and delivered 78, half 122 and 122, float 263 and 263. agreed_decimal_digits is
reporting correctly.

The sweep oracle now guards the property that would actually fail if sparseness
were a defect: that a product of two deliberately sparse operands equals the
exact dyadic product, alongside a 0-overlap check on the operands themselves.

Also corrected the published v4.9.0 release notes, which carried the wr... (continued)

43083 of 50463 relevant lines covered (85.38%)

7152446.76 hits per line

Coverage Regressions

Lines Coverage ∆ File
8
93.65
 -0.48% include/sw/universal/number/cfloat/cfloat_impl.hpp
Jobs
ID Job ID Ran Files Coverage
1 32449306562.1 620
85.38
 GitHub Action Run
Source Files on build 32449306562