Comparison of Moving Average (and any other indicators) and error - page 4
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
Thanks for the advice of course, but I can read the Help myself. And I repeat computational mathematics is not tied to a particular programming language. It's just the calculation errors I have to deal with, which you'll pass with.
If you can not only read the Help, but also understand it, then you are engaging in deliberate demagogy, stubbornly continuing to talk about normalisation and its potential applications in a belittling spirit. Including deliberate demagoguery about the dangers of its application.
And I'm not being clever, but giving counterexamples (including for your beloved normalization).
The demagoguery was there. There were no counter-examples on normalisation.
Apart from the fact that someone can misapply it.
So the epsilons can be applied incorrectly. Yes and the demagoguery has already been mentioned.
P./S.: The post is about normalisation, so I don't mention moving averages.
And I think Artem can help you better with EAs using MAs than I can with those difficult ones.
Look for crossovers on every tick. What's the problem?
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.
If you can not only read the Help, but also understand it, then you are engaging in deliberate demagogy, stubbornly continuing to talk about normalisation and its potential applications in a belittling spirit. Including deliberate demagoguery about the dangers of its application.
Demagoguery was there. There were no counterexamples on normalization.
Not including the fact that someone may not use it correctly.
So the epsilons may be applied incorrectly. And the demagogy has already been mentioned.
There have been counterexamples (at least in terms of normalisation also of difference, as voiced here). I'll say it again: normalisation is the easiest way for those who don't want to dig into the intricacies. He has read the documentation and piously believes it all. Again, I repeat that the programming language within computational mathematics is irrelevant. If it's written in this in the helpe, that doesn't mean it's true (otherwise there wouldn't be any computational maths and epsilon problems you dislike so much). There's a lot written on the fence too, but that doesn't mean it's the truth in the last resort. You're happy with the Halp option, you have every right to be. But it's your personal choice. And it doesn't mean that it solves all the problems I've been trying to make clear here. And to consider as demagoguery something that you simply do not want to understand (again, your right), does not mean that it is demagoguery itself. I'm not asking rhetorical questions about the meaning of life (the answers to which are just demagoguery), I'm just trying to understand something that I haven't yet encountered. Again, let's say the values are always the same whenever you calculate them. There you could get something from the same computational mathematics. But when the values are different as well, you won't be able to come up with a universal algorithm, even if you are a mega-guru.
Besides, I just want to make sure that my understanding that if a robot does not work by ticks, getting multiple intersections inside a bar is basically impossible. It can already be attributed purely to the intricacies of mql.
P.S. I'm not trying to argue with someone groundlessly, I don't think I'm a right genius all the time. I just don't like when people try to be clever and write something without even reading it. It has nothing to do with you personally. Thank you for your help and your thoughts on the subject. But still, IMHO it is wrong to write something about patience when you insist on only one point of view in documentation (which you wholeheartedly believe and do not accept any alternative views and examples), and epsilons are not to your liking. I hope Artyom understands what I wrote in the postcript before that too. Thank you all for your replies and pardon me if I got a bit testy somewhere.
P.P.S. Normalization to a certain decimal place is in fact analogous to introduction of epsilon just by the order of the same sign.
P.P.P.S. If we have such a heated discussion, I would be very grateful if you share your experiences in this topic, because proper answers (especially on the 2 and 3 items that bother me), in fact, did not get. Although scouring many forums, almost came to the conclusion that, yes, 2 point is impossible. Developers of mql could think about this, and provide more flexibility, because it is very inconvenient (in any other programming language has the ability to dynamically change the program interface, and here it turns out there is none ((()))
There have been counter-examples (at least in terms of normalisation also of difference, as voiced here). I'll say it again: normalisation is the easiest way for those who don't want to dig into the intricacies. He has read the documentation and piously believes it all. Again, I repeat that the programming language within computational mathematics is irrelevant. If it's written in this in the helpe, that doesn't mean it's true (otherwise there wouldn't be any computational maths and epsilon problems you dislike so much). There's a lot written on the fence too, but that doesn't mean it's the truth in the last resort. You're happy with the Halp option, you have every right to be. But it's your personal choice. And it doesn't mean that it solves all the problems I've been trying to make clear here. And to consider as demagoguery something that you simply do not want to understand (again, your right), does not mean that it is demagoguery itself. I'm not asking rhetorical questions about the meaning of life (the answers to which are just demagoguery), I'm just trying to understand something that I haven't yet encountered. Again, let's say the values are always the same whenever you calculate them. There you could get something from the same computational mathematics. But when the values are different as well, you won't be able to come up with a universal algorithm, even if you are a mega-guru.
Besides, I just want to make sure that my understanding that if a robot does not work by ticks, getting multiple intersections inside a bar is basically impossible. It can already be attributed purely to the intricacies of mql.
P.S. I'm not trying to argue with someone groundlessly, I don't think I'm a right genius all the time. I just don't like when people try to be clever and write something without even reading it. This has nothing to do with you personally. Thank you for your help and your thoughts on the subject. But still, IMHO it is wrong to write something about patience when you insist on only one point of view in documentation (which you wholeheartedly believe and do not accept any alternative views and examples), and epsilons are not to your liking. I hope Artyom understands what I wrote in the postcript before that too. Thank you all for your replies and pardon me if I got a bit testy somewhere.
P.P.S. Normalization to a certain decimal place is in fact analogous to introduction of epsilon just by the order of the same sign.
P.P.P.S. If we have such a heated discussion, I would be very grateful if you share your experiences in this topic, because proper answers (especially on the 2 and 3 items that bother me), in fact, did not get. Although scouring many forums, almost came to the conclusion that, yes, 2 point is impossible. The mql developers could have thought about this, and provide more flexibility, because it is very uncomfortable (in any other programming language has the ability to dynamically change the program interface, and here it turns out there is none ((()))
For me using data conversion using NormalizeDouble function when comparing doubles is one of two ways, stipulated in Documentation, to get program conditions to work exactly where and how it was intended when writing specific conditions in code. That is what I was talking about earlier. Accordingly, it is not only the elimination of any errors. It's also various thoughtful ways of transforming data to fulfill any conditions.
I've told you and am telling you about it, based on my personal practical experience in the programming language you're just starting to learn. For this reason, and suggested repeatedly in this thread, to use such a practical way.
By the way, I will say, in part, agreeing with you, that I will not dispute that normalization with this function may be the easiest way for any tasks in terms of transformation of real-type data
But it's up to everyone to decide which of the two methods recommended in the Documentation to use when converting data of real types.
And choosing any of these ways is not a determinant of whether one is the kind of person who tries to figure out any necessary subtleties or not.
That I don't like epsilons was not a word on my part. Not applying any method is not necessarily love/dislike. Nor did I insist on applying only the second way of the two.
My literal words in terms of practical application of peculiarities of working with numbers of type double, that:
P./S.: It so happens, that the first method from Documentation turned out to be less convenient for me to use, including, based on tasks, which, as a rule, I solve for myself. Consequently I don't have a lot of experience with the first way.
But when applying the second way (i.e. comparing normalized difference of two real numbers with zero value in conditional operator expression), any problems did not arise unambiguously.
But if I did a comparison of non-normalized numbers (here I mean, without using the first way too), then yes, it was that I found incorrect working of conditions on the basis of comparisons of numbers of type double.
Besides, I also gave such a clarification:
P./S.: That said, just in case, I will clarify once again, that comparing real numbers by the first method of the two listed here , bycomparing the difference of numbers with some small value, I can not call worse than using normalization, when you need to adjust the level of comparison (incl., since for me the second method was more convenient, I did not consider for myself more detailed for the practical application).
That is, in terms of normalization when converting double data, I just didn't need the first way. In particular, due to convenience for me in using the NormalizeDouble function in solving various problems (and not only in comparisons).
This site has a huge accumulated knowledge base.
People have been solving all kinds of problems of different complexity using MQL4.
After MQL4 was brought closer to MQL5, the possibilities of the first one have increased even more.
I think you should become better acquainted with this programming language and not ignore the knowledge base accumulated on the sites here. Gain practical experience in using it. And only then you can say something confidently in terms of any applications in this programming language and its capabilities.
I have a different ToR) And again, I've already written about the problems with ticks. There is no way you can explain to the customer why the robot entered the trade if he does not see the crossover on the chart
Take the MA values on the zero and the first bar on every tick - then and only then you can find crossovers of MAs on the zero bar. You take them from the first bar at the time of the zero bar opening - and there the MA values are those that were present when the first bar was closed, not when it was formed. You simply read МАšek values late and therefore do not see them crossing. The normalization has nothing to do with it. And by the way, if MAs show price values, then the values should be normalized to _Digits, instead of guessing to what value the normalization is needed...
Dear participants of the forum. Please do not establish squabbles on the forum. Only on the subject of the thread.
I think the topic can be closed. The authors (not the topic) of the statements did not come to a consensus. There were isolated moments of chauvinism, which is not welcome.
But neither one nor the other have been able to prove their case. That's why I close the thread. Further discussion may be punished (maximum daily ban).
Although if there will be given normal evidence, it is welcome.
The judges will be me and Volodya.
This is not a discussion.
I haven't seen all that here, so I don't know what arguments have been made within the topic. But since I suppose it's about proving my position, which is similar to Artem's position in this post (and earlier here in the thread), I'll give one of the examples below, in connection with whether normalization should be applied in one way or another when working with numbers of real type.
With screenshots and a variant of the test code.
Artyom wrote in the post above:
И, кстати, раз МА показывают значения цены, то и нормализовать значения нужно до _Digits, а не гадать до какого же значения нормализация нужна...
And since I also believe (as I think many others do) that this is a simple and effective way in the most common directions of problems, I will make only this small addition of my own:
with how many decimal places it is conceived to display line MA, or just carried out calculations based on any number of decimal places (the same comparison), with so many decimal places and normalization (rounding to a certain decimal place).
/*For some individual tasks, there may be "exceptions", and you can vary to get the desired result, for example, by comparing a value with a lower decimal place, with a value with a higher decimal place. But if this is needed for the task at hand, then in my view it can be well advised, as with the above method, to print out the values obtained and compare the values obtained with the visually displayed rendering on the chart, if necessary.
If we need to output values of double type as text (through Print, Comment, OBJ_LABEL, etc.), then we need to use DoubleToString since we want to convert number into text.
Now, from introductory explanation to clarity:
In the screenshots:
Data of the test script are MA values obtained using the iMA function (with and without transformations using the functions described for working with real types in the Documentation).
In the data window and on the chart you can see that the lines with a lower decimal place have equalized in values on the third bar, not counting the current one, of the chart. You can also see that the MA values from the standard set to the terminal, drawn on the decimal places of the chart, are not equal and visually they have equalized on the chart a bit earlier.
I.e. if you enlarge the screenshots or perform your own experiments using the attached test script or your own codes, you will see that the MA lines, with the number of decimal places as in the chart, cross a bit earlier.
And that's understandable. By analogy, lines with decimals are one less than lines drawn with two-digit quotes on a three-digit chart. It allows to see them in "old" points of the time when three- or five-digit quotes in terminals are not wide spread and, at the same time, have the advantages of extended decimal quotes for trading (including narrower spreads).
That is, lines based on values with fewer decimal places have less "noise".
But if rounding was not applied (in this case, using the normalisation function), a number clearly limited to a specific decimal place would be more problematic.
Or, if just in numbers:
123.4561 and 123.4556 are not equal. And their difference is not zero.
However, if you round them up, both the first and second numbers, will be the same and equal to 123.456. Accordingly, the difference between them will be 0.
It is up to the decimal point to round the resulting values, depending on the tasks to be carried out.
In the screenshots in the "Experts" journal, you can see the MA values output using iMA with the conversions described in the Documentation, and without conversions of the resulting values. MA settings in the test script are equal to those of indicators on the chart.
In the second screenshot, you can see the deltas between two MA values with and without transformations.Below, as I mentioned, is a small test code. It is not optimized but allows making various experiments with MA values including changing of some parameters.
The number of bars in it is set in this line:
P./S.: I have replaced the attached test script. I got the wrong variant in my post. Wrong. Sorry.
The previously attached screenshots are not required, so I leave them the same.