Tim Wescott wrote:> 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.With 32-bit floating point, there are 25 bits in the mantissa counting the implied one. Many filters will never accumulate a large enough sum to change the exponent, and the operation will be perfect. That's good and bad. If considering the possibilities, an exponent change is known to never happen, that's good. If the fact that it works most of the time and accumulates error only slowly and sporadically, that can have the bad effect of allowing defective code to survive testing. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Online · Live + on demand
February 9-11, 2027
Price goes up Nov 1: register now to lock in today's rate
Register Now →
Question on pole-zero cancellation
Started by ●June 7, 2006
Reply by ●June 8, 20062006-06-08
Reply by ●June 8, 20062006-06-08
jim wrote:> > 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.Never doing it is the same approach. Data-dependent bugs are best avoided. If you can be assured that the exponent of every addend will always be the same as the accumulated sum, floating point will work. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●June 8, 20062006-06-08
Andor wrote:> 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 transient arises when connecting the filter's input to a DC source. As for the source, I submit that it doesn't matter whether the battery in question was formed in the Big Bang, or if it was manufactured today. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●June 8, 20062006-06-08
Jerry Avins wrote:> Andor wrote: > > > 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 transient arises when connecting the filter's input to a DC source. > As for the source, I submit that it doesn't matter whether the battery > in question was formed in the Big Bang, or if it was manufactured today.<sigh> I knew beforehand that someone was going to say something along those lines. Why is it that we can never keep theory and practice apart in this group?
Reply by ●June 8, 20062006-06-08
Reply by ●June 8, 20062006-06-08
Oli Filth wrote:> 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------->The diagram is wrong. It should be +------+ ---+--->| z^-L |------+ | +------+ | - | - v | + +------+ +------------->| SUM |-----> +------+ Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●June 8, 20062006-06-08
Jerry Avins wrote: ...> Never doing it is the same approach. Data-dependent bugs are bestNever doing it is the sane approach. Data-dependent bugs are best ^ ... Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●June 8, 20062006-06-08
Andor wrote:> Jerry Avins wrote: > > >>Andor wrote: >> >> >>>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 transient arises when connecting the filter's input to a DC source. >>As for the source, I submit that it doesn't matter whether the battery >>in question was formed in the Big Bang, or if it was manufactured today. > > > <sigh> > > I knew beforehand that someone was going to say something along those > lines. Why is it that we can never keep theory and practice apart in > this group?Because the filters are used in practice, and we're discussing the theory behind why they really work. Jerry -- Engineering is the art of making what you want from things you can get. �����������������������������������������������������������������������
Reply by ●June 8, 20062006-06-08
Jerry Avins said the following on 08/06/2006 22:45:> Oli Filth wrote: >> 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-------> > > The diagram is wrong. It should be > > +------+ > ---+--->| z^-L |------+ > | +------+ | - > | - v > | + +------+ > +------------->| SUM |-----> > +------+ >This has a (mathematical and practical) zero at DC, and its difference equation is: y[n] = x[n] - x[n-L] not: y[n] = x[n] - x[n-L] + y[n-1] and therefore isn't equivalent to: L-1 y[n] = sum { x[n-i] } i=0 -- Oli
Reply by ●June 8, 20062006-06-08
Jerry Avins wrote:> > With 32-bit floating point, there are 25 bits in the mantissa counting > the implied one. Many filters will never accumulate a large enough sum > to change the exponent, and the operation will be perfect.> > That's good and bad. If considering the possibilities, an exponent > change is known to never happen, that's good. If the fact that it works > most of the time and accumulates error only slowly and sporadically, > that can have the bad effect of allowing defective code to survive testing.So what does that mean in the context of the present discussion? Do you or do you not get the same results if you implement a box-car filter as an standard FIR implementation or as a recursive implementation similar to an IIR? That is if the starting condition are such that both of the 2 methods start generating the same identical sequences what is the mechanism that would cause the sequences to diverge over time? Whether the operation is perfectly precise or not was not the question. Loss of precision can occur in either implementation. Over time what makes you think the result won't be precisely the same even if not perfectly correct? -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 =----
