[Octave-bug-tracker] [bug #60597] Bug in functions handling SOS

[Charles Praplan]

URL:
  <https://savannah.gnu.org/bugs/?60597>

                 Summary: Bug in functions handling SOS
                 Project: GNU Octave
            Submitted by: charprap
            Submitted on: Thu 13 May 2021 07:56:50 AM UTC
                Category: None
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Incorrect Result
                  Status: None
             Assigned to: None
         Originator Name: 
        Originator Email: 
             Open/Closed: Open
                 Release: 6.2.0
         Discussion Lock: Any
        Operating System: Any

    _______________________________________________________

Details:

Hi,

I already posted this under an old bug report (2017), but I think it has not
been seen, since nobody replied...

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 starting 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.




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: Thu 13 May 2021 07:56:50 AM UTC  Name: sos.7z  Size: 4KiB   By: charprap

<http://savannah.gnu.org/bugs/download.php?file_id=51429>

    _______________________________________________________

Reply to this item at:

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

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