RemezEngine

Development biography · earlier archive

Development profile compiled from project source and retained records in October 2026. Dates and test results describe those records; they do not imply a new build, live acceptance test or public release.

Biography

Equiripple design is how you get the most stopband attenuation out of a fixed number of filter taps. The Parks–McClellan algorithm finds, for a given length and a given set of frequency bands, the filter whose worst-case weighted error is as small as it can possibly be — and the Chebyshev alternation theorem makes that optimum checkable, because the optimal filter is the unique one whose error touches ±δ with strictly alternating sign at r+1 frequencies.

That theorem is also what makes the algorithm treacherous to implement. The quantity being approximated is the zero-phase amplitude A(ω), which is real and signed. What a naive transform of the taps hands you instead is the real part of the response referred to sample 0, and for a linear-phase filter those differ by a factor of cos(ω(N−1)/2) — a carrier that changes sign roughly N/2 times across the band. An implementation that drives its extremal search with the wrong one will find the carrier's zeros instead of the error's peaks, and then report a beautiful δ for a filter that misses its specification badly. Nothing about the result looks wrong from the inside.

RemezEngine's history is the story of that bug being made and then found. The earliest code dates from 7 December 2025, written inside the NoiceColour application as two files — a struct Remez prototype and an "extended" helper file — which were later folded into a standalone package. Six successive snapshots survive from then through March 2026. All of them share the defect. Measured on the version as found: a 63-tap lowpass specified for roughly −58 dB reported δ = 9.4e-11 while its stopband actually peaked at −33.75 dB, about 24 dB short, and the reported δ and the reported stopband ripple inside the same result object contradicted each other by eight orders of magnitude. Even tap counts were worse than inaccurate: they were structurally impossible, because the tap-construction step mirrored coefficients about (N−1)/2 using integer division, which is not a symmetry axis for even N. A four-tap request returned [c1, c0, c1, 0] — not a linear-phase filter at all. The package had no tests, and its test target was commented out in the manifest.

The current engine replaces the design core outright. Each of the four linear-phase types is written as A(ω) = Q(ω)·P(ω), folding the type's fixed factor into the specification so that all four reduce to one problem: best Chebyshev approximation by a cosine polynomial. δ and the interpolant come from barycentric Lagrange form with no matrix at all — the obvious alternative, solving the (r+1)×(r+1) alternation system, was built first and measured returning garbage above about 250 taps while LAPACK reported success. The exchange starts from a least-squares seed, because a uniform start makes δ at iteration zero a high-order divided difference that underflows; coefficients are recovered by an in-band fit, because sampling the interpolant across the full range extrapolates beyond its node hull wherever a specification has a don't-care region, which imposed a ripple floor no tap count could beat; and whenever a multiple exchange would decrease |δ| the engine falls back to a single exchange, which is monotone by construction and cannot cycle, fixing a period-10 limit cycle on a 32-tap three-band bandpass.

The distinctive idea, though, is not any single numerical choice: it is that the library is built to be unable to flatter itself. Three mechanisms carry that. The tests assert the alternation theorem directly — 24 extremals, |E|/δ = 1.000000 at every one, strictly alternating — which is a proof of optimality rather than a comparison against remembered output, and every response is measured from the taps by an independent DFT so a design cannot pass by lying twice. converged means both that the exchange met its tolerance and that the returned taps demonstrably achieve the δ being reported. And failure is loud: design throws rather than returning quietly, rejects specifications that ask for gain where the chosen type forces a zero, and distinguishes ordinary non-convergence from a requested ripple below what double precision can resolve — cases whose remedies are opposite, since for the second the advice is to reduce the tap count.

The intended audience is a developer building audio or RF signal processing on Apple platforms who needs a filter that provably meets a stated specification, and who would rather be told that a design failed than handed one that quietly does not. A typical journey: call designTaps with band edges, desired gains and weights; read delta, alternationDeviation and converged off the result to confirm the design is what it claims; then either hand the taps to a real-time convolver in the FIRFilters package, or call exportFixedPointCHeader to emit a Q-format C header for an embedded target. Independent validation exists for the symmetric cases: against SemanticCompute v1.20.0's separately written RemezReference on a 61-tap lowpass, δ agrees to 0.0015031 against 0.0014995 and the realised stopband to −56.45 dB against −56.44 dB.

Modules and features

What a visitor can see, hear or try: nothing, currently. This is a headless library with no executable target, no sample app and no captured media. RemezVisualizer is the only visual surface and it must be hosted in a SwiftUI app to render; it has never been instantiated outside a preview. Any site presentation needs a host app built first.

Technical foundations

Swift 6.2, Foundation and Accelerate only — no third-party dependencies. vDSP for transforms and dot products; LAPACK dgels for the least-squares seed and the in-band coefficient fit (via the deprecated CLAPACK interface, which is the only build warning). Numerics: barycentric Lagrange interpolation with log-domain weight normalisation, Chebyshev recurrence evaluation, and a DCT-I-free in-band fit. Local packages: FIRFilters depends on RemezEngine by relative path and pins its own deployment floor to RemezEngine's; SemanticCompute is a test-time oracle only, deliberately not a dependency.

Maturity by feature, with evidence

Limitations

• Double-precision wall. A specification whose implied ripple falls below roughly 1e-12 relative to its band levels cannot be resolved; the engine reports this instead of returning noise. For a Hilbert transformer over 0.05–0.45 the wall falls between 127 and 151 taps.
• Types III and IV have no external oracle. SemanticCompute's family covers Types I and II only, so the antisymmetric work rests on the alternation-theorem tests alone.
• evaluateWeightedErrorNorm reads only the second half of the taps, so it cannot see damage that breaks symmetry, while its documentation says "any set of taps". Confirmed by independent reproduction; not yet fixed.
• Nine confirmed review findings are unapplied, mostly documentation inaccuracies in the recently carried-forward functions.
• A completeness claim in the package's own Archive/README.md is not yet proven. Three archive files were never opened. See the warning below.
• Not published, not installed, not run in an application.

Roadmap (aspirations, kept separate from the above)

Apply the nine confirmed findings; finish the archive survey; fold the branch into the studio’s main checkout; optionally restore the macOS 13 / iOS 16 floor; build a host app so the visualiser can be captured; consider a public release with a versioned git dependency.

FAQs

Why not just use a windowed sinc? For the same length and transition width, equiripple does considerably better. Measured independently at 61 taps: −56.4 dB equiripple against −36.7 dB for a Kaiser windowed sinc.

How do I know a filter is actually optimal and not just plausible? The alternation theorem makes it checkable. Read alternationDeviation (zero at the optimum) and converged, which is true only when the returned taps demonstrably achieve the reported δ.

Does it handle even tap counts? Yes — Types II and IV, with the half-integer bases they require. A four-tap design now comes back exactly symmetric.

Why does design throw instead of returning a filter? Because a filter that silently misses its specification is worse than no filter. Pass requireConvergence: false to receive it anyway, flagged.

Can I use it today? As a local Swift package, yes. There is no published release.