Skip to content

Keep the product uncertainty defined for many factors - #106

Merged
PierreRaybaut merged 1 commit into
developfrom
fix/product-uncertainty-many-factors
Oct 26, 2026
Merged

PierreRaybaut merged 1 commit into
developfrom
fix/product-uncertainty-many-factors

Conversation

@PierreRaybaut

Copy link
Copy Markdown
Contributor

Closes #105

Summary

Since #86, the first-order uncertainty of a product of signals is computed from the mantissas and exponents of the factors (np.frexp), but the products of the mantissas before and after each factor used np.cumprod. Each mantissa lying in [0.5, 1), these products decreased geometrically with the number of factors and underflowed, even when the product itself was representable: the uncertainty was wrong (subnormal numbers), then zero, from about 150 float32 or 1 074 float64 factors — e.g. 0 instead of 0.3317 for 1 100 factors equal to 1 with an uncertainty of 0.01 each, and dy = 0 for product() of 200 float32 signals.

  • The running products of the mantissas (prefix and suffix) are now renormalized at each step (np.frexp of the current product, exponents accumulated as int64): they stay in [0.5, 1) whatever the number of factors.
  • Scaling by powers of two is exact: results are bit-identical wherever no intermediate product underflowed (checked on 3 000 random cases with up to 11 real, complex, float32 and float64 factors spanning 10⁻³⁰ to 10³⁰, zeros included; existing tests unchanged).
  • The result changes for many factors: the contract of sigima.signal.product, published at version 1 with Sigima 1.3.0, goes to version 2 (the one-off exception of 1.4 does not apply to later changes), qualified at version 2.
  • Release notes: product uncertainty bullet and contract versions bullet (product at version 2), French translation updated (checked with a gettext build + sphinx_intl update).

Validation

  • New tests: 300, 1 100 and 5 000 float64 factors, 200 and 1 000 float32 factors (σ = 0.01 √n); 1 000 factors of 0.6 (representable product 0.6¹⁰⁰⁰); 4 000 alternating factors 10³ and −10⁻³ (product close to 1, mantissa product about 0.5²⁰⁰⁰). 5 of these 6 cases fail with the former implementation.
  • Full suite: 2340 passed; --qualification-report: no problem (product v2 qualified, validation and replay passed).
  • DataLab develop against this branch: provenance, replay, capsule and signal feature tests pass (163); DataLab reads the local contract versions dynamically, no fixture records sigima.signal.product.

@PierreRaybaut PierreRaybaut added the bug Something isn't working label Oct 26, 2026
Since #86, the first-order uncertainty of a product of signals is computed
from the mantissas and exponents of the factors, but the products of the
mantissas before and after each factor were computed with np.cumprod. Each
mantissa lying in [0.5, 1), these products decreased geometrically with the
number of factors and underflowed, even when the product itself was
representable: the uncertainty was wrong, then zero, from about 150 float32
or 1074 float64 factors (e.g. 0 instead of 0.33 for 1100 factors equal to 1
with an uncertainty of 0.01 each).

The running products of the mantissas are now renormalized at each step
(np.frexp of the current product, exponents accumulated as integers), so
that they stay in [0.5, 1) whatever the number of factors. Scaling by powers
of two is exact: the results are bit-identical wherever no intermediate
product underflowed.

The result changes for many factors: the contract of sigima.signal.product,
published at version 1 with Sigima 1.3.0, goes to version 2, qualified.

Closes #105

Assisted-by: Claude Opus 5.5
@PierreRaybaut
PierreRaybaut force-pushed the fix/product-uncertainty-many-factors branch from 2184af6 to 7e1c4c2 Compare October 26, 2026 08:35
@PierreRaybaut
PierreRaybaut merged commit 5303e3f into develop Oct 26, 2026
6 checks passed
@PierreRaybaut
PierreRaybaut deleted the fix/product-uncertainty-many-factors branch October 26, 2026 08:40
@ThomasMalletCodra ThomasMalletCodra added this to the v1.4.0 milestone Oct 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants