[Octave-bug-tracker] [bug #63440] [octave forge] (signal) sosfilt - NaN

[Charles Praplan]

Follow-up Comment #1, bug #63440 (project octave):

In https://savannah.gnu.org/bugs/?func=detailitem&item_id=60597, I proposed
updates for several functions handling poles and zeroes to corrected several
problems. This includes the function zp2sos.

During the development the following question arized : should the real poles
and zeros be combined as the complex conjugates ones?

When rewriting the function zp2sos, the first idea was to have an input
parameter, DoNotCombineReal, in the function
\octave-7.3.0-w64\mingw64\share\octave\packages\signal-1.4.3\zp2sos.m to let
the user decide.

Finally this parameter has been fixed to 1 inside the function (line 78).

Let examine the results in both cases

In your example,

Without combining the real poles and zeros we get (with your data):
  sos =
          0   0.0008   0.0008   1.0000  -1.9263   0.9296
          0   1.0000   1.0000   1.0000  -1.9914   0.9914
          0   1.0000  -1.0000        0        0   1.0000
          0   1.0000  -1.0000        0        0   1.0000
        
When combining the real poles and zeros we get
  sos2 =
     7.9956e-04   1.5991e-03   7.9956e-04   1.0000e+00  -1.9263e+00  
9.2963e-01
     1.0000e+00  -2.0000e+00   1.0000e+00   1.0000e+00  -1.9914e+00  
9.9140e-01        


Mathematically, both solutions seem to be correct, because when recalculating
the transfer functions, we get same result

  >> [B,A]=sos2tf(sos)
  B =
     7.9956e-04            0  -1.5991e-03            0   7.9956e-04
  A =
     1.0000  -3.9176   5.7569  -3.7609   0.9216
  
  >> [B,A]=sos2tf(sos2)
  B =
     7.9956e-04            0  -1.5991e-03            0   7.9956e-04
  A =
     1.0000  -3.9176   5.7569  -3.7609   0.9216


The problem is the function sosfilt, which seems not to handle transfer
functions with leading zeros in the denominator.

To overcome your problem:
- edit the function 
\octave-7.3.0-w64\mingw64\share\octave\packages\signal-1.4.3\zp2sos.m
- change the value of DoNotCombineReal to 0 on line 78.

For the future, I will reexamine the choice of this parameter:
Value to be modified?
Value depending on filter type?
Default value rather that fixed value?
etc.

Suggestions are welcome.




    _______________________________________________________

Reply to this item at:

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

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