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

LAST BUILD BRANCH: main
DEFAULT BRANCH: master
Ran
Jobs 1
Files 644
Run time 2min
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.499% (+0.02%) from 85.484%
30402066067

push

github

web-flow 
fix(lns): correct quire<lns> accuracy docs -- it is NOT an exact accumulator (#1242)

quire_mul(lns,lns)'s header claimed lns values are "always exactly representable as
powers of 2", implying quire<lns> is an exact accumulator like quire<posit>/quire<cfloat>.
That is false: an lns product is 2^(k + m/2^rbits), irrational for m != 0 (unique
factorization forces q | p if 2^(p/q) were rational), so it is not a dyadic rational and
cannot be represented exactly in ANY linear fixed-point quire at any width. lns simply
does not admit an exact dot product -- a structural property posit and cfloat have (their
values are dyadic) and lns does not.

The real, documented defect: quire_mul rounds each product at ~the lns representation
precision (a blocktriple with 2*rbits significand bits) instead of the quire's precision,
so the quire-dot error is bounded by the product-representation error, not the
accumulation -- and for narrow lns (e.g. lns<16,8>) the quire is orders of magnitude worse
than a promoted-double accumulator. For accurate lns dot products, promote to double.

This corrects the misleading comments in number/lns/fdp.hpp and adds an accuracy note to
quire_traits<lns>, so downstream code (e.g. the mp-blas level-1 accumulator study) does
not assume the posit/cfloat exactness guarantee transfers. Behavior is unchanged.

New characterization test (static/quire/api/lns_quire_accuracy.cpp) pins the contract:
integer-exponent (power-of-2) operands with a power-of-2 result are exact; fractional
operands are not (quire-dot error, vs a long-double reference over the same quantized
values, sits orders of magnitude above binary64). Guards against reintroducing the false
"exact" claim. Green on gcc + clang.

The "exact lns quire" request in the issue is unachievable; a future enhancement could
round each product at the quire's full precision (single-rounding-per-term, still not
exact). See stillwater-sc/mp-blas#11.

Resolves #1203
Relates to stillwater-sc/mp-blas... (continued)

46915 of 54872 relevant lines covered (85.5%)

6795490.33 hits per line

Coverage Regressions

Lines Coverage ∆ File
5
50.45
 -4.5% include/sw/universal/verification/posit_test_suite_randoms.hpp
2
81.25
 0.22% include/sw/universal/number/posit1/specialized/posit_16_1.hpp
Jobs
ID Job ID Ran Files Coverage
1 30402066067.1 644
85.5
 GitHub Action Run
Source Files on build 30402066067