freqz produces incorrect output

[Ben Abbott]

On Jan 25, 2009, at 3:38 PM, Ben Abbott wrote:

>
> On Jan 25, 2009, at 12:46 PM, Søren Hauberg wrote:
>
>> søn, 25 01 2009 kl. 12:07 -0500, skrev Ben Abbott:
>>> Søren, can you try these instead?
>>>
>>> 	freqz ([ones(1, 20), zeros(1, 768-20)], 1, 512, "half", 2);
>>>
>>> 	freqz ([zeros(1, 768-20), ones(1, 20)], 1, 512, "half", 2);
>>
>> I've updated http://hauberg.org/freqz to only show these results
>>
>> Søren
>
> Thanks Søren!
>
> The second phase curve is different from Octave's. Specifically, the
> phase slope of the prepad (2nd) example has the opposite sign.
>
> Using octave, I notice the sign of the phase slope is dependent upon
> the degree by which the input sequence exceeds the length  of the
> frequency vector. For the present example, the sign of the phase slope
> changes sign when the length input vector is greater than 522. See the
> examples below ...
>
> 	freqz ([zeros(1, 522-20), ones(1, 20)], 1, 512, 'half', 2);
>
> 	freqz ([zeros(1, 523-20), ones(1, 20)], 1, 512, 'half', 2);
>
> So this problem manifests when the nominal delay exceeds 512.
>
> My understanding is that the two responses below should be the same.
>
> 	p = [zeros(1, 768-20), ones(1, 20)];
> 	hz = freqz (p, 1, 512, 'half', 2);
> 	hf = fft (p, 1024)(1:512);
>
> ... and Octave does produce identical results.
>
> Assuming that there is no problem with either Matlab or my
> understanding, I'm inclined to question the manner by which the two
> implementations are unwrapping the phase.
>
> If the phase is unwrapped such that only positive delays are possible,
> I octave will produce the same plot as does Matlab. For example, the
> result below, looks convincing.
>
> 	f = (0:511)/512;
> 	da = -pi*f*512;
> 	plot (f, (unwrap(angle(hz)-da)+da)*180/pi, ...
>                  f, (unwrap(angle(hf)-da)+da)*180/pi)
>
> If my inference is correct, then freqz.m is not to blame. The problem
> is superficial, and is in freqz_plot.m
>
> I'm not familiar with the signal processing functions. If someone has
> an opinion how/where this should be resolved, I'd appreciate the  
> input.
>
> For the time being, I'll assume it is best to modify freqz_plot.m, and
> generate a changeset including each of these changes.
>
> Ben

I had hoped to get to this sooner.

Please review the attached changeset for freqz.m. I made a simple  
addition to Frederick's work that ensures a causal phase delay when  
there are not output arguments (which results in a figure being  
rendered).

I've compared the two examples below to the result Søren obtained  
using Matlab.

	freqz ([ones(1, 20), zeros(1, 768-20)], 1, 512, "half", 2);

	freqz ([zeros(1, 768-20), ones(1, 20)], 1, 512, "half", 2);

The result Søren obtained running Matlab is still here; http://hauberg.org/freqz

Ben

-------------- next part --------------
A non-text attachment was scrubbed...
Name: changeset-freqz.patch
Type: application/octet-stream
Size: 2108 bytes
Desc: not available
Url : https://www-old.cae.wisc.edu/pipermail/bug-octave/attachments/20090202/afe3b9bc/attachment.obj 
-------------- next part --------------