lowpass tap count

valtih1978 <do@not.email.me> wrote:

> As opposed to differentiator, which operates locally (computes 
> difference between two adjacent samples), integrator averages a huge 
> number of samples over its huge time constant. This does not look 
> practical. How do you do it?

I believe easier than differentiators.

One form is the decaying average, where you sum an exponentially
decaying amount of each prior sample.  That can be done with
just multiply and add at each point.

If instead you want a running average, where each output sample
is the arithmetic mean of the N previous input samples, all you
need is a memory to store N samples.  At each input sample, you
subtract the Nth previous sample (retrieved from memory) add the
current input, store the current sample in memory, and output
the (possibly scaled) value.  Small computation, but it does
need the memory.  

The decaying average avoids the memory.

-- glen

On 10/24/2011 3:04 PM, valtih1978 wrote:
>  > There is no way to specify an impulse response with fewer taps than
> that.
>
> I have discovered http://www.dspguide.com/CH14.PDF, which says that we
> can always get highpass from lowpass just by flipping convolution
> coefficient signs. (The amount of coefficients in not changed)
>
> The idea is: "run the signal through a low-pass filter, and then
> subtract the filtered signal from the original!"

Yes. That amounts to a proof that filters whose critical frequencies are 
very nearly equal to half the sampling also require many taps. That's a 
good reason for oversampling (like 48 KHz to capture 20 KHz).

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

On 10/24/2011 3:13 PM, HardySpicer wrote:
> On Oct 25, 1:43 am, valtih1978<d...@not.email.me>  wrote:
>> As opposed to differentiator, which operates locally (computes
>> difference between two adjacent samples), integrator averages a huge
>> number of samples over its huge time constant. This does not look
>> practical. How do you do it?
>>
>> thanks
>
> A summation can be written recursively. There is a simple proof for
> this which I can't be bothered writing but you find the sum with k
> terms and then find the sum for k+1. Then write the latter in terms of
> the former.

Hardy,

Did you read my bit of pseudocode:

integral=0
For n=[0], to n=[enough]
integral="integral"+x[n] ?

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

On Oct 25, 10:21&#4294967295;am, Jerry Avins <j...@ieee.org> wrote:
> On 10/24/2011 3:13 PM, HardySpicer wrote:
>
> > On Oct 25, 1:43 am, valtih1978<d...@not.email.me> &#4294967295;wrote:
> >> As opposed to differentiator, which operates locally (computes
> >> difference between two adjacent samples), integrator averages a huge
> >> number of samples over its huge time constant. This does not look
> >> practical. How do you do it?
>
> >> thanks
>
> > A summation can be written recursively. There is a simple proof for
> > this which I can't be bothered writing but you find the sum with k
> > terms and then find the sum for k+1. Then write the latter in terms of
> > the former.
>
> Hardy,
>
> Did you read my bit of pseudocode:
>
> integral=0
> For n=[0], to n=[enough]
> integral="integral"+x[n] ?
>
> Jerry
> --
> Engineering is the art of making what you want from things you can get.

That's not a proof though. What I wanted (but am too tired) to prove
is where your code comes from!
Nothing wrong with your code btw.


Hardy

On 10/24/2011 9:14 PM, HardySpicer wrote:
> On Oct 25, 10:21 am, Jerry Avins<j...@ieee.org>  wrote:
>> On 10/24/2011 3:13 PM, HardySpicer wrote:
>>
>>> On Oct 25, 1:43 am, valtih1978<d...@not.email.me>    wrote:
>>>> As opposed to differentiator, which operates locally (computes
>>>> difference between two adjacent samples), integrator averages a huge
>>>> number of samples over its huge time constant. This does not look
>>>> practical. How do you do it?
>>
>>>> thanks
>>
>>> A summation can be written recursively. There is a simple proof for
>>> this which I can't be bothered writing but you find the sum with k
>>> terms and then find the sum for k+1. Then write the latter in terms of
>>> the former.
>>
>> Hardy,
>>
>> Did you read my bit of pseudocode:
>>
>> integral=0
>> For n=[0], to n=[enough]
>> integral="integral"+x[n] ?
>>
>> Jerry
>> --
>> Engineering is the art of making what you want from things you can get.
>
> That's not a proof though. What I wanted (but am too tired) to prove
> is where your code comes from!
> Nothing wrong with your code btw.

I intended it as a description of (the process of accumulating) a 
running sum.

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

