FIR filter with a flat transfer function

Carlos Moreno wrote:
> ecco wrote:
> > Hi, All
> >
> > While I'm not too familiar with all of the real-world DSP tricks and
> > techniques, I do have a pretty good understanding of continuous- and
> > discrete-time signals and systems.  My question:
> >
> > I am trying to build an FIR filter for linear prediction, i.e., the 0th
> > order tap in the FIR filter must be 0.  The filter needs to have a
> > near-flat magnitude response (1dB ripple?), and, here's the catch, the
> > filter should have a '0' phase response from 0Hz out to as far as
> > possible.
> >
> > Again, what makes this tricky is that the 0th order tap must be 0.  Can
> > anyone point me in the direction of a tool which will allow me to try
> > to build a filter to these specs?  Even better, does anyone know of
> > such a filter?
>
> You say you have a good undersntanding of signals and systems (including
> discrete-time).  Shouldn't it be obvious for you that what you're asking
> for is physically impossible??
>
> Zero-phase *requires* a symmetric impulse response --- a symmetric
> impulse response is either the "identity" filter (a wire connecting
> input to output), or it is non-causal.

Where did the OP say that the filter had to be causal?  Perhaps
a symmetric non-causal filter would do (e.g. some thing like
[0.5 0 0.5] with the 0 as the 0th order tap?)  Non-causal filters
work just fine if the sampling axis is for something other than
time (e.g. can you predict what should have been in a missing
pixel based on the pixels to the right and left?)


IMHO. YMMV.
-- 
rhn A.T nicholson d.0.t C-o-M

Ok, everyone, please allow me to abort my original question and
describe my real problem/question:

I am trying to implement an FIR predictive filter (linear predictive
filter) for a particular kind of waveform.  When I calculate (using
Matlab) the filter taps which correspond to the least-mean-square (LMS)
optimization, I find that the filter performs (in terms of entropy)
worst than [0 1], a simple d/dt.

This tells me that the LMS optimization is not appropriate (optimum)
for my waveforms.  I guess I'm looking for alternative optimizations on
which to determine taps.

I realize that this is a "classic" problem and that there is no silver
bullet, but can anybody point me in the direction of alternative
optimizations which I might try (other than LMS)?  I also realize that
I could also try opening the door to non-linear predictive filters.  I
am exploring this option.  As it turns out, samples in my waveform only
depend on the previous 5-10 samples; a search for a good non-linear
filter may be tractable.

Thanks.

ec

----------------------------
Jerry:
What you said is not correct.  Adding taps can serve to flatten out
portions of the phase response.  If you do not believe this, I will
send you taps for such a filter tomorrow.  Please let me know.  Thanks.
----------------------------


Ron N. wrote:
> Carlos Moreno wrote:
> > ecco wrote:
> > > Hi, All
> > >
> > > While I'm not too familiar with all of the real-world DSP tricks and
> > > techniques, I do have a pretty good understanding of continuous- and
> > > discrete-time signals and systems.  My question:
> > >
> > > I am trying to build an FIR filter for linear prediction, i.e., the 0th
> > > order tap in the FIR filter must be 0.  The filter needs to have a
> > > near-flat magnitude response (1dB ripple?), and, here's the catch, the
> > > filter should have a '0' phase response from 0Hz out to as far as
> > > possible.
> > >
> > > Again, what makes this tricky is that the 0th order tap must be 0.  Can
> > > anyone point me in the direction of a tool which will allow me to try
> > > to build a filter to these specs?  Even better, does anyone know of
> > > such a filter?
> >
> > You say you have a good undersntanding of signals and systems (including
> > discrete-time).  Shouldn't it be obvious for you that what you're asking
> > for is physically impossible??
> >
> > Zero-phase *requires* a symmetric impulse response --- a symmetric
> > impulse response is either the "identity" filter (a wire connecting
> > input to output), or it is non-causal.
>
> Where did the OP say that the filter had to be causal?  Perhaps
> a symmetric non-causal filter would do (e.g. some thing like
> [0.5 0 0.5] with the 0 as the 0th order tap?)  Non-causal filters
> work just fine if the sampling axis is for something other than
> time (e.g. can you predict what should have been in a missing
> pixel based on the pixels to the right and left?)
> 
> 
> IMHO. YMMV.
> -- 
> rhn A.T nicholson d.0.t C-o-M

