stillwater-sc / universal / 26589976912

84%

master: 84%

Build Type

push

github

Committed by web-flow

Commit Message

fix(cfloat): frexp returns a [0.5,1) fraction (std::frexp semantics) (#1029)

cfloat's frexp returned a fraction in [1,2) with *exp = scale() (floor(log2|x|)),
which does not match std::frexp (fraction in [0.5,1), *exp = floor(log2|x|)+1) --
issue #1027. Generic code written to the std contract (and every other Universal
type's frexp: dd, qd, ereal, bfloat16 all use [0.5,1)) saw the wrong exponent.

Now: place the fraction at scale -1 (*exp = scale()+1). Extreme low-range configs
(es <= 2, minimum normal exponent >= 0) cannot represent any value below 1.0 as a
normal, so [0.5,1) is unachievable there; those fall back to the [1,2) fraction.
ldexp is UNCHANGED -- it rebuilds the exponent from scale(), so the round-trip
ldexp(frexp(x,&e),e) == x holds in every case. Also added the std special cases:
+-0/inf/nan return unchanged with *exp = 0 (the old code corrupted them).

Dependency sweep (the reason this is safe): the only callers of cfloat's frexp
are round-trip tests, which are convention-agnostic; no generic/templated code
instantiates cfloat's frexp expecting [1,2); manipulators/attributes/conversions
do not use it. So the change is confined to frexp + its test.

Test (fractional.cpp): assert the [0.5,1) fraction range for normal inputs where
representable, plus frexp(0)/inf/nan special cases; added half and cfloat<16,8>
coverage. (Note: a separate cfloat quirk -- isnormal() reports true for +-0 --
required excluding zero from the range assertion explicitly.)

Verified gcc + clang: cfloat_fractional passes; the #1022 elreal oracle (which
reads cfloat bits directly) is regression-clean.

Resolves #1027

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

Coverage Stats

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

9 existing lines in 2 files now uncovered.

46934 of 55859 relevant lines covered (84.02%)

5781818.2 hits per line