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

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

[Octave-bug-tracker] [bug #49996] signal package: cheby2 produces zeros


From: Bill Lash
Subject: [Octave-bug-tracker] [bug #49996] signal package: cheby2 produces zeros that are not quite complex conjugate pairs
Date: Wed, 11 Jan 2017 04:48:28 +0000 (UTC)
User-agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:50.0) Gecko/20100101 Firefox/50.0

Follow-up Comment #14, bug #49996 (project octave):

I agree that the issue in butter is not with cplxpair, although I think there
are some issues with cplxpair.  I was able to get the butter example to work
by playing with sftrans.  In sftrans when the poles and zeros are adapted from
low pass with unit cutoff to the proper type (bandpass in this case) a new set
of poles and zeros are calculated. By basically forcing these to be pairs, the
result will pass cplxpair.

I wrote a function that is like cplxpair, but averages the real and imaginary
parts of the pairs, and called that in the bandpass case of sftrans on the b
value used to calculate the poles.  

here is the patch to sftrans:

--- ../octave/signal-1.3.2/sftrans.m    2017-01-05 22:10:48.690453045 -0600
+++ sftrans.m   2017-01-07 22:46:39.951910271 -0600
@@ -141,6 +141,7 @@
 ## ----------------  -------------------------  ------------------------
       Sg = Sg * (C/(Fh-Fl))^(z-p);
       b = Sp*((Fh-Fl)/(2*C));
+b=cplxpair_eqlz(b);
       Sp = [b+sqrt(b.^2-Fh*Fl), b-sqrt(b.^2-Fh*Fl)];
       if isempty(Sz)
         Sz = zeros(1,p);


and the cplxpair_eqlz.m is 


function ze = cplxpair_eqlz (z, thresh = 100*eps)

  ## interesting for testing: if nargin<2, thresh=1E-3; endif

  if isempty(z)
    ze=[];
  else
    ze = cplxpair(z); # sort complex pairs, real roots at end
    nz = length(z);
    nzrsec = 0;
    i=nz;
    while i && abs(imag(ze(i)))<thresh # determine no. of real values
      ze(i) = real(ze(i));
      nzrsec = nzrsec+1;
      i=i-1;
    endwhile
    nzsect2 = nz-nzrsec;
    if mod(nzsect2,2)~=0
      error('cplxreal: Odd number of complex values!');
    endif
    for i = 1:2:nzsect2-1
      ze(i) = (ze(i) + conj(ze(i+1)))/2;
      ze(i+1) = conj(ze(i));
    endfor
  endif

endfunction


realistically, any time a filter that produces real valued output from real
valued input should have all the poles and zeros that are either real, or
complex conjugate pairs.  I'm not sure if averaging the real and imaginary
parts is better or worse than choosing one of the pair, and conjugating it to
get the other member of the pair.


    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?49996>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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