[Octave-bug-tracker] [bug #51310] firls.m modification to include all 4 FIR types, Hilbert transformer, and differentiator

[Vlad]

Follow-up Comment #4, bug #51310 (project octave):

The more I think of it, the better suited this seems for the increment N part:
adding an extra parameter, say 'x', that, when added, makes the behaviour as
originally intended, otherwise (no argument, default) mimicks Matlab. Later
this day I'll make an example with what I mean.

About (2), I see that the results seem to get worse as N increases, at least
based on the existent examples in the discussion list. For example, according
to the results in
https://lists.gnu.org/archive/html/help-octave/2017-05/msg00179.html and the
followup https://lists.gnu.org/archive/html/help-octave/2017-05/msg00180.html,
if one considers "h" to be Octave's output and "g" to be Matlab's, then
plotting this should give an idea:

plot(diff(abs(fft(h,1024)(1:512))),"",diff(abs(fft(g,1024)(1:512))))

Zooming in on the passband region it can be seen that, as the order increases,
the 1/f^2 weighting is clearly consistent in for "h", but not for "g". Going
further with
https://lists.gnu.org/archive/html/help-octave/2017-05/msg00138.html (the 2nd
example, order 44) and the followup
https://lists.gnu.org/archive/html/help-octave/2017-05/msg00139.html, the
differences are more visible, and going even further with
https://lists.gnu.org/archive/html/help-octave/2017-06/msg00259.html (the
"firls_expected_output.txt" attachement) it can be seen that the passband for
"g" gets more and more distorted, but the general magnitude is close to the
requirements.

This is why I think Matlab must use some very small number for F(1)=0,
probably 1e-6 or similar, which, when used for cos(1e-6)/1e-6 results in a six
orders of magnitude number, which is then used to build the Q matrix which, in
turn, is used for a=Q\b. This must have a negative effect on precision.

The results I had with wxMaxima were numerical confirmations, since their
expintegral_e1(x) is accurate and can be used for bigfloats, as well.

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?51310>

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