Phil wrote:>>For what it's worth, a moving average *is* an FIR filter.> Is it still considered FIR when implemented with a delayed > differentiator (delay sets the window size) followed by an > integrator? I would consider this implementation as IIR.It is IIR if implemented in floating point and FIR in fixed point. -- glen
Low Pass Filter Design Help
Started by ●August 13, 2007
Reply by ●August 15, 20072007-08-15
Reply by ●August 15, 20072007-08-15
On Aug 15, 1:40 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote:> Phil wrote: > >>For what it's worth, a moving average *is* an FIR filter. > > Is it still considered FIR when implemented with a delayed > > differentiator (delay sets the window size) followed by an > > integrator? I would consider this implementation as IIR. > > It is IIR if implemented in floating point and FIR in > fixed point. > > -- glenThe only way for the last statement to by true is to violate the basic principles of floating point comparison. But it is an interesting response, philosophically. This is one of the types of responses that triggered that second failed attempt at creating a human based source of usable information on the web: the wiki. Dale B. Dalrymple http://dbdimages.com
Reply by ●August 15, 20072007-08-15
dbd wrote:> On Aug 15, 1:40 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: >> Phil wrote: >>>> For what it's worth, a moving average *is* an FIR filter. >>> Is it still considered FIR when implemented with a delayed >>> differentiator (delay sets the window size) followed by an >>> integrator? I would consider this implementation as IIR. >> It is IIR if implemented in floating point and FIR in >> fixed point. >> >> -- glen > > The only way for the last statement to by true is to violate the basic > principles of floating point comparison. > > But it is an interesting response, philosophically. This is one of the > types of responses that triggered that second failed attempt at > creating a human based source of usable information on the web: the > wiki. > > Dale B. Dalrymple > http://dbdimages.comGlen is right, though in a non-obvious way. A floating-point box-car isn't necessarily completely stable. (It's stable IFF the exponent of the running sum never changes.) The filter's impulse response becomes infinite as soon as the implied "empty" value begins its random walk. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●August 15, 20072007-08-15
On Aug 15, 2:31 pm, Jerry Avins <j...@ieee.org> wrote:> dbd wrote: > > On Aug 15, 1:40 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: > >> Phil wrote: > >>>> For what it's worth, a moving average *is* an FIR filter. > >>> Is it still considered FIR when implemented with a delayed > >>> differentiator (delay sets the window size) followed by an > >>> integrator? I would consider this implementation as IIR. > >> It is IIR if implemented in floating point and FIR in > >> fixed point. > > >> -- glen > > > The only way for the last statement to by true is to violate the basic > > principles of floating point comparison. > > > But it is an interesting response, philosophically. This is one of the > > types of responses that triggered that second failed attempt at > > creating a human based source of usable information on the web: the > > wiki. > > > Dale B. Dalrymple > >http://dbdimages.com > > Glen is right, though in a non-obvious way. A floating-point box-car > isn't necessarily completely stable. (It's stable IFF the exponent of > the running sum never changes.) The filter's impulse response becomes > infinite as soon as the implied "empty" value begins its random walk. > > Jerry > -- > Engineering is the art of making what you want from things you can get. > =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF==AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF= =AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF=AF Of course Glen is right. But you can only notice it, in practice, if you make the kind of floating point comparison we usually try to convince people like the OP not to make. Dale B. Dalrymple http://dbdimages.com
Reply by ●August 15, 20072007-08-15
Jerry Avins wrote:> => dbd wrote: > > On Aug 15, 1:40 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote=:> >> Phil wrote: > >>>> For what it's worth, a moving average *is* an FIR filter. > >>> Is it still considered FIR when implemented with a delayed > >>> differentiator (delay sets the window size) followed by an > >>> integrator? I would consider this implementation as IIR. > >> It is IIR if implemented in floating point and FIR in > >> fixed point. > >> > >> -- glen > > > > The only way for the last statement to by true is to violate the basi=c> > principles of floating point comparison. > > > > But it is an interesting response, philosophically. This is one of th=e> > types of responses that triggered that second failed attempt at > > creating a human based source of usable information on the web: the > > wiki. > > > > Dale B. Dalrymple > > http://dbdimages.com > => Glen is right, though in a non-obvious way. A floating-point box-car > isn't necessarily completely stable. (It's stable IFF the exponent of > the running sum never changes.) The filter's impulse response becomes > infinite as soon as the implied "empty" value begins its random walk.Maybe that's true on some other planet for some other problem. But for the problem the OP presented he is working with relatively small integers and a relatively small boxcar. So there should be (barring error) no danger that using floating point will produce an output result that is not the very same set of integers that a fixed point implementation would produce. -jim> => Jerry > -- > Engineering is the art of making what you want from things you can get.=> =C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF==C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2= =AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF= =C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2= =AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF= =C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF=C2=AF ----== 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 =----
Reply by ●August 15, 20072007-08-15
dbd wrote:> On Aug 15, 2:31 pm, Jerry Avins <j...@ieee.org> wrote: >> dbd wrote: >>> On Aug 15, 1:40 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: >>>> Phil wrote: >>>>>> For what it's worth, a moving average *is* an FIR filter. >>>>> Is it still considered FIR when implemented with a delayed >>>>> differentiator (delay sets the window size) followed by an >>>>> integrator? I would consider this implementation as IIR. >>>> It is IIR if implemented in floating point and FIR in >>>> fixed point. >>>> -- glen >>> The only way for the last statement to by true is to violate the basic >>> principles of floating point comparison. >>> But it is an interesting response, philosophically. This is one of the >>> types of responses that triggered that second failed attempt at >>> creating a human based source of usable information on the web: the >>> wiki. >>> Dale B. Dalrymple >>> http://dbdimages.com >> Glen is right, though in a non-obvious way. A floating-point box-car >> isn't necessarily completely stable. (It's stable IFF the exponent of >> the running sum never changes.) The filter's impulse response becomes >> infinite as soon as the implied "empty" value begins its random walk. >> >> Jerry >> -- >> Engineering is the art of making what you want from things you can get. > > Of course Glen is right. But you can only notice it, in practice, if > you make the kind of floating point comparison we usually try to > convince people like the OP not to make.I don't see how comparison enters the picture. A recursive boxcar keeps a running sum of the last N samples by setting y[i]=y[i-1]+x[i]-x[i-N]. N samples ago, when x[i - N] had been added, the exponent of the sum y might have been different. The proper functioning of the averager depends on subtracting exactly what had been previously added. That requirement isn't met if the exponent changed. 32-bit floats have a wide range, even with an unchanging exponent, so the problem may not appear unless the averaging period is long. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●August 16, 20072007-08-16
Jerry Avins wrote:> dbd wrote: >> On Aug 15, 2:31 pm, Jerry Avins <j...@ieee.org> wrote: >>> dbd wrote: >>>> On Aug 15, 1:40 pm, glen herrmannsfeldt <g...@ugcs.caltech.edu> wrote: >>>>> Phil wrote: >>>>>>> For what it's worth, a moving average *is* an FIR filter. >>>>>> Is it still considered FIR when implemented with a delayed >>>>>> differentiator (delay sets the window size) followed by an >>>>>> integrator? I would consider this implementation as IIR. >>>>> It is IIR if implemented in floating point and FIR in >>>>> fixed point. >>>>> -- glen >>>> The only way for the last statement to by true is to violate the basic >>>> principles of floating point comparison. >>>> But it is an interesting response, philosophically. This is one of the >>>> types of responses that triggered that second failed attempt at >>>> creating a human based source of usable information on the web: the >>>> wiki. >>>> Dale B. Dalrymple >>>> http://dbdimages.com >>> Glen is right, though in a non-obvious way. A floating-point box-car >>> isn't necessarily completely stable. (It's stable IFF the exponent of >>> the running sum never changes.) The filter's impulse response becomes >>> infinite as soon as the implied "empty" value begins its random walk. >>> >>> Jerry >>> -- >>> Engineering is the art of making what you want from things you can get. >> >> Of course Glen is right. But you can only notice it, in practice, if >> you make the kind of floating point comparison we usually try to >> convince people like the OP not to make. > > I don't see how comparison enters the picture. A recursive boxcar keeps > a running sum of the last N samples by setting y[i]=y[i-1]+x[i]-x[i-N]. > N samples ago, when x[i - N] had been added, the exponent of the sum y > might have been different. The proper functioning of the averager > depends on subtracting exactly what had been previously added. That > requirement isn't met if the exponent changed. 32-bit floats have a wide > range, even with an unchanging exponent, so the problem may not appear > unless the averaging period is long.The same thing applies to the majority of these types of sliding windowed algorithms. They rely on subtracting at the end of the window exactly what they added at the start of the window. If its not exact, there is the potential for the "baseline" to wander way off. When using fixed point, people often drop the lower bits in calculations where the numbers can go very large. If this is done in conjunction with a sliding window, things can get just as quirky as using floating point. Steve
Reply by ●August 16, 20072007-08-16
Steve Underwood wrote:> Jerry Avins wrote:>> ... A recursive boxcar >> keeps a running sum of the last N samples by setting >> y[i]=y[i-1]+x[i]-x[i-N]. N samples ago, when x[i - N] had been added, >> the exponent of the sum y might have been different. The proper >> functioning of the averager depends on subtracting exactly what had >> been previously added. That requirement isn't met if the exponent >> changed. 32-bit floats have a wide range, even with an unchanging >> exponent, so the problem may not appear unless the averaging period is >> long. > > The same thing applies to the majority of these types of sliding > windowed algorithms. They rely on subtracting at the end of the window > exactly what they added at the start of the window. If its not exact, > there is the potential for the "baseline" to wander way off. When using > fixed point, people often drop the lower bits in calculations where the > numbers can go very large. If this is done in conjunction with a sliding > window, things can get just as quirky as using floating point.Yes. Some algorithms implicitly assume bit-exact computation. That is ignored only at one's peril. Jerry -- Engineering is the art of making what you want from things you can get. ¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯
Reply by ●August 17, 20072007-08-17
On Tue, 14 Aug 2007 15:23:11 -0700, Phil <philguillemette@alumni.uwaterloo.ca> wrote:>> For what it's worth, a moving average *is* an FIR filter. >> >> Jason > >Is it still considered FIR when implemented with a delayed >differentiator (delay sets the window size) followed by an >integrator? I would consider this implementation as IIR. > >PhilHi, It's an FIR system implemented with a recursive network. [-Rick-]
