[Octave-bug-tracker] [bug #51936] [octave forge] (signal) zp2sos wrong results for single zero

[Charles Praplan]

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

Hi,

I have encountered a problem with the function tf2sos which delivered a wrong
result:

  tf2sos([0 0 1], [1 1 1])
  ans =
     1.0000        0        0   1.0000   1.0000   1.0000
   
which is obviously different from sarting point.   

Having a look in savannah, I found this old bug report, handling the same
topic.

So I worked a little bit on these functions handling second order sections,
and I propose
some corrections (4 m-files appended: sos.7z)
The main idea behind the changes is to make the functions more general to
handle polynomial
coefficients, zeros and poles regardless which transfer function they
represent.
So the modified functions can handle analog and digital filer.
   

tf2sos     : tf2sos is ok but calls zp2sos which does not work correctly.

zp2sos     : zp2sos assumes that all 2nd-order polynomials are monic.
             This is a restriction, which does not even have a physical
reason.
             If the assumption is not met, the function does not issue an
error,
             but returns a wrong result.
         
             The function has been rewritten to overcome the limitation.
             Furthermore, a flag allows not to combine real poles or zeros.
         
             However in order to get correct results in all cases, a
correction is
             needed in the function cplxreal as described below.
         
cplxreal.m : at line 70, real zeroes or poles with value 0 were handled as
complex.

             The correction corrects this.

sos2tf     : sos2tf removes trailing zeros independently in numerator and
denominator.
             This is not correct (even if Matlab does the same).
         
             The new version only removes trailing zeros which are present
both in
             numerator and in denominator.
             The new version also removes leading zeros in the same way.
        
             My opinion is that the functions which return numerator and
denominator
             should return vectors of the same size (even if Matlab does
not).
             A good practice for the user is to always apply this rule.
         
sos2zp     : sos2zp considers the gain as the product of the b0 coefficients
and
             issues an error if it is zero.
             This means that all b0s must be non-zero. This is a restriction
which
             has no reason to exist.
         
             In the new version, the gain is calculated as the product of the
first
             non-zero coefficients of the numerators.

I hope this will be useful and will be integrated in next release.
In the meantime I will make some more checks.



(file #51377)
    _______________________________________________________

Additional Item Attachment:

File name: sos.7z                         Size:4 KB
    <https://file.savannah.gnu.org/file/sos.7z?file_id=51377>



    _______________________________________________________

Reply to this item at:

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

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