With only 6000 points, it would seem to me that the best choice would be to 
perform an FFT, perform the frequency shaping in the frequency domain , set 
the DC term to zero, and perform an inverse FFT if the time domain data is 
what you need.  This would probably be faster than filtering and far more 
accurate.  If you're decimating the data, the inverse FFT would be a smaller 
size to get the appropriate number of output points.  QED.

In article <1172670402.497216.135920@a75g2000cwd.googlegroups.com>, "David 
Bonnell" <dbonnell@gmail.com> wrote:
>> > in case your impulse response is symmetric (which is required for linear
> phase FIR filters), you can spare half of the multiplications
>This has nothing to do with the delay, however.
>
>No arguments here.
>
>> Unfortunately, you forgot to mention the actual problem.
>
>You asked for it  :)  I will, however, try to be brief.
>
>Not so much of a problem as a question.  I have two 64 tap filters (A,
>B)in cascade.  The output of A (an anti-aliasing filter) feeds into
>the B (LPF intended to determine DC offset).  I cannot reduce actual
>delay through the system (i.e 64 + 64 samples).  However, I am
>wondering if there are methods to compensate for the delay by
>intelligently preloading my filters.
>
>I want to AC-couple the signal by subtracting the output of B (DC
>value) from the output of A.  Because B is delayed by 64 samples, I
>need to buffer the output of A to sync the two signals.  Conceptually
>pretty simple.
>
>In this system, roughly 6000 samples are taken, followed by a 1000
>sample 'break'.  This cycle repeats.  When resuming sampling (i.e.
>after the 1000 sample break), I currently discard 128 samples (or 2%
>of my data).  I also am unable to process the last 64 data points (at
>the end of the sampling interval) because of the sync issue between A
>and B.
>
>Having said all that, I figured I could discard fewer samples by pre-
>loading the filter(s) prior to start of the sampling interval.  For
>example, at the start of a sampling interval I could load the filters
>with the average value obtained during the previous sampling
>interval.  Clearly, there will be some error in the first 64 + 64
>filter outputs, but my question would be 'how much error'?
>
>I believe my colleague was stating that if I take this approach, I
>could 'safely' discard the first 32 samples (instead of 64) and use
>the next 32 samples as valid data, even though there would be some
>error in the result.
>
>That prompted me to look through my textbooks and search online (where
>I found no information), and subsequently led me to post here for some
>guidance.
>
>HTH,
>Dave
>
>
>

David Bonnell wrote:

>>>in case your impulse response is symmetric (which is required for linear phase FIR filters), you can spare half of the multiplications
> 
> This has nothing to do with the delay, however.
> 
> No arguments here.
> 
> 
>>Unfortunately, you forgot to mention the actual problem.
> 
> 
> You asked for it  :)  I will, however, try to be brief.
> 
> Not so much of a problem as a question.  I have two 64 tap filters (A,
> B)in cascade.  The output of A (an anti-aliasing filter) feeds into

I'm with Jerry here -- why an anti-alias filter?  Are you decimating?

> the B (LPF intended to determine DC offset).  I cannot reduce actual
> delay through the system (i.e 64 + 64 samples).  However, I am
> wondering if there are methods to compensate for the delay by
> intelligently preloading my filters.

Maybe, if you know enough about your data before hand.  I would 
investigate that, but I would also look at using different filters for 
the start and finish (more about that later).
> 
> I want to AC-couple the signal by subtracting the output of B (DC
> value) from the output of A.  Because B is delayed by 64 samples, I
> need to buffer the output of A to sync the two signals.  Conceptually
> pretty simple.
> 
> In this system, roughly 6000 samples are taken, followed by a 1000
> sample 'break'.  This cycle repeats.  When resuming sampling (i.e.
> after the 1000 sample break), I currently discard 128 samples (or 2%
> of my data).  I also am unable to process the last 64 data points (at
> the end of the sampling interval) because of the sync issue between A
> and B.
> 
> Having said all that, I figured I could discard fewer samples by pre-
> loading the filter(s) prior to start of the sampling interval.  For
> example, at the start of a sampling interval I could load the filters
> with the average value obtained during the previous sampling
> interval.  Clearly, there will be some error in the first 64 + 64
> filter outputs, but my question would be 'how much error'?

If you have a good stochastic model of your data then you should be able 
to calculate this.  If you have a good stochastic model of your data and 
a good simulator to match you should be able to simulate this (although 
the simulation won't help to direct you to a good solution).
> 
> I believe my colleague was stating that if I take this approach, I
> could 'safely' discard the first 32 samples (instead of 64) and use
> the next 32 samples as valid data, even though there would be some
> error in the result.
> 
> That prompted me to look through my textbooks and search online (where
> I found no information), and subsequently led me to post here for some
> guidance.

Buried in the design of the filters is the implicit assumption that you 
are separating good information from bad.  You are filtering out the 
'bad' information and keeping the 'good'.

If you _really_ want to go to town on this, you would look at the 
stochastic model of your data and use it to construct a Kalman filter. 
This would give you an optimal estimate of the 'A' and 'B' data for each 
point in the sample.  It would also be computationally expensive, but 
you didn't say you were limited in any way, so I assumed it was OK :-).

You may want to consider taking the whole vector of fully-good output 
values from the anti-alias filter (6000 - 64 if I'm correct), taking the 
average, then subtracting that from your original vector to get your 
AC-coupled data.  If you have drift to contend with then you'd want to 
do a least-squares fit of offset and slope, or even higher-order fits 
(note that you only have to calculate the kernel for this once; after 
that you'll be calculating a linear operation).  Here again I'm assuming 
you have lots of processing power -- but if you are indeed decimating, 
you can do this after resampling which will make your job easier.

-- 

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

Andor wrote:

   ...

> Delay of the DC? This reminds me of another discussion we once had:
> phase shifting of DC ... :-)

Here we go again! :-) Not delay in DC, but delay in determining the 
amount of "DC".

I'm still surprised -- I should be used to it by now -- when somebody 
asks me why it's so hard to give a Hilbert transformer good 
low-frequency response. I get a blank stare when I ask how long a 
90-degree delay at DC is.

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

Jerry wrote:
> Andor wrote:
> > Jerry Avins wrote:
> >> David Bonnell wrote:
>
> >>> Not so much of a problem as a question.  I have two 64 tap filters (A,
> >>> B)in cascade.  The output of A (an anti-aliasing filter) feeds into
> >>> the B (LPF intended to determine DC offset).  I cannot reduce actual
> >>> delay through the system (i.e 64 + 64 samples).  However, I am
> >>> wondering if there are methods to compensate for the delay by
> >>> intelligently preloading my filters.
> >> You are already off on the wrong foot. An anti-alias filter generally is
> >> a low-pass filter, and it must come _before_ sampling tales place. It
> >> will therefore necessarily be an analog filter.
>
> > Not quite necessarily. Anti-alias filters are also used in decimation
> > - most audio AD converters use discrete linear-phase anti-alias
> > filters in the final filtering stage.
>
> Andor, please! he's sampling, not decimating. If you include all the
> caveats, ifs and buts every time, you'll never finish a sentence.

I was just commenting on your logically incorrect use of the term
"necessary" (saying that makes me feel like Mr. Spock :-).

>
> >>> I want to AC-couple the signal by subtracting the output of B (DC
> >>> value) from the output of A.  Because B is delayed by 64 samples, I
> >>> need to buffer the output of A to sync the two signals.  Conceptually
> >>> pretty simple.
> >> A high-pass filter is even simpler. Subtracting the output of a low-pass
> >> filter from the original signal is a roundabout way to low-pass filter.
> >                                                         ^^^^
> > high, right?
>
> Duh. Right!
>
>
>
>
>
> > Subtracting the output of a linear-phase low-pass from the identity is
> > one of several possible ways to design linear-phase high-pass filters.
> > Remember spectral inversion and spectral reversal?
>
> > In this case, it could completely do away with the latency of the
> > filter B (isn't this, ahem, Avins DC blocker?):
>
> >        +-------+
> > in ----| A     |----|----------------- + -----> out
> >        +-------+    |                - |
> >                     |                  |
> >                     |    +------+      |
> >                     |----| B    |------|
> >                          +------+
>
> > If the filter B is a DC estimator (low-pass filter), it doesn't matter
> > at what time it is subtracted from the output of the system A
> > (because, by definition, the DC content doesn't change over time). And
> > there is no input/output latency due to filter B (however, the DC
> > removal will only work as designed once the filter B is stationary).
> > The whole thing can be equivalently drawn as:
>
> >        +-------+         +-------+
> > in ----| A     |---------| C     |-----> out
> >        +-------+         +-------+
>
> > where the coefficients of C are given by [1-b0 -b1 -b2 ... ], where
> > b_i are the coefficients of the filter B. Voila: minimum latency DC
> > blocker.
>
> No filter would be needed if the "DC" were truly stationary. The
> software would merely need to use a additive constant.  It isn't so
> stationary as to make that feasible, so it needs to be measured and
> updated. That's where the delay comes in.

Delay of the DC? This reminds me of another discussion we once had:
phase shifting of DC ... :-)

Regards,
Andor

David Bonnell wrote:
> Wow, thanks guys...a light bulb just went off in my head, and things
> are pretty much crystal clear now.
> 
> Jerry, the (digital) anti-aliasing filter I spoke of was intended for
> decimation.  There is also a 9th order analog LPF prior to A/D
> conversion.
> 
> I have considered using a HPF for the AC coupling, but when I tried it
> the results weren't as clean...I had significant ripple on the output
> (probably due to poor filter design).  I'm currently in debug mode, so
> having the DC value on hand is kind of useful.  I will, however,
> revisit the use of a HPF once I clean up the implementation.

You need an analog filter ahead of the sampler. Otherwise it's garbage 
in, garbage out. Not all of the burden of an anti-alias filter needs to 
be analog, but with intermittent sampling, all analog is probably best. 
I'll provide details in another post if you ask.

> After all this discussion, I'm pretty sure discarding samples is the
> way to go in my case.
> 
> The other 'issue' with delay is my own stupid fault.  I got in the
> (wrong) mindset regarding how filter output corresponds to filter
> input.  I think that's cleared up now.

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

Andor wrote:
> Jerry Avins wrote:
>> David Bonnell wrote:
> 
>>> Not so much of a problem as a question.  I have two 64 tap filters (A,
>>> B)in cascade.  The output of A (an anti-aliasing filter) feeds into
>>> the B (LPF intended to determine DC offset).  I cannot reduce actual
>>> delay through the system (i.e 64 + 64 samples).  However, I am
>>> wondering if there are methods to compensate for the delay by
>>> intelligently preloading my filters.
>> You are already off on the wrong foot. An anti-alias filter generally is
>> a low-pass filter, and it must come _before_ sampling tales place. It
>> will therefore necessarily be an analog filter.
> 
> Not quite necessarily. Anti-alias filters are also used in decimation
> - most audio AD converters use discrete linear-phase anti-alias
> filters in the final filtering stage.

Andor, please! he's sampling, not decimating. If you include all the 
caveats, ifs and buts every time, you'll never finish a sentence.

>>> I want to AC-couple the signal by subtracting the output of B (DC
>>> value) from the output of A.  Because B is delayed by 64 samples, I
>>> need to buffer the output of A to sync the two signals.  Conceptually
>>> pretty simple.
>> A high-pass filter is even simpler. Subtracting the output of a low-pass
>> filter from the original signal is a roundabout way to low-pass filter.
>                                                         ^^^^
> high, right?

Duh. Right!

> Subtracting the output of a linear-phase low-pass from the identity is
> one of several possible ways to design linear-phase high-pass filters.
> Remember spectral inversion and spectral reversal?
> 
> In this case, it could completely do away with the latency of the
> filter B (isn't this, ahem, Avins DC blocker?):
> 
> 
>        +-------+
> in ----| A     |----|----------------- + -----> out
>        +-------+    |                - |
>                     |                  |
>                     |    +------+      |
>                     |----| B    |------|
>                          +------+
> 
> If the filter B is a DC estimator (low-pass filter), it doesn't matter
> at what time it is subtracted from the output of the system A
> (because, by definition, the DC content doesn't change over time). And
> there is no input/output latency due to filter B (however, the DC
> removal will only work as designed once the filter B is stationary).
> The whole thing can be equivalently drawn as:
> 
> 
>        +-------+         +-------+
> in ----| A     |---------| C     |-----> out
>        +-------+         +-------+
> 
> 
> where the coefficients of C are given by [1-b0 -b1 -b2 ... ], where
> b_i are the coefficients of the filter B. Voila: minimum latency DC
> blocker.

No filter would be needed if the "DC" were truly stationary. The 
software would merely need to use a additive constant. It isn't so 
stationary as to make that feasible, so it needs to be measured and 
updated. That's where the delay comes in.

>>> In this system, roughly 6000 samples are taken, followed by a 1000
>>> sample 'break'.  This cycle repeats.  When resuming sampling (i.e.
>>> after the 1000 sample break), I currently discard 128 samples (or 2%
>>> of my data).  I also am unable to process the last 64 data points (at
>>> the end of the sampling interval) because of the sync issue between A
>>> and B.
>>> Having said all that, I figured I could discard fewer samples by pre-
>>> loading the filter(s) prior to start of the sampling interval.  For
>>> example, at the start of a sampling interval I could load the filters
>>> with the average value obtained during the previous sampling
>>> interval.  Clearly, there will be some error in the first 64 + 64
>>> filter outputs, but my question would be 'how much error'?
>> The answer lies in your particular data. The more skillful your in
>> matching fiction to reality, the nicer your results will look. Whatever
>> you do, justifying the validity will be hard.
> 
> One could postulate that the DC content doesn't change over the
> frames. So one could instead of subtracting the output of filter B in
> the above diagram, subtract a constant value for 64 cycles, at which
> point the filter B will be stationary. The constant could, for
> example, be the last output of the filter B from the previous frame.
> Afterwards, switch to the output of B, which contains an updated "DC"
> estimate.

That will work if the change is slow enough. I suspect there are more 
details we don't know. It's worth a try if the data seem to warrant it. 
In any event, nothing will help much without proper antialiasing.

>>> I believe my colleague was stating that if I take this approach, I
>>> could 'safely' discard the first 32 samples (instead of 64) and use
>>> the next 32 samples as valid data, even though there would be some
>>> error in the result.
>> In some weather, I can safely jump off my boat without a life jacket.
>> Weather can change.
> 
> The delay of linear-phase filters does not depend on the weather.
> 
> 
>>> That prompted me to look through my textbooks and search online (where
>>> I found no information), and subsequently led me to post here for some
>>> guidance.
>> You asked for it   :)   I will, however, try to be brief.
>>
>> You should low-pass your data before it's sampled. That filter can run
>> continuously, so whatever delay it imposes will not contribute to end
>> effects. The function of an anti-alias filter is removing those
>> frequencies that would alias if they were sampled. It is not possible to
>> separate aliases created by sampling after sampling takes place. Aliases
>> occupy the same frequency range as useful data. That's why they're
>> called aliases.
>>
>> You will likely remove DC more efficiently with an IIR high-pass filter.
>> Google this group's archives for "DC Blocker" and "robert
>> bristow-johnson". Although not linear phase, the delay in the passband
>> will be small and nearly constant.
> 
> Yes, good point.

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

Jerry Avins wrote:
> David Bonnell wrote:

> > Not so much of a problem as a question.  I have two 64 tap filters (A,
> > B)in cascade.  The output of A (an anti-aliasing filter) feeds into
> > the B (LPF intended to determine DC offset).  I cannot reduce actual
> > delay through the system (i.e 64 + 64 samples).  However, I am
> > wondering if there are methods to compensate for the delay by
> > intelligently preloading my filters.
>
> You are already off on the wrong foot. An anti-alias filter generally is
> a low-pass filter, and it must come _before_ sampling tales place. It
> will therefore necessarily be an analog filter.

Not quite necessarily. Anti-alias filters are also used in decimation
- most audio AD converters use discrete linear-phase anti-alias
filters in the final filtering stage.

>
> > I want to AC-couple the signal by subtracting the output of B (DC
> > value) from the output of A.  Because B is delayed by 64 samples, I
> > need to buffer the output of A to sync the two signals.  Conceptually
> > pretty simple.
>
> A high-pass filter is even simpler. Subtracting the output of a low-pass
> filter from the original signal is a roundabout way to low-pass filter.
                                                        ^^^^
high, right?

Subtracting the output of a linear-phase low-pass from the identity is
one of several possible ways to design linear-phase high-pass filters.
Remember spectral inversion and spectral reversal?

In this case, it could completely do away with the latency of the
filter B (isn't this, ahem, Avins DC blocker?):


       +-------+
in ----| A     |----|----------------- + -----> out
       +-------+    |                - |
                    |                  |
                    |    +------+      |
                    |----| B    |------|
                         +------+

If the filter B is a DC estimator (low-pass filter), it doesn't matter
at what time it is subtracted from the output of the system A
(because, by definition, the DC content doesn't change over time). And
there is no input/output latency due to filter B (however, the DC
removal will only work as designed once the filter B is stationary).
The whole thing can be equivalently drawn as:


       +-------+         +-------+
in ----| A     |---------| C     |-----> out
       +-------+         +-------+


where the coefficients of C are given by [1-b0 -b1 -b2 ... ], where
b_i are the coefficients of the filter B. Voila: minimum latency DC
blocker.


>
> > In this system, roughly 6000 samples are taken, followed by a 1000
> > sample 'break'.  This cycle repeats.  When resuming sampling (i.e.
> > after the 1000 sample break), I currently discard 128 samples (or 2%
> > of my data).  I also am unable to process the last 64 data points (at
> > the end of the sampling interval) because of the sync issue between A
> > and B.
>
> > Having said all that, I figured I could discard fewer samples by pre-
> > loading the filter(s) prior to start of the sampling interval.  For
> > example, at the start of a sampling interval I could load the filters
> > with the average value obtained during the previous sampling
> > interval.  Clearly, there will be some error in the first 64 + 64
> > filter outputs, but my question would be 'how much error'?
>
> The answer lies in your particular data. The more skillful your in
> matching fiction to reality, the nicer your results will look. Whatever
> you do, justifying the validity will be hard.

One could postulate that the DC content doesn't change over the
frames. So one could instead of subtracting the output of filter B in
the above diagram, subtract a constant value for 64 cycles, at which
point the filter B will be stationary. The constant could, for
example, be the last output of the filter B from the previous frame.
Afterwards, switch to the output of B, which contains an updated "DC"
estimate.

>
> > I believe my colleague was stating that if I take this approach, I
> > could 'safely' discard the first 32 samples (instead of 64) and use
> > the next 32 samples as valid data, even though there would be some
> > error in the result.
>
> In some weather, I can safely jump off my boat without a life jacket.
> Weather can change.

The delay of linear-phase filters does not depend on the weather.


> > That prompted me to look through my textbooks and search online (where
> > I found no information), and subsequently led me to post here for some
> > guidance.
>
> You asked for it   :)   I will, however, try to be brief.
>
> You should low-pass your data before it's sampled. That filter can run
> continuously, so whatever delay it imposes will not contribute to end
> effects. The function of an anti-alias filter is removing those
> frequencies that would alias if they were sampled. It is not possible to
> separate aliases created by sampling after sampling takes place. Aliases
> occupy the same frequency range as useful data. That's why they're
> called aliases.
>
> You will likely remove DC more efficiently with an IIR high-pass filter.
> Google this group's archives for "DC Blocker" and "robert
> bristow-johnson". Although not linear phase, the delay in the passband
> will be small and nearly constant.

Yes, good point.

>
> Jerry

Regards,
Andor

Wow, thanks guys...a light bulb just went off in my head, and things
are pretty much crystal clear now.

Jerry, the (digital) anti-aliasing filter I spoke of was intended for
decimation.  There is also a 9th order analog LPF prior to A/D
conversion.

I have considered using a HPF for the AC coupling, but when I tried it
the results weren't as clean...I had significant ripple on the output
(probably due to poor filter design).  I'm currently in debug mode, so
having the DC value on hand is kind of useful.  I will, however,
revisit the use of a HPF once I clean up the implementation.

After all this discussion, I'm pretty sure discarding samples is the
way to go in my case.

The other 'issue' with delay is my own stupid fault.  I got in the
(wrong) mindset regarding how filter output corresponds to filter
input.  I think that's cleared up now.

Thanks again,
Dave

David Bonnell wrote:
>>> The discontinuity

   ...

>> Linear phase FIRs have a constant, frequency independent delay of
>> (N-1)/2 samples. So the part in y that "corresponds" to the unfiltered
>> signal x is
>>
>> y( (N-1)/2 : (N-1)/2 + K -1 )
>>
> 
> I believe this is what I'm failing to grasp.  I am using linear FIRs,
> but I am not sure why the delay is (N-1)/2 instead of N-1.  Given a
> 101-tap filter, I'm not sure why/how the delay would be only 50
> samples instead of 100.

A sample affects the output as soon as it is taken. The effect of equal 
samples increases with their number. Analyze the step response of a 
simple filter and you will see that the center of the output step occurs 
when the first sample reaches the middle tap.


Consider a filter of length 3 and take as output the sum of the taps*. 
After a long string of zeros, put in ones: 0 0 ... 0 1 1 1 1 .... What 
is the output?


In  ... 0 1 1 1 1 1 1
Out ... 0 1 2 3 3 3 3

The middle of the output rise occurs one sample after the first 1 hits 
the filter. (3 - 1)/2 = 1. Try it with other numbers. Even lengths will 
have non-integer delays.

Jerry
____________________________________
* This is called a boxcar averager.
-- 
Engineering is the art of making what you want from things you can get.
¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯¯

"David Bonnell" <dbonnell@gmail.com> wrote in message 
news:1172670956.752847.225530@s48g2000cws.googlegroups.com...
>> > The discontinuity in sampling worries me.
>
>> Why? What's your purpose for filtering?
>
> I have outlined this in another response.
>
>> If you convolve a signal x of length K with a signal h of length N,
>> you get a new signal y of length K + N -1. Why does that worry you?
>
> Worry is perhaps a bit strong.  I want to avoid discarding samples
> when sampling starts.  If sampling was continuous this wouldn't be a
> problem, but I sample a block of data, pause, and repeat.  So I have
> to discard samples at the beginning of every block.
>
>> Linear phase FIRs have a constant, frequency independent delay of
>> (N-1)/2 samples. So the part in y that "corresponds" to the unfiltered
>> signal x is
>>
>> y( (N-1)/2 : (N-1)/2 + K -1 )
>>
>
> I believe this is what I'm failing to grasp.  I am using linear FIRs,
> but I am not sure why the delay is (N-1)/2 instead of N-1.  Given a
> 101-tap filter, I'm not sure why/how the delay would be only 50
> samples instead of 100.
>
> Cheers,
> Dave

Dave,

"seeding" the filter simply means you fill it with data that proposes to 
represent what *may have* been in it.  It's like guessing what your real 
input data looked like *before* it started.  That seems risky.

It appears the trade is whether you just need to get just something out of 
the filter or whether you need to get something sorta accurate out of the 
filter.  If the purpose of the filter is to generate some kind of noise then 
the first objective may be yours.  If the purpose of the filter is to do 
data analysis with some accuracy then it's a dangerous thought I should 
think.

That said, there can be special cases.
What if the real data has a large constant component?  Then, it may actually 
be helpful to load the filter up with that constant value so that higher 
frequency details might be seen "sooner".  This would be highly data 
dependent and application dependent of course.

Fred