Skip to main content

thermite_compensated/specialized/
mod.rs

1//! Compensated's own backend layer, one rung below `thermite-special`'s.
2//!
3//! `thermite-special` exposes its math through a two-rung ladder: the user-facing
4//! `SpecialMath` / `SpecialMathWithPolicy` traits are blanket-implemented for anything
5//! that implements the corresponding `Specialized*Math<E>`, so a type supplies one
6//! backend and the whole public API materializes. That is how `Vector<R>`, `Dual`,
7//! `Compensated` and `Complex` all present the same surface without any of them writing
8//! it.
9//!
10//! For `Compensated` that ladder is one rung short. Its backend impl is a single blanket
11//!
12//! ```ignore
13//! impl<V: CompensatedFloatVector> SpecializedSpecialMath<Compensated<V::Element>> for Compensated<V>
14//! ```
15//!
16//! which covers every width at once - and the widths are not alike.
17//! `Compensated<Vector<f32>>` is double-single at ~48 bits of mantissa;
18//! `Compensated<Vector<f64>>` is double-double at ~106. Anything carrying fitted
19//! coefficients needs a *different* table for each, and that impl has nowhere to put
20//! two. That, not any missing algorithm, is why the gamma family sat unimplemented.
21//!
22//! So this module adds the missing rung. The traits here are the real backend for the
23//! coefficient-bearing functions; `Compensated`'s `SpecializedSpecialMath` impl is
24//! blanket-implemented over them exactly the way `SpecialMath` is blanket-implemented
25//! over *it*. Per-width impls live in `ps` / `pd` submodules, named after
26//! `thermite-special`'s own.
27//!
28//! Methods carry element-agnostic defaults - series, continued fractions, recurrences,
29//! which are correct at any width - so a width that needs no special treatment
30//! implements the trait with an empty block, and a per-element impl is only ever an
31//! optimization or a precision fix, never a prerequisite.
32
33pub mod special;
Last built: 2026-09-08 21:35:55 UTC