#20410·scipy

ENH: signal: integrate new implementation of `remez`

Author: lucascolleyCreated Apr 7, 2024Updated Sep 18, 2026
Labelsenhancementscipy.signalC/C++sustain-2026

As noted by @DietBru in gh-7588, the current C implementation used in remez has some bugs (gh-7588 and gh-11968), and it would be nice to have a new implementation which is easier to maintain.

@sfilip has relicensed their C++ implementation at https://github.com/sfilip/firpm to BSD. Reposting their full comment:

Hi! My pleasure. I'm thrilled to help in any way that I can. As @ev-br mentioned, I have relicensed the code to BSD.

A first important matter to discuss is what kind of dependencies are allowed. There are two main ones in firpm, but I think they can probably be removed/replaced.

  1. eigen: I use the eigenvalue solver in Eigen to compute the set of points that will form the basis of the next iteration of the Remez/Parks-McClellan algorithm. Since my code started as a research project looking into the numerics of the algorithm, I wanted an eigensolver that was flexible enough to work with multiple precision floating-point arithmetic (this is why the routines in firpm are templated to work with double, long double and mpfr multiple precision arithmetic). Eigen offers that, but I would imagine that in SciPy only a double precision version of the algorithm has its place. If that is the case, then relying on Eigen might not be a necessity, since SciPy already has an eigenvalue problem solver in scipy.linalg.eig that works with double precision matrices.
  2. OpenMP: I use OpenMP to parallelize the search for the aforementioned set of points. This can be disabled, for instance. Another option is to write a pure Python version. I would go for this if the integration efforts on the C++ version look too cumbersome.

In any eventuality, I am happy to help with the integration or re-write of a Python version.

I've opened this issue to separate the discussion of this new implementation from the original bug report. cc @ja3443