Comparison of Moving Average (and any other indicators) and error - page 2
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
This has nothing to do with mql in principle. Let's take an abstract programming language. In this particular example that I have given, the main problem is that the values for the difference of muwings in one and the same bar are not equal (2e-16 in the first calculation and exactly 0 in the second). In this case, this intersection may not be determined in any way. If we return to mql, normalization implies rounding the number(or rather, simply dropping all the numbers after a certain sign, like in the Sish function floor, but to a certain decimal place). So how do I know which digit to normalize to? If the wrong digit is chosen, all values may ALWAYS be rounded to exactly 0. So normalisation is dangerous here and generally does not solve the problem.
As for what Alexey Lebedev wrote. Yes, I was thinking in this direction. But if we compare both differences by more or equal to 0, there is a probability of getting a false signal (for example, the theoretically possible situation when the muvings between neighboring bars have exactly the same values). Then their difference does not change the sign (there is no crossover), but the signal for crossover will be determined programmatically. You could put only one comparison on more or equal, as you suggested. But then the problem is that in calculation in this situation first it will not be equal to 0 (2e-16), and on the next bar it will be exactly 0 but it will be a strict comparison.
It is important to understand why the same difference, when calculated on different bars, produces NOT the same result. If the result were the same, the problem would always be solved by introducing one non-strict comparison.
When normalising, yes, there is rounding to a given decimal place. Not discarding all numbers after a certain sign, but rounding.
If I understand you exactly in that context (I take both your first post with screenshot and your second one), various experiments with such method, including taking DoubleToString into account when printing out, I suppose, can still help you. Rosomah mentioned it before me to you.
Including, help to determine for yourself to what figure to normalize at any tasks, or whether in some cases normalization is needed (in cases of doubts, application or not on the set of related factors, including that the program then can be applied in different DC and, consequently, the calculated values may be different).
From my point of view, the danger of getting signals that can be regarded as false, depending on the task at hand, can be just when normalisation is not applied (or when there is no comparison in the first way due to some small value) where it wouldn't be a problem.
In addition, if DoubleToString is not applied in the printout, there may simply be a misconception that the same difference or the same values are not the same result.
/* Just in case, I would like to mention again that when printing out numbers of double type, it is necessary to use DoubleToString, because the output converts a numeric value into a text value. Accordingly, if this function is not used, you may see errors that are not actually there.
The number of decimal places in this function, of course, with no less number of decimal places than the normalized values. And for non-normalised values, the number of decimal places is larger.
The calculation of the iMA function is most likely optimised. First value = sum(close)/N, second = previous value of MA+(new close-old close)/N.
So iMAs in general for the same bar can give different values of the two muwings at different call times?
When normalising, yes, there is rounding to the specified decimal place. It is rounding, not discarding all numbers after a certain decimal place.
If I understand you exactly in that context, which you mean (I take into account both your first post with screenshot and second post), then various experiments with such method, including taking DoubleToString into account when printing out, I believe, can still help you.
Including, help to define for yourself to what figure to normalize at any tasks, or whether normalization is needed in some cases (in cases of doubt, use or not use on set of accompanying factors, including that program then can be applied in different DC and, respectively, obtained calculation values can be different).
From my point of view, the danger of getting signals that could be considered as false, depending on the task at hand, can be just when normalization is not applied (or when the first method is not compared due to some small value) where it wouldn't hurt.
In addition, if DoubleToString is not applied in the printout, there may simply be a misconception that the same difference or the same values are not the same result.
/* Just in case, I would like to mention again that when printing out numbers of double type, it is necessary to use DoubleToString, because the print output converts a numeric value into a text value. Accordingly, when this function is not used, the following errors may occur
The number of decimal places in this function, of course, with no less number of decimal places than the normalized values. And for non-normalized values, the number of decimals is larger.
It is clear that the last significant digit is rounded. But if, for example, if you put 5 significant digits for number 0.000016, it will be 0.00002, and if there are less significant digits, it will always be 0. Therefore rounding to a specific digit is always not possible. MA values will not only depend on timeframe, but also on the bars themselves. Therefore it is not clear how to set the number of significant digits during normalization in general case.
What I cannot understand about infinitesimal value is how to apply it. Infinitesimal (error) is used to compare a real number to 0. I, on the other hand, need to compare the difference. The situation here may be even worse. For example, I set some epsilon. When the difference is greater than epsilon, I consider it positive. When it's less than minus the epsilon, it's negative. When it is within the boundaries it is 0. But then how do you determine the change in the sign of the difference? For example, the difference of muvings on two bars is within epsilon. But in the first case it is positive, in the second it is negative (i.e. crossing ALREADY happened). And I, taking into account introduction of error, will consider the difference to be 0. Then the sign change condition should be changed. Conditionally, the signal of two MA crossing from top to bottom in this case will be both a simple comparison of <0 (was) and >0 (became), and =0 (was) and >0 (became). And most importantly, in the case described (when the values at the same point are different for different calls) introducing this error does not help. This difference can always be such that whichever epsilon you choose, you won't get a signal.
It is clear that the last significant digit is rounded. But if, for example, for a number 0.000016 you put normalisation with 5 digits, it will be the number 0.00002, and if less digits, it will always be 0. Therefore rounding to a specific digit is always not possible. MA values will not only depend on timeframe, but also on the bars themselves. Therefore it is not clear how to set the number of significant digits during normalization in general case.
What I cannot understand about infinitesimal value is how to apply it. Infinitesimal (error) is used to compare a real number to 0. I, on the other hand, need to compare the difference. The situation here may be even worse. For example, I set some epsilon. When the difference is greater than epsilon, I consider it positive. When it's less than minus the epsilon, it's negative. When it is within the boundaries it is 0. But then how do you determine the change in the sign of the difference? For example, the difference of muvings on two bars is within epsilon. But in the first case it is positive, in the second it is negative (i.e. crossing ALREADY happened). And I, taking into account introduction of error, will consider the difference to be 0. Then the sign change condition should be changed. Conditionally, the signal of two MA crossing from top to bottom in this case will be both a simple comparison of <0 (was) and >0 (became), and =0 (was) and >0 (became). And most importantly, in the case described (when the values at the same point are different for different calls) introducing this error does not help. This difference can always be such, that whatever epsilon you choose, you will not get signal.
I think that when solving any particular problems, you can also rely on the accuracy of decimal significant digits. At double it is 15 significant digits, according to the Documentation. The format of the normalisation accuracy, from 0 to 8, according to the Documentation. DoubleToString has its own peculiarities of accuracy formats.
Besides, iMA is, from my point of view, a function taking into account that the values derived with it will be applied in different situations and to solve different problems. Accordingly, the values it outputs can be processed differently, also with respect to specific tasks.
In addition, calculating averages is a mathematical calculation. For example: (1.20525 + 1.20598 + 1.2081)/3 = 1.2064433333... Correspondingly, calculated values with small or extended roundings increase the options for applying the calculations.
Just in case, I want to mention that instead of iMA, you can use the functions from MovingAverages library, which is included in the standard terminal package. Or you can use your own functions based on the ones in this library.
/* In mathematical calculations, there may bepeculiarities of working with numbers of type double */.
About epsilons, on the other hand, I'll pass.
P./S.: So, I think experiments can help you. Theoretical reasoning without practical experiments (on large amount of data) for specific tasks, including, can confuse, and lead away from acceptable solutions.
Dina Paches:
...
What a mess. We've been comparing MAs for 300 days... Normalise to digits and don't bother...
You can normalize the values directly (the difference - no way). But again, the given ala benchmark code for comparison of MA must be changed and one should enter a non-strict inequality anyway. Besides, the issue of different MA values on one and the same bar when calculated at different times remains open. If it will be repeated further, it is not sure that even normalization and introduction of one non-strict inequality will solve the problem completely. Plus the case when the muwings within one bar intersect twice, you can not catch, if you analyze not by ticks, but by the opening of a new bar. Maybe you can share your experience, how do you act in this situation?
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, then the Expert Advisor should clearly monitor the opening of a new bar, and after the fact, check for crossovers.
First decide for yourself - trade at bar opening or at every tick, then write your code. And, accordingly, test it the same way.
Dina, I am amazed at your angelic patience ...
Thank you, Artem, but unfortunately it turns out that it can have limits too.