Ron N. wrote:

>>Zero-phase *requires* a symmetric impulse response --- a symmetric
>>impulse response is either the "identity" filter (a wire connecting
>>input to output), or it is non-causal.
> 
> Where did the OP say that the filter had to be causal? 

Well, he did mention *prediction*  (which he now confirms in his
reply to your message).

I assumed that a non-causal filter, which would only be valid for
"off-line" processing of already-occured signals would not cut it.

Carlos
--

Jerry Avins wrote:

>> [...]
>> A linear predictor is usually computed from the data [...]
>>
> Moreover, with the first tap set to zero, the filter can't incorporate 
> the newest data into its output.

?????

Care to elaborate on what exactly do you mean by that??

A *prediction* filter by definition can not include the *current*
sample (which is the one being predicted).

Sure, the filter that computes the prediction error (perhaps to
be transmitted) does use the current sample --- to subtract it
from the output of the predictor filter (which only takes into
account past samples).

Am I misunderstanding, or missing something?

Carlos
--

ecco wrote to me privately:ecco wrote to me privately:

 > Hi, Jerry
 > What I'm building is a predictive filter.  The idea is to form an
 > estimate of the current sample based on previous samples.  The
 > difference between the estimate and the real signal is what is stored,
 > ergo, the 0th order tap of the filter must be 0.  Thanks for spending
 > time thinking about this!

And I answered him so:

I don't understand the reasoning that leads up to that condition.

Let's keep this in the newsgroup, please.

Jerry
-- 
A quitter never wins. A winner never quits. A fool never does either.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

ecco wrote:

   ...

> ----------------------------
> Jerry:
> What you said is not correct.  Adding taps can serve to flatten out
> portions of the phase response.  If you do not believe this, I will
> send you taps for such a filter tomorrow.  Please let me know.  Thanks.

I wrote, IIRC, that adding taps could only increase delay. By that I 
meant overall delay. In your case of zero (or linear) phase, phase delay 
and group delay are equal. Suitable approximations to linear phase may 
allow you to circumvent that.

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

Carlos Moreno wrote:
> Jerry Avins wrote:
> 
>>> [...]
>>> A linear predictor is usually computed from the data [...]
>>>
>> Moreover, with the first tap set to zero, the filter can't incorporate 
>> the newest data into its output.
> 
> ?????
> 
> Care to elaborate on what exactly do you mean by that??
> 
> A *prediction* filter by definition can not include the *current*
> sample (which is the one being predicted).
> 
> Sure, the filter that computes the prediction error (perhaps to
> be transmitted) does use the current sample --- to subtract it
> from the output of the predictor filter (which only takes into
> account past samples).

A filter can't effectively use the current sample if its coefficient is 
zero.

> Am I misunderstanding, or missing something?

Not necessarily; maybe I am. Why would want to to "predict" the value of 
a sample already taken?

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

Jerry Avins wrote:

>>>> [...]
>>> Moreover, with the first tap set to zero, the filter can't 
>>> incorporate the newest data into its output.
>>
>> ?????
>>
>> Care to elaborate on what exactly do you mean by that??
>>
>> A *prediction* filter by definition can not include the *current*
>> sample (which is the one being predicted).
>>
>> Sure, the filter that computes the prediction error (perhaps to
>> be transmitted) does use the current sample --- to subtract it
>> from the output of the predictor filter (which only takes into
>> account past samples).
> 
> A filter can't effectively use the current sample if its coefficient is 
> zero.

In the example of the LPC *encoding filter* (not *prediction* filter),
the coefficient for the current sample is not zero, it's 1.

If P(z) is the *prediction* filter (which has the coefficient for
the current sample = 0), then the *encoding* filter has transfer
function 1 - P(z)  (the encoding filter simply produces the
prediction error).

