[Octave-patch-tracker] [patch #8535] [signal] firpm (new remez)

[Laurent Goulet]

Follow-up Comment #3, patch #8535 (project octave):

This looks like a good alternative to remez. 
I did however notice a few minor things:

Differentiator design from the original PM program used a 1/f weight only in
the passband. This typically results in a lower relative error in the
passband.
For example,

remez(59, [0 0.2 0.3 1], [0 1 0 0], 'differentiator')

with the patch <https://savannah.gnu.org/bugs/download.php?file_id=32732> for
Bug #38134 <https://savannah.gnu.org/bugs/?38134>
yields a filter with relative error of 0.074% in the passband and an absolute
equiripple error of 0.0074 in the stopband
(which corresponds to some textbook examples of PM program execution).
firpm <https://savannah.gnu.org/patch/download.php?file_id=32118> on the other
hand yields a filter with a relative error of 0.2%
in the passband and a maximum absolute error (not equiripple) of 0.01 in the
stopband.

Also, the code seems to trigger a preprocessing bug in Visual Studio with the
max macro arguments at lines 620 & 643 of file #32118
<https://savannah.gnu.org/patch/download.php?file_id=32118> 
(a simple workaround being to use a temporary, eg.
tmp=fabs(E(i)),max=max(max,tmp)). 
I realize that this package is typically not built with Visual Studio so that
should generally not be an issue.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/patch/?8535>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/