The ability to reduce lag while keeping a good level of stability has been a major challenge for smoothing filters in technical analysis. Stability involve many parameters, one of them being overshoots. Overshoots are a common effect induced by low-lagging filters, they are defined as the ability of a signal output to exceed a target input. This effect can lead to major drawbacks such as whipsaw and reduction of precision. I propose a modification of the least squares moving average "Reduced Overshoots Moving Average" (ROMA) to reduce overshoots induced by the lsma by using a scaled recursive dispersion coefficient with the purpose of reducing overshoots.
Overshoots - Causes and Effects
Control theory and electronic engineering use step response to measure overshoots, the target signal is defined as an heaviside step function which will be used as input signal for our filter.
In white an input signal, in blue a least squares moving average with the input signal as source, the circle show the overshoot induced by the lsma, the filter exceed drastically the target input. But why low lag filters often induce overshoots ? This is because in order to reduce lag those filter will increase certain frequencies of the input signal, this reduce lag but induce overshoots because the amplitude of those frequencies have been increased, so its normal for the filter to exceed the input target. The increase of frequencies is not a bad process but when those frequencies are already of large amplitudes (high volatility periods) the overshoots can be seen.
Comparison With ROMA
Our method will use the line rescaling technique to estimate the lsma for efficiency sake. This method involve calculating the z-score of a line and multiplying it by the correlation of the line and the target input (price). Then we rescale this result by adding this z-score multiplied by the dispersion coefficient to a simple moving average. Lets compare the step response of our filer and the lsma.
ROMA (in red) need more data to be computed but reduce the mean absolute error in comparison with the classic lsma, it is seen that instead of following increasing, ROMA decrease thus ending with an undershoot.
ROMA in (red) and an lsma (in blue) with both length = 14, ROMA decrease overshoots with the cost of less smoothing, both filter match when there are no overshoots situations.
Both filters with length = 200, large periods increase the amplitude of overshoots, ROMA stabilize early at the cost of some smoothness.
The running Mean Absolute Error of both filters with length = 100, ROMA (in red) is on average closer to the price than the lsma (in blue)
Conclusion
I presented a modification of the least squares moving average with the goal to provide both stability and rapidity, the statistics show that ROMA do a better job when it comes to reduce the mean absolute error. Alternatives methods can involve decreasing the period it take for the filter to be on a steady state (reducing filter period during high volatility periods), various filters already exploit this method.
Side Project
I'am not that good when it come to make my post easy to read, this is why i'am currently making an article explaining the basis of digital signal processing. This post will help you to understand signals and things such as lag, frequency transform, cycles, overshoots, ringing, FIR/IIR filters, impulse response, convolution, filter topology and many more. I love to post indicators but also making more educational content as well, so stay tuned :)
Thanks for reading, let me know if you need help with something, i would be happy to assist you.
please be kind to notify me if you find errors about the indicator in order for me to update it as fast as possible.
Hi Alexgrover, Nothing much can mentioned; I can only said I very proud of your brilliant work. Keep it up Bro =D
alexgrover
⋅
@ICEKI, Thank you a lot for the support, let me know if you need a specific indicator in the future :)
aaahopper
⋅
Hi alexgrover,
As always brilliant work :)
Is there an option to replace the "correlation(close,n,length)" with an alternative as "correlation" repaints?
Sorry for that request
alexgrover
⋅
@aaahopper, Thanks for your support, the correlation function does not repaint, it depend on what you use as source for it. Nonetheless you can estimate this correlation by using the product moment correlation or an estimate i made which consist on the following code : (sma(close,length/2) - sma(close,length))/stdev(close,length) , i described this estimate here tradingview.com/script/qb8XbLC1-Light-LSMA/ :)
aaahopper
⋅
@alexgrover, Thank you for this.
I agree the correlation should not repaint but when I remove the "correlation" part of the formula I don't have any issues.
There is another programmer has raised the same issue.
I am not sure if this is a version3 problem.
Anyway, thank you again and for the brilliant work and a brilliant mind :)
alexgrover
⋅
@aaahopper, Oh my, am i worthy of such praise :D ? I will check the correlation function, but in version 2 there is no problem, in my opinion version 2 is superior to 3/4 when someone use recursion since you can just use nz without the need to prior variable declaration, so i have the habit to use version 2 instead of others versions. But thank you a lot for pointing out this possible issue, it could actually be a really interesting as well as terrible thing for pine to have another repainting function.