|
PureBytes Links
Trading Reference Links
|
Bob Fulks wrote:
>
> At 5:52 PM -0700 9/28/00, Monte C. Smith wrote:
>
> >Mark Jurik wrote:
> >
> >>The SMA has more "inertia" than the EMA. Consequently, it takes
> >>longer to respond to reversals. As the cycles speed up, SMA will lag
> >>further behind EMA. However, on straight trends (no cycles), the lags
> >>are the same.
> >
> >
> >Thanks Mark. The formulae for determining lag in MAs at turning points
> >must look a good deal different from those that determine lags in
> >'steady state' series, and the formula for making this determination in
> >a SMA would then look quite a bit different from that of an EMA. If
> >there is anything in print that explains it well to a non-mathematician,
> >perhaps you or someone else on the List could make a recomendation?
>
> Unfortunately, this is not a simple subject. Electrical engineers
> would refer to the lag at turning points as the "transient response"
> of the filter. Moving averages are really "digital filters" which are
> digital versions of analog filters such as those used in the "bass
> and treble controls" on your old stereo system. In the olden days,
> engineers used a few electronic components to design such filters.
> Now days it is much cheaper to use a million-transistor computer to
> calculate the values.
Yes I recall computing RC time constants, analog filter characteristics,
transient response times, etc a year before the ibm pc came out. I'd be
hard pressed at this point though to look at a schematic and tell you
what the column strobe rate would have to be based on capacitor leakage
in semiconductor memory.
>
> There are several characteristics you have to trade off - the lag,
> the overshoot, and the noise.
>
> The lag is usually measured by how many bars the output is lagging on
> a price that is moving on a sloping straight line as we have
> discussed.
>
> The overshoot is what happens when there is a sudden change in
> direction. It refers to the tendency to move on beyond the price and
> then catch up later. You might say this is the "lag at turning
> points".
Right, precisely.
> The simple moving average, the exponential moving average,
> and the weighted moving average have no overshoot. More sophisticated
> moving averages such as the T3 average and the Jurik moving average
> can have overshoot as this makes them respond faster. On the moving
> averages I design for myself, I usually include a parameter for this.
This parameter would be used to 'artificially' force the MA plot up or
down when its (the parameter's) inputs cross a threshold that are
indiciative of overshoot?
> As I recall the Jurik moving average has a "damping" parameter for
> this purpose also. It give you more control over the tradeoff between
> lag and overshoot.
>
> A simple moving average has no overshoot at all so tends to look
> pretty sluggish.
The SMA will possibly 'appear' to overshoot if a large number is dropped
off the back end, but this is not the 'true overshoot' we're talking
about, which is a function of lag? Is it fair to say that overshoot is a
function of lag?
> It also has several annoying problems. If you apply
> a 20-bar moving average to a signal that is repeating on a 20-bar
> cycle, you will get NO SIGNAL. This is because the value for the new
> bar added to the average is exactly equal to the value dropped off
> the average at the back end.
hahah!!! That's a great and useful observation, and one I can understand
without straining my brain!
> So you better not be trying to trade a
> 20 day cycle using a 20 day simple moving average! Engineers would
> say that this digital filter has a null in its's frequency response
> at the frequency corresponding to the 20-bar period.
>
> And if the price suddenly spikes down on bar 123, the output of the
> 20 bar simple moving average will JUMP UP on bar 143 even if the
> price is perfectly flat. This occurs because the spike value drops
> off of the average suddenly at the back end.
Yes this is what I was talking about above. But this does not qualify as
overshoot.
> If you are using this to
> signal a breakout, you might go long for no reason at all - very
> disconcerting!
Yes, I'd say that would be a very disconcerting situation to be in.
>
> An exponential moving average and the weighted moving average put
> more weighting on the most recent data and less and less on older
> data. This makes them respond faster to changes, eliminates the
> 20-bar null problem, and eliminates the problem with the false
> response as old data drops off of the back of the filter. As a result
> of the faster response, these tend to look noisier.
>
> The so called "end point moving average" is simply the end of a "best
> least squares fit" linear regression line through all of the data
> points. It has no lag at all on a sloping price line but overshoots
> horribly at a turn. It also tends to be pretty noisy.
It seems that some of these problems, such as lag and overshoot, could
be put to good use, even though they are not desirable characteristics
in many instances. The fact that the End-point MA overshoots drastically
at turns might be used with an XMA to generate a raw signal. I've also
"discovered" how the lag in an MA can be used to determine cycle period.
>
> You can get rid of much of the overshoot problem of the linear
> regression line by using a parabola or a cubic best-fit to the points
> in what is often called a polynomial moving average. The calculations
> for these were pretty time consuming until two guys figured out a
> fast way to do the them so now these filters are often called
> "Savizky-Golay" filters in their honor. They provide a pretty good
> compromise between overshoot, noise and lag since you are fitting a
> curve to the available points. The calculation are still too complex
> for EasyLanguage and require a DLL, but they only have to be done on
> the first bar of data so do not take much computer time.
I'll have to search and see if I can locate a source for DLLs of this
type, and how to best use them.
>
> Then there are the adaptive moving averages that adapt their
> characteristics dynamically to try and optimize the tradeoffs. These
> have names such as the Kaufmann AMA, Kalman filters, Tushar Chande's
> VIDYA, and the Jurik AMA. Some are very useful.
Having talked about, or at least mentioned, some of the wide array of
moving averages, I'll have to ask at this point if you or anyone on the
List have any observations concerning the Volume Adjusted Moving
Average, in which time does not play a role. The weighting is done
'dynamically' based upon volume. There is a description at
http://trends-online.com/ind15691.htm if you or anyone else cares to
have a look at it.
>
> As you can see, there are a lot of considerations in deciding which
> to use. Each has good and bad points. Many people have spent their
> complete careers figuring out ways to design such digital filters.
> Since the telephone system required a lot of filters, much of the
> early technology was invented at the Bell Telephone Labs and is
> published in the Bell System Technical Journal. Any engineering
> school library will have hundreds of books on digital filters and
> digital signal processing. (Amazon.com shows 125 books on "digital
> filters" and 472 books on "digital signal processing".)
Hmmm...600 books....well what the hell, I'm not doing anything this
weekend anyway. Actually I don't doubt my time would be better spent
doing some more reading rather than reinventing old wheels, although
things one 'discovers' often hit home deeper than things one comes to
'understand' through reading...but both are important.
>
> Hope this helps...
It sure does Bob, and I thank you.
Regards,
Monte
|