stillwater-sc / universal / 26581102578
84%
master: 84%

LAST BUILD BRANCH: main
DEFAULT BRANCH: master
Ran
Jobs 1
Files 661
Run time 3min
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: 84.001% (-0.003%) from 84.004%
26581102578

push

github

web-flow 
test(elreal): independent exact dyadic oracle for Phase 1-4 building blocks (#1023)

* test(elreal): independent exact dyadic oracle for Phase 1-4 building blocks

Ports the ereal/#987 approach (dyadic_exact.hpp, an einteger-backed exact
dyadic-rational reference that shares no code with the algorithms under test) to
the elreal McCleeary substrate, removing the Phase 1-4 reliance on `long double`
-- which is not an exact oracle (it aliases double on MSVC/ARM/RISC-V, giving
zero headroom over the type under test). This is the Phase-5 precondition: lock
down a *validated* baseline before stacking more arithmetic on it.

New elastic/elreal/arithmetic/exact_value_oracle.cpp asserts, against the dyadic
oracle (exact(block) = from_double(double(b.v)) << b.exp; exact(ZBCL) = sum of
block dyadics):
  * block_two_sum / block_two_mult: exact(high)+exact(low) == exact(a){+,*}exact(b)
    bit-for-bit, with a nonzero error tolerated ONLY when the residual block is a
    nonzero subnormal (the cfloat<24,5> #942 representability floor). A wrong high
    part or a wrong NORMAL residual still fails.
  * threeAdd + add(): exact equality on the wide-exponent RN hosts.
Randomized + adversarial sweeps (cancellation, scale separation, classic
0.1+0.2). Strict-exact PASSES on all five round-to-nearest hosts:
float, double, half, cfloat<24,5> (modulo #942), cfloat<32,8>.

FINDING the loose Phase 1-4 tolerances were masking: bfloat16 is NOT an
exact-EFT host. It rounds toward zero (numeric_limits::round_style ==
round_toward_zero; its float->bf16 cast is `bits >> 16`, no rounding), and
Knuth/Dekker EFTs are exact only under round-to-nearest -- so on bfloat16 they
leak up to ~1 residual-ulp. This is intentional bfloat16 behaviour, not an elreal
bug; it makes elreal-over-bfloat16 inherently approximate (like the cfloat<24,5>
floor, but from the rounding mode rather than the exponent range). bfloat16 is
PINNED with a truncation bound (double is its exact reference -- ~45 bits of... (continued)

46879 of 55808 relevant lines covered (84.0%)

5787609.44 hits per line

Coverage Regressions

Lines Coverage ∆ File
10
31.43
 -3.57% include/sw/universal/verification/test_suite_randoms.hpp
Jobs
ID Job ID Ran Files Coverage
1 26581102578.1 661
84.0
 GitHub Action Run
Source Files on build 26581102578