Comparison of Moving Average (and any other indicators) and error - page 3
You are missing trading opportunities:
- Free trading apps
- Over 8,000 signals for copying
- Economic news for exploring financial markets
Registration
Log in
You agree to website policy and terms of use
If you do not have an account, please register
Thank you, Artyom, but unfortunately it turns out that it can have limits too.
I hope you didn't kill anyone.
I don't. It's nothing to do with my surroundings.)
I don't. It's nothing to do with my surroundings).
Well firstly, the difference of two normalised values will eventually give a non-normalised value. You need to check the normalised difference.
Secondly, if you want to catch crossovers inside a bar, take values of all ticks on the zero and the first bar - you'll catch a lot ... ...just watch out ...
If you test by the opening of a bar, the Expert Advisor should obviously trace the opening of a new bar and, after the fact, check for crossovers.
First of all, decide for yourself - do you trade at bar opening, or at every tick, then write your code. And, accordingly, test it in the same way.
First, I wrote in the first post that I'm trading only at bar opening. There is a subtlety in ticks trading. You can get a signal, but visually there will be no crossover on the chart, because it is drawn only at certain prices (open, close, etc.). It is not drawn by ticks. In this case, explain the layman that yes, there is no crossover on the chart, but because it is specific for drawing of muwings at visualization only by far spaced values (again, opening and closing prices, etc. - approximation, if you've heard such a word) rather than by ticks. Secondly, difference normalisation is nonsense. You will NEVER know in advance to what sign you need to normalise to avoid getting exactly 0 (stupidly not cutting off all the significant digits). I've been engaged in programming for quite some time, and in connection with that I understand computational mathematics quite well (in my main occupation - modeling of physics, where I constantly have to wrestle with the accuracy of calculations). In fact, in general, normalization is a great simplification, if you do not want to delve into the intricacies of calculus mathematics, errors, etc. If you consider yourself such a guru and are not willing to stoop to read the whole topic carefully and then come to conclusions, that's one thing. If that is not the case and you are also trading on the opening of a new bar, then try testing your robot on the bar of 29.07.2015 at 3:20 with the parameters of two SMAs 5 and 34 applied to the close price, on a one minute timeframe. Exactly the situation where the muvings within the same bar cross twice. And this situation is unrealistic when trading not based on ticks. Will your trading robot receive both signals? And most importantly, the answer to the question why on the same bar the difference in muwings (or rather their initial values) at different times is not equal, has not been given yet (only Alexey Lebedev has tried, thank you for that, but it is only a guess...). And it's impossible to answer without knowing the principles of iMA function.
P.S. Just to chat, I think there are special threads on the forum, if you don't want to get into the core of the problem.
Thank you, Artyom, but unfortunately it turns out that it can have limits too.
...
Keep reinventing the hyperboloid. It always works for me and counts correctly. Ah, yes, sorry, I am not a guru in your computational mathematics, I don't invent crap - I make programs for MT4 and MT5. And you keep getting smart, since you don't want to hear what you're told (and it's not about a textbook).
I repeat - if you trade at the opening of a new bar - the question is: why do you need a cross inside the bar (does it matter to you? If so, I will advise you how to do it, if not - forget about it).
I'm not going to use my robot on your time data - I've long given up trading on MAHs. And the fact that MAEs overdraw the zero bar when calculated using all prices except the open price is known even to a schoolboy. What for do you need to explain to someone that it was there and now it is gone if you trade at the opening of a candle? So at the opening and take the data from the MAA.
Where did you find the problem? Here is your cross:
Can you give me a code that will correctly identify this crossover?
Keep reinventing the hyperboloid. It always works for me and counts correctly. Oh, yes, sorry, I'm not a guru in your computational mathematics, I don't invent crap - I make programs for MT4 and MT5. And you keep getting smart, since you don't want to hear what you're told (and it's not about a textbook).
I repeat - if you trade at the opening of a new bar - the question is: why do you need a cross inside the bar (does it matter to you? If so, I'll advise you how to do it, if not - forget about it).
I'm not going to use my robot on your time data - I've long given up trading on MAHs. And the fact that MAEs overdraw the zero bar when calculated using all prices except the open price is known even to a schoolboy. What for do you need to explain to someone that it was there and now it is gone if you trade at the opening of a candle? So at the opening and take the data from the MAA.
Where did you find the problem? Here is your crossover:
Can you suggest a code that will correctly identify this crossover?
I am not inventing the hyperdoloid. If I wanted to invent it, I would not have asked you anything. And I'm not being clever; I am giving counterexamples (including your favourite normalization). Regarding crossovers within a bar. The most primitive TS on MA open trade at their intersection. At the next crossing in the opposite direction the first thing is to close the trade opened at the old crossing and open a new one opposite to it. If I miss a crossover (and in the case of crossover inside the bar twice, as it were, it will be so), then I miss one signal. And accordingly I do not close the current trade. And my robot has two active trades, though there should always be one trade in this TS. That is why any crossover is important. Further, concerning the price at the opening of a candle. In this case the lion's share of crossover signals will be missed if we take for example MA values at close prices. A simple example - we take the MA close price (it does not matter which one to take for a new bar as it has just appeared; all МА values will be equal). Imagine the situation when the MAs are crossed somewhere in the middle of the newly appeared bar but at the open price they are not crossed. On the next new bar, that intersection is lost altogether because we take the close price on the previous bar (and they crossed somewhere between the open and close price). The signals will come only in that rare case that was originally described by me when the MA crosses precisely at the close price of the bar. It means that if the current bar is opened, there is already a limitation that МА should be applied to open prices.
I have dealt with the example I gave by introducing one non-strict inequality. Try to test the bar in my previous post (where there are two MA crossovers in one bar) and see if your robot detects those crossovers? If it only works when a bar appears, that's impossible. Only if it works by ticks. And I've already described the pitfalls there
It is never necessary to normalise anything when comparing two real numbers.
If numbers are really equal, they are stored in memory equally. Actually, it is precisely because of this property that computing machines can exist.
Hence, comparisons of the form if(a<b) or if(a==b) are correct in any case and no normalization is required.
If inquisitive mind of a researcher finds contradiction to this rule, it means that either his machine is out of order, or his mind. One of the two.
Help and documentation of course should be read at least sometimes (they were also written by humanoids like us), but it is necessary to have your own sensible reasoning.
I am not inventing the hyperdoloid. If I wanted to invent, I wouldn't be asking anything here. And I'm not being clever, but giving counterexamples (including for your favourite normalisation). Regarding crossovers within a bar. The most primitive TS on MA open trades at their intersection. At the next crossing in the opposite direction the first thing is to close the trade opened at the old crossing, and open a new one opposite to it. If I miss a crossover (and in the case of crossover inside the bar twice, as it were, it will be so), then I miss one signal. And accordingly I do not close the current trade. And my robot has two active trades, though there should always be one trade in this TS. That is why any crossover is important. Further, concerning the price at the opening of a candle. In this case the lion's share of crossover signals will be missed if we take for example MA values at close prices. A simple example - we take the MA close price (it does not matter which one to take for a new bar as it has just appeared; all МА values will be equal). Imagine the situation when the MAs are crossed somewhere in the middle of the newly appeared bar but at the open price they are not crossed. On the next new bar, that intersection is lost altogether because we take the close price on the previous bar (and they crossed somewhere between the open and close prices). The signals will come only in that rare case that was originally described by me when the MA crosses precisely at the close price of the bar. It means that if the current bar is opened, there is already a limitation that МА should be applied to open prices.
I have dealt with the example I gave by introducing one non-strict inequality. Try to test the bar in my previous post (where there are two MA crossovers in one bar) and see if your robot detects those crossovers? If it only works when a bar appears, that's impossible. Only if it works by ticks. And there I have already described the pitfalls
It is never necessary to normalize anything when comparing two real numbers.
If numbers are really equal, they are stored in memory the same way. In fact, it is precisely this property that makes the existence of computing machines possible.
Hence, comparisons of the form if(a<b) or if(a==b) are correct in any case and no normalization is required.
If inquisitive mind of a researcher finds contradiction to this rule, it means that either his machine is out of order, or his mind. One of the two.
Help and documentation certainly must be read at least sometimes (they were also written by mankind as we are), but one must have own reasonable considerations.
If there were no need in normalization when comparing double-type numbers using one of methods proposed in Documentation, such questions wouldn't arise.
And I don't have to use normalization to get necessary accuracy of triggering of any conditions in my codes. Not to mention the fact that the use of normalization of values to different decimal places in comparison, may simply be in itself convenient and required when setting comparison conditions, based on the tasks to be solved.
P./S.: But, in general, I mentioned it in this thread and before:
About the possibility with the help of normalization to adjust/adjust the required level of accuracy of comparisons (and/or output values) and/or tolerable errors for some tasks and purposes, which in turn, among other things, allows the program conditions to work exactly where and how it was intended when prescribing specific conditions in the code.