bugGNU Octave - Bugs: bug #51936, [octave forge] (signal) zp2sos...

 
 

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

Submitter:  fietew <fietew>
Submitted:  Mon 04 Sep 2017 04:30:20 PM UTC
   
 
Category:  Octave Package Severity:  1 - Wish
Priority:  1 - Later Item Group:  Matlab Compatibility
Status:  Fixed Assigned to:  lostbard
Originator Name:  Open/Closed:  * Closed
Release:  * dev Operating System:  * Any
Fixed Release:  None Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Fri 28 Oct 2022 12:13:41 PM UTC, comment #5: 


Signal 1.4.3 released

I believe the issues have been addressed on other tickets, so closing as fixed

If that is not the case, we can reopen or file a new ticket for any additional fixes

John Donoghue <lostbard>
Group Member
Mon 03 May 2021 04:22:22 PM UTC, comment #4: 

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)

Charles Praplan <charprap>
Tue 05 Sep 2017 05:48:22 PM UTC, comment #3: 

Thanks. This is a case that is currently not supported in the sos2{tf,zp} and {tf,zp}2sos functions, as mentioned in the doc strings for these functions. Any patches to support this in these four functions is welcome.

Mike Miller <mtmiller>
Group Member
Mon 04 Sep 2017 05:21:26 PM UTC, comment #2: 

Matlab's output is imho the correct one:

ans =

     0     1    -1     1     0    -1
ans =

     1     0    -1     1     0    -1
ans =

     1    -1     0     1     0    -1


fietew <fietew>
Mon 04 Sep 2017 04:52:51 PM UTC, comment #1: 

Well let's look at the inverse operation:


[z, p, k] = sos2zp ([1 -1 0 1 0 -1])
z =

   1
   0

p =

  -1
   1

k =  1


This matches your third line. This implies that the zeros array may have been padded.

And if you look into zp2sos.m, if the number of real zeros is not even, the z array is padded by a single 0. This makes the first the same as the third.

What does Matlab do with these examples? What do you think the results should be?

Mike Miller <mtmiller>
Group Member
Mon 04 Sep 2017 04:30:20 PM UTC, original submission:  

Try:


zp2sos([1],[-1; 1], 1)
zp2sos([1; -1],[-1; 1], 1)
zp2sos([1; 0],[-1; 1], 1)


The input describes the following Systems:
1st Line: H(z) = (z-1)/((z-1)*(z+1)) = (z^(-1) - z^(-2))/(1-(z^-2))
2nd Line: H(z) = ((z-1)*(z+1))/((z-1)*(z+1)) = (1-z^(-2))/(1-z^(-2))
3rd Line: H(z) = ((z-1)*z)/((z-1)*(z+1)) = (1 - z^(-1))/(1-z^(-2))

Output:

ans =

   1  -1   0   1   0  -1
ans =

   1   0  -1   1   0  -1
ans =

   1  -1   0   1   0  -1


The third output is equal to the first one, which should not be the case, since the systems are not the same. The documentation (https://octave.sourceforge.io/signal/function/zp2sos.html) says "The b0 entry must be nonzero for each section.", which explains the behavior, but does not preserve the properties of the first system.

fietew <fietew>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #51377:  sos.7z added by charprap (4KiB - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by lostbard (Posted a comment)
  • -email is unavailable- added by charprap (Updated the item)
  • -email is unavailable- added by fietew (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 17 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-28 lostbard StatusPostponed Fixed
        Assigned toNone lostbard
        Open/ClosedOpen Closed
    2021-05-03 charprap Attached File- Added sos.7z, #51377
    2019-02-27 mtmiller Operating SystemGNU/Linux Any
    2019-02-26 mtmiller Carbon-CopyRemoved 80942 -
    2019-02-26 mtmiller Releaseother dev
    2018-04-03 mtmiller Priority3 - Low 1 - Later
    2018-03-20 mtmiller StatusConfirmed Postponed
        Release4.0.0 other
    2017-09-05 mtmiller Severity2 - Minor 1 - Wish
        Priority5 - Normal 3 - Low
        Item GroupIncorrect Result Matlab Compatibility
        StatusNeed Info Confirmed
    2017-09-04 mtmiller Severity3 - Normal 2 - Minor
        StatusNone Need Info
        Summaryzp2sos wrong results for single zero [octave forge] (signal) zp2sos wrong results for single zero

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code