octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #46440] [octave forge] (signal) missing functi


From: Tony Richardson
Subject: [Octave-bug-tracker] [bug #46440] [octave forge] (signal) missing function lp2lp
Date: Sat, 10 Apr 2021 12:13:46 -0400 (EDT)
User-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/89.0.4389.114 Safari/537.36

Follow-up Comment #5, bug #46440 (project octave):

After sleeping on this, I wonder if my original implementations (files
51223-51226) might be more robust than the newer ones that use sftrans (files
51227-51230).  They really aren't much uglier than the implementation of
sftrans.  I could see moving all of the coefficient transformation code into a
common function (kind of like sftrans) so that the implementations of lp2lp,
etc are cleaner.

The newer functions use tf2zp to transform from the transfer function
(coefficient) representation to the zero-pole representation, sftrans is then
used to transform the zero-poles of the prototype filter to those of the
desired filter (lp, hp, etc), then zp2tf is used to transform the zeros and
poles back to the transfer function (coefficients) of desired filter. The
original implementations directly transform the coefficients of the prototype
filter to those of the desired filter using polynomial multiplication (conv)
operations.  I would think that the direct transformation in the original code
would be more accurate than the multiple transformations in the newer code,
but I have not tested this at all.  (It seems as if the newer code could also
introduce extraneous poles and zeros, but I am not sure.)  The newer code uses
existing Octave functions that have been tested over time while the original
functions have undergone very little testing.

I would guess that when there are two different algorithms that can be used to
implement an Octave function a decision is based on accuracy and robustness
(speed wouldn't appear to be much of a concern for these functions).  I'll try
to do some more testing of the original functions (maybe refactor and clean up
the code a bit) and compare results to the newer functions.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?46440>

_______________________________________________
  Message sent via Savannah
  https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]