Indicators: Liner regression
Your version appears to be the same mathematics as:
https://www.mql5.com/en/code/429
I ran both for a period of 20 on NZDUSD,D1, and they line up exactly.
Differences:
- Yours color codes the slope.
-
- His has the ability to "shift" bars and points.
-
- Yours has ability to switch APPLIED_PRICE.
Your version appears to be the same mathematics as:
https://www.mql5.com/en/code/429
I ran both for a period of 20 on NZDUSD,D1, and they line up exactly.
Differences:
- Yours color codes the slope.
-
- His has the ability to "shift" bars and points.
-
- Yours has ability to switch APPLIED_PRICE.
That way (the 3*lwma-2*sma) is explained in the link from the post (please check that link too, this link https://www.mql5.com/en/articles/270) and exists for a long, long time and was first introduced at this forum (quite frankly I do not remember exactly who was that introduced that algo for the first time, I think it was "mathemat" but please do not take my word for it)
As of code : the code that I have posted is a single pass code (that is why it is fast) and has nothing in common with Nikolays code, which you can check for yourself too. The purpose of the post was to post the fast (CPU wise fast) way that is flexible enough to be used in any type of code. And, according to all the tests it is fast enough to be used in metatrader 5 and is flexible enough too
all the best
- www.mql5.com
As of code : the code that I have posted is a single pass code (that is why it is fast) and has nothing in common with Nikolays code, which you can check for yourself too. The purpose of the post was to post the fast (CPU wise fast) way that is flexible enough to be used in any type of code. And, according to all the tests it is fast enough to be used in metatrader 5 and is flexible enough too
OK. Fast is good. I didn't really compare the code; just the results; so I mistakenly said the "same mathematics."
I've been using the Nikolays code for a while, and yes, it is the slowest indicator I have. Fast is good.
Keep up the good work!
Nice implementation. Congrats.
- What is the purpose of this ? Obfuscation ? :-D
#define ¤ instance #define _functionInstances 1
- Is there any reason to not use >= in the below code ? ;-)
if(i>period)
Nice implementation. Congrats.
- What is the purpose of this ? Obfuscation ? :-D
- Is there any reason to not use >= in the below code ? ;-)
No obfuscation :
Of "¤" : I simply like it that way better (a convention that I use for myself - to me the code is more readable like that - one glance at the function code and I can see exactly what is used where). I could use that directly as a parameter name, but then it would be "too cryptic" when I type in the name of the function and when the auto fill brings up the parameter names
Of "_functionInstances" : since it will be translated into compile time directive, it serves for planning - if I want to use more than one function instance (ie: different parameters for any reason) then I simply change the define value and then it is compiled to correct number for array allocation to be used with different parameters - an I do not have to think if I have changed it in all the places in the code where it needs to be done. And being a compiler time directive, no run-time cost
As of ">=" - two reasons:
- one condition less (that is executed on each and every function call) unless the compiler translates it to something else (the ">=") but judging from the profiler results it is using that as 2 conditions not 1 in that case
- it does not not hurt the final speed at all and is making sure that all is properly set for further processing (one extra initial sums processing is making sure of that)
No obfuscation :
Of "¤" : I simply like it that way better (a convention that I use for myself - to me the code is more readable like that - one glance at the function code and I can see exactly what is used where). I could use that directly as a parameter name, but then it would be "too cryptic" when I type in the name of the function and when the auto fill brings up the parameter names
Of "_functionInstances" : since it will be translated into compile time directive, it serves for planning - if I want to use more than one function instance (ie: different parameters for any reason) then I simply change the define value and then it is compiled to correct number for array allocation to be used with different parameters - an I do not have to think if I have changed it in all the places in the code where it needs to be done. And being a compiler time directive, no run-time cost
As of ">=" - two reasons:
- one condition less (that is executed on each and every function call) unless the compiler translates it to something else (the ">=") but judging from the profiler results it is using that as 2 conditions not 1 in that case
- it does not not hurt the final speed at all and is making sure that all is properly set for further processing (one extra initial sums processing is making sure of that)
Of course ">" is working. My remark was just to say you are losing "1 loop", of course it doesn't change much the final speed. "Making sure of that" seems more like a superstition ;-)
Alain Verleyen:
You should try an OOP approach.
...
You mean something like this :)
It is slightly (but only slightly) slower - I am using ring buffer approach in the OOP mode and that adds one mod instruction to the whole calculation, that is why. I think that the posted will be OK enough too :)
You mean something like this :)
It is slightly (but only slightly) slower - I am using ring buffer approach in the OOP mode and that adds one mod instruction to the whole calculation, that is why. I think that the posted will be OK enough too :)
Yes it's always a compromise between speed and memory.
And of course the main advantage of OOP is maintenance and reusability, not speed.
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
You agree to website policy and terms of use
Liner regression:
Linear regression
Author: Mladen Rakic