Question on pole-zero cancellation

Randy Yates wrote:
...
> It appears to be just as Tim has stated - this works
> because we're using perfect arithmetic. The transient
> generated by the zero section gets integrated by the
> integrator section back into a perfect DC signal.

There is no transient for DC input - remember, DC has to extend from
-inf to +inf to be DC. The transversal section of the recursive
implementation has a zero at DC, and it cannot be recovered, even with
infinite precision maths.

This is the same effect as the infinitely narrow notch filter, which I
touched on a couple of weeks back. This is another example of two
systems which have the same frequency response, except at one single
point where they differ.

I think the main dilemma lies in the interpretation of the frequency
response. It must be remembered that the frequency response is defined
as the response to periodic signals (interpret the Fourier transform as
convolution with a sinusoid). The impulse response (signal) is computed
with an integral transform from the frequency response. This means that
two frequency responses must only be equal up to a set of measure zero
to have the same impulse response, or in other words, two equal (finite
energy) signals may have differing frequency responses, as long as the
(Lebesgue) measure of the difference set is equal to zero.

Setting the frequency response of a (finite energy) signal to zero at
one point (DC or some notch frequency) changes the frequency reponse on
a set of measure zero only and can therefore not be seen in the time
domain for finite energy signals (interestingly).

The issue of filtering periodic signals (or sums of sinusoids) is
different. The reason is that these signals have point masses in the
frequency domain, and therefore removing a single point in the
frequency domain can very much affect the signal in time domain. For
such signals, infinitely narrow notches do make a difference. Hence the
appearant mismatch of the "theoretical" performance (response to
sinusoids) to the "measured" performance (repsonse to finite energy
signals).

Regards,
Andor

Tim Wescott wrote:

> 
> In this case, what happens in practices is that the unit-circle section
> puts out a transient that will always integrate to the true DC value, so
> the DC value is preserved (at least mathematically).
> 
> Note that this type of filter will work in practice _provided_ that you
> use bit-exact math, you initialize all your variables correctly, and
> nothing gets smacked by a stray gamma ray or other transient effects.
> So this is something that I might expect to see implemented with integer
> arithmetic, but never with floating point.


What does that mean? Are you saying:

A) If I add  numbers to a float variable and later subtract them back
out it will eventually blow up.
B) If I subtract numbers from a float variable and then later add them
back in it will eventually blow up.
c) both
d) neither

And how long will I have to wait to see it blow up? Is there  some sort
of asymmetry in the way floating point numerical implementations handle
adding negative numbers versus subtracting positive numbers?  


-jim

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Jerry Avins said the following on 08/06/2006 05:01:
> Oli Filth wrote:
> 
>> Jerry Avins said the following on 08/06/2006 02:09:
>>
>>> The recursive form I know uses a delay, an adder, and a subtracter:
>>>
>>>         +------+
>>> ---+--->| z^-L |------+
>>>    |    +------+      |  -
>>>    |                  v
>>>    +----------- + --->0------->
>>
>> Perhaps I don't understand your diagram, but isn't that more of a comb
>> filter than a moving sum? ;)
>>
>>
>>> Although that is mathematically the same as
>>>
>>>         +------+
>>> ---+--->| z^-L |------+
>>>    |    +------+      |  -
>>>    |                  v
>>>    +----------------->0-----------------+----->
>>>                       ^                 |
>>>                       |     +------+    |
>>>                       +-----| z^-1 |<---+
>>>                             +------+
>>>
<SNIP>
> 
> The filter works because in practice, we don't build it the way you
> describe.

It seems to me that the structure I described is an explicit Direct Form 
1 implementation of the difference equation, isn't it?  i.e.:

	y[n] = y[n-1] + x[n] - x[n-L]

which, as we know, is mathematically identical to:

	       L-1
	y[n] = sum { x[n-i] }
	       i=0

 From a quick Google, these articles seem to suggest something similar:
http://www.dspguide.com/ch15/5.htm
http://www.techonline.com/community/ed_resource/feature_article/26649
http://www.embedded.com/showArticle.jhtml?articleID=160400592



-- 
Oli

Oli Filth wrote:

> Jerry Avins said the following on 08/06/2006 05:01:

  ...

>> The filter works because in practice, we don't build it the way you
>> describe.
> 
> 
> It seems to me that the structure I described is an explicit Direct Form
> 1 implementation of the difference equation, isn't it?  i.e.:
> 
>     y[n] = y[n-1] + x[n] - x[n-L]
> 
> which, as we know, is mathematically identical to:
> 
>            L-1
>     y[n] = sum { x[n-i] }
>            i=0

It is equivalent, but needlessly complex. Tim put his finger on why the
literal implementation works, and that should settle it.

Transients matter. Consider a lossless capacitor and a lossless inductor
in series. There is no initial current and no initial charge. Now
connect the string to a DC source and an oscillation begins. The funny
thing is, though, that the voltage on the capacitor never changes sign.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

jim wrote:

> 
> Tim Wescott wrote:
> 
> 
>>In this case, what happens in practices is that the unit-circle section
>>puts out a transient that will always integrate to the true DC value, so
>>the DC value is preserved (at least mathematically).
>>
>>Note that this type of filter will work in practice _provided_ that you
>>use bit-exact math, you initialize all your variables correctly, and
>>nothing gets smacked by a stray gamma ray or other transient effects.
>>So this is something that I might expect to see implemented with integer
>>arithmetic, but never with floating point.
> 
> 
> 
> What does that mean? Are you saying:
> 
> A) If I add  numbers to a float variable and later subtract them back
> out it will eventually blow up.
> B) If I subtract numbers from a float variable and then later add them
> back in it will eventually blow up.
> c) both
> d) neither
> 
> And how long will I have to wait to see it blow up? Is there  some sort
> of asymmetry in the way floating point numerical implementations handle
> adding negative numbers versus subtracting positive numbers?  

If the exponent of your float never changes, then the implementation
behaves like fixed point. If the running sum gets large enough to change
the exponent, then the bits involved in the subsequent subtraction are
not identical to the ones in the originally addition. How long before
you might care is a different issue.

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins said the following on 08/06/2006 15:46:
> Oli Filth wrote:
> 
>> Jerry Avins said the following on 08/06/2006 05:01:
> 
>   ...
> 
>>> The filter works because in practice, we don't build it the way you
>>> describe.
>>
>> It seems to me that the structure I described is an explicit Direct Form
>> 1 implementation of the difference equation, isn't it?  i.e.:
>>
>>     y[n] = y[n-1] + x[n] - x[n-L]
>>
>> which, as we know, is mathematically identical to:
>>
>>            L-1
>>     y[n] = sum { x[n-i] }
>>            i=0
> 
> It is equivalent, but needlessly complex.

Needlessly complex?  It replaces (L-1) operations per sample with 2 
operations per sample.


> Tim put his finger on why the
> literal implementation works, and that should settle it.

Indeed, Tim's explanation made a lot of sense; it basically boils down 
to initial conditions.



-- 
Oli

Jerry Avins wrote:

> jim wrote:
> 
> 
>>Tim Wescott wrote:
>>
>>
>>
>>>In this case, what happens in practices is that the unit-circle section
>>>puts out a transient that will always integrate to the true DC value, so
>>>the DC value is preserved (at least mathematically).
>>>
>>>Note that this type of filter will work in practice _provided_ that you
>>>use bit-exact math, you initialize all your variables correctly, and
>>>nothing gets smacked by a stray gamma ray or other transient effects.
>>>So this is something that I might expect to see implemented with integer
>>>arithmetic, but never with floating point.
>>
>>
>>
>>What does that mean? Are you saying:
>>
>>A) If I add  numbers to a float variable and later subtract them back
>>out it will eventually blow up.
>>B) If I subtract numbers from a float variable and then later add them
>>back in it will eventually blow up.
>>c) both
>>d) neither
>>
>>And how long will I have to wait to see it blow up? Is there  some sort
>>of asymmetry in the way floating point numerical implementations handle
>>adding negative numbers versus subtracting positive numbers?  
> 
> 
> If the exponent of your float never changes, then the implementation
> behaves like fixed point. If the running sum gets large enough to change
> the exponent, then the bits involved in the subsequent subtraction are
> not identical to the ones in the originally addition. How long before
> you might care is a different issue.
> 
> Jerry

And hard to pin down.  The most likely effect is that the filter will 
include a small Wiener process, so the deviation from 'correct' will 
take a drunkard's walk away from 0.

-- 

Tim Wescott
Wescott Design Services
http://www.wescottdesign.com

Posting from Google?  See http://cfaj.freeshell.org/google/

"Applied Control Theory for Embedded Systems" came out in April.
See details at http://www.wescottdesign.com/actfes/actfes.html

Jerry Avins wrote:

> 
> If the exponent of your float never changes, then the implementation
> behaves like fixed point. If the running sum gets large enough to change
> the exponent, then the bits involved in the subsequent subtraction are
> not identical to the ones in the originally addition. 

Please explain how that works. The bits involved in the subtraction come
from the same memory location as the bits involved in addition. Why
would they be different. Or are you saying that floating point
arithmetic operations by design have dither added? Or is there an
asymmetry in the way 1 bit overflow occurs when negative versus
positive. There is only addition and subtraction involved here.


>How long before
> you might care is a different issue.

The original assertion I was responding to was It is never done
(presumably for some reason). That also implies some knowledge of how
long it takes to make a noticeable difference.

-jim

----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Oli Filth wrote:

> Jerry Avins said the following on 08/06/2006 15:46:

  ...

>> It is equivalent, but needlessly complex.
> 
> 
> Needlessly complex?  It replaces (L-1) operations per sample with 2
> operations per sample.

Compare your two-loop implementation with the more common one-loop
approach. In each case there is one addition and one subtraction, but
the diagram I showed has one fewer loop. I guess complexity, like
beauty, is in the mind of the beholder.

  ...

Jerry
-- 
Engineering is the art of making what you want from things you can get.
�����������������������������������������������������������������������

Jerry Avins said the following on 08/06/2006 21:46:
> Oli Filth wrote:
> 
>> Jerry Avins said the following on 08/06/2006 15:46:
> 
>   ...
> 
>>> It is equivalent, but needlessly complex.
>>
>> Needlessly complex?  It replaces (L-1) operations per sample with 2
>> operations per sample.
> 
> Compare your two-loop implementation with the more common one-loop
> approach. In each case there is one addition and one subtraction, but
> the diagram I showed has one fewer loop. I guess complexity, like
> beauty, is in the mind of the beholder.

Ah sorry, I thought you were saying that the recursive form was 
"needlessly complex" compared to the non-recursive form.

However, I have to admit, I still don't understand the diagram you drew 
- it still looks like a comb filter to me - where is the addition taking 
place, or rather, what is being added?

Your diagram:

         +------+
---+--->| z^-L |------+
    |    +------+      |  -
    |                  v
    +----------- + --->0------->


-- 
Oli