I brought this up as a way of trying to find some applicability to
your comment, but pointing out that you may have been confusing
a *prediction* filter with the *encoding* filter in an LPC system
(apparently, that's not the example that you had in mind?)

>> Am I misunderstanding, or missing something?
> 
> Not necessarily; maybe I am. Why would want to to "predict" the value of 
> a sample already taken?

What's going on here???  Some major confusion must be happening,
because the above should be precisely my argument to your comment.

You said (quoted above): "with the first tap set to zero, the
filter can't incorporate the newest data into its output"

But then, if the filter is a *predictor*, then you don't
incorporate the newest data --- if you have the data, then
no need to predict it  (as I said, what you ask in this last
message is precisely my argument to your initial comment,
which I understood as you were implying that it doesn't make
sense to have the first tap of the filter = 0 because you
need to incorporate the newest sample into the output and
with the first tap being 0 you can't ...  Did I misread
something?)

Carlos
--

Carlos Moreno wrote:
> Jerry Avins wrote:
> 
>>>>> [...]
>>>> Moreover, with the first tap set to zero, the filter can't 
>>>> incorporate the newest data into its output.
>>>
>>> ?????
>>>
>>> Care to elaborate on what exactly do you mean by that??
>>>
>>> A *prediction* filter by definition can not include the *current*
>>> sample (which is the one being predicted).
>>>
>>> Sure, the filter that computes the prediction error (perhaps to
>>> be transmitted) does use the current sample --- to subtract it
>>> from the output of the predictor filter (which only takes into
>>> account past samples).
>>
>> A filter can't effectively use the current sample if its coefficient 
>> is zero.
> 
> In the example of the LPC *encoding filter* (not *prediction* filter),
> the coefficient for the current sample is not zero, it's 1.
> 
> If P(z) is the *prediction* filter (which has the coefficient for
> the current sample = 0), then the *encoding* filter has transfer
> function 1 - P(z)  (the encoding filter simply produces the
> prediction error).
> 
> I brought this up as a way of trying to find some applicability to
> your comment, but pointing out that you may have been confusing
> a *prediction* filter with the *encoding* filter in an LPC system
> (apparently, that's not the example that you had in mind?)
> 
>>> Am I misunderstanding, or missing something?
>>
>> Not necessarily; maybe I am. Why would want to to "predict" the value 
>> of a sample already taken?
> 
> What's going on here???  Some major confusion must be happening,
> because the above should be precisely my argument to your comment.
> 
> You said (quoted above): "with the first tap set to zero, the
> filter can't incorporate the newest data into its output"
> 
> But then, if the filter is a *predictor*, then you don't
> incorporate the newest data --- if you have the data, then
> no need to predict it  (as I said, what you ask in this last
> message is precisely my argument to your initial comment,
> which I understood as you were implying that it doesn't make
> sense to have the first tap of the filter = 0 because you
> need to incorporate the newest sample into the output and
> with the first tap being 0 you can't ...  Did I misread
> something?)

I don't know. Maybe I misread something. What is the aim if prediction? 
Surely it can't be the past (except in the special case of validating a 
model and then we pretend it's the future) and it makes no sense for it 
to be the present, so it must be the future. (That's usually what 
predictions are for, no?) What's wrong with accounting for the present 
in an attempt to predict the future? Is there any advantage to 
discounting it?

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

"Jerry Avins" <jya@ieee.org> wrote in message 
news:2IOdnYwOptwCYhTYnZ2dnUVZ_h63nZ2d@rcn.net...
> ecco wrote to me privately:ecco wrote to me privately:
>
> > Hi, Jerry
> > What I'm building is a predictive filter.  The idea is to form an
> > estimate of the current sample based on previous samples.  The
> > difference between the estimate and the real signal is what is stored,
> > ergo, the 0th order tap of the filter must be 0.  Thanks for spending
> > time thinking about this!
>
> And I answered him so:
>
> I don't understand the reasoning that leads up to that condition.
>
> Let's keep this in the newsgroup, please.
>
> Jerry
> -- 

I think the time base in this discussion is not well described.  Here is how 
I understand a predictor:

1) You *design* a predictor by delaying the input and then making the best 
estimator (filter) that generates the future sample(s) that are already 
known.  I suppose this equates to having the first or more filter taps equal 
to zero to form that delay.  The optimization is done by comparing with the 
current input and minimizing the error (difference).

2) You *apply* the predictor (filter) to the current samples so that the 
future samples are predicted.  That is, you remove the delay and apply the 
same filter to the current input stream.

In the first case (design) the filter may appear to be noncausal if you 
ignore the zero-valued taps at the beginning of the filter and you may 
define time=0 as a time in the future.

In the second case (application), the filter can't be noncausal.  Well, 
unless you store the data and "predict" later.... so then it's not real time 
and it's (like totally) not necessary to predict.

Fred