On Oct 25, 3:12&#4294967295;pm, Jerry Avins <j...@ieee.org> wrote:
> On 10/24/2011 9:14 PM, HardySpicer wrote:
>
>
>
> > On Oct 25, 10:21 am, Jerry Avins<j...@ieee.org> &#4294967295;wrote:
> >> On 10/24/2011 3:13 PM, HardySpicer wrote:
>
> >>> On Oct 25, 1:43 am, valtih1978<d...@not.email.me> &#4294967295; &#4294967295;wrote:
> >>>> As opposed to differentiator, which operates locally (computes
> >>>> difference between two adjacent samples), integrator averages a huge
> >>>> number of samples over its huge time constant. This does not look
> >>>> practical. How do you do it?
>
> >>>> thanks
>
> >>> A summation can be written recursively. There is a simple proof for
> >>> this which I can't be bothered writing but you find the sum with k
> >>> terms and then find the sum for k+1. Then write the latter in terms of
> >>> the former.
>
> >> Hardy,
>
> >> Did you read my bit of pseudocode:
>
> >> integral=0
> >> For n=[0], to n=[enough]
> >> integral="integral"+x[n] ?
>
> >> Jerry
> >> --
> >> Engineering is the art of making what you want from things you can get.
>
> > That's not a proof though. What I wanted (but am too tired) to prove
> > is where your code comes from!
> > Nothing wrong with your code btw.
>
> I intended it as a description of (the process of accumulating) a
> running sum.
>
> Jerry
> --
> Engineering is the art of making what you want from things you can get.

But it is easier to see from a batch summation. Everybody understands
how to work out an average value. Suppose the average with k samples
is W(k)

                   k
W(k)=(1/k) Sum a(i)
                   i=1
then

                            k+1
W(k+1)=(1/(k+1)) Sum a(i)
                           i=1
              k
= 1/(k+1)Sum a(i)      +   a(k+1)(1/(k+1))
              i=1
                    k
But kW(k) = Sum a(i)
                   i=1

Hence

W(k+1) = k/(k+1)  W(k) + a(k+1)(1/(k+1))


 = (1- 1/(k+1))W(k) + a(k+1)(1/(k+1))

Hence

W(k+1) = W(k) + (1/(k+1))( a(k+1) - W(k) )



This is the recursive mean.


Hardy

I see. You turn the arguments other way around. From the fact that 
low-pass filters have long time constant and we can derive high-pass by 
flipping it we conclude that high pass also requires many taps. Yet, 
high freq processes have very small time constants and, thus, low number 
of samples per impulse response. There is a contradiction in this logic.

On 10/25/2011 6:49 AM, valtih1978 wrote:
> I see. You turn the arguments other way around. From the fact that
> low-pass filters have long time constant and we can derive high-pass by
> flipping it we conclude that high pass also requires many taps. Yet,
> high freq processes have very small time constants and, thus, low number
> of samples per impulse response. There is a contradiction in this logic.

Fixing three misconceptions:
1. Filters with high critical frequencies are not necessarily low pass.
2. Flipping is not the only way to design high-pass filters.
3. Not all low-pass filters have very long impulse responses.
    It depends on how low.

There is an often-overlooked symmetry to the band edges, and you have 
stumbled upon it. The time needed to resolve a frequency f is also the 
time needed to resolve fs/2 - f. In my opinion, that's a more important 
reason to oversample than filters.

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

On 10/24/2011 5:43 AM, valtih1978 wrote:
> As opposed to differentiator, which operates locally (computes
> difference between two adjacent samples), integrator averages a huge
> number of samples over its huge time constant. This does not look
> practical. How do you do it?
>
> thanks

It seems that you've not discussed a fundamental parameter of filter design:

The length of a filter is very much dependent on the width of the 
narrowest *transition region*.  It doesn't matter if it's lowpass, 
highpass, etc.

The length of the filter is roughly the reciprocal of the width of the 
narrowest transition region.

So a lowpass (or a highpass) filter with first edge at 0.3fs and next 
edge at 0.4fs will have a transition band of 0.1fs and a length around 
10/fs.
A filter with first edge at .35fs and next edge at .36fs will have a 
transition band of 0.01fs and a length around 100/fs.

Maybe there's a factor of 2 in there but this is pretty close.

And, that's about all there is to say about it except for minute details.

Fred

Fred Marshall <fmarshallxremove_the_x@acm.org> wrote:

(snip)
> It seems that you've not discussed a fundamental parameter of filter design:

> The length of a filter is very much dependent on the width of the 
> narrowest *transition region*.  It doesn't matter if it's lowpass, 
> highpass, etc.

> The length of the filter is roughly the reciprocal of the width of the 
> narrowest transition region.

> So a lowpass (or a highpass) filter with first edge at 0.3fs and next 
> edge at 0.4fs will have a transition band of 0.1fs and a length around 
> 10/fs.
> A filter with first edge at .35fs and next edge at .36fs will have a 
> transition band of 0.01fs and a length around 100/fs.

> Maybe there's a factor of 2 in there but this is pretty close.

> And, that's about all there is to say about it except for minute details.

And note that for filters with very low or very high transition
frequency that the transition will generally be narrow, especially
for the high end.

-- glen