Discussion of article "Universal ZigZag" - 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
No work for specialists can become a bestseller by definition - there are few specialists.
Just in case, I don't include myself among them. The article is for guys who have just started to master or are about to. It's good.
To be properly understood, I will give links to two articles.
What do the links you cited have to do with the topic of the article?
They are relevant to the discussion that started in the initial comments on the article.
The discussion with "nurseries" actually touches on a fundamental point.
In fact, the author states that all Expert Advisors that work with time series (which is 99% of Expert Advisors) should receive data about them through indicators (via iCustom-mechanism) and only in this way. For example, if you want to work with opening prices, call the indicator, which buffer contains this timeseries. The reasoning is not new - the prev_calculated mechanism, which has been honed by developers for more than 15 years of experience in writing trading platforms.
A robot is trading. The broker either by mistake or intentionally changes something in the history retroactively. Prev_calculated is immediately reset to zero and all indicators are recalculated, including those used by the Expert Advisor. It is quite difficult to predict how the Expert Advisor will behave after that.
If the Expert Advisor used only an indicator as an OOP-object, the situation would be no worse. Therefore, it is difficult to understand the reasoning behind the power of the prev_calculated mechanism when applied to Expert Advisors.
The "nursery" discussion actually touches on a fundamental point.
1. In fact, the author states that all Expert Advisors that work with time series (which is 99% of Expert Advisors) should receive data about them through indicators (via iCustom-mechanism) and only in this way. For example, if you want to work with opening prices, call the indicator, which buffer contains this timeseries. The reasoning is not new - the prev_calculated mechanism, which has been honed by developers for more than 15 years of experience in writing trading platforms.
2. the robot trades. The broker either by mistake or intentionally changes something in the history retroactively. Prev_calculated is immediately reset to zero and all indicators are recalculated, including those used by the Expert Advisor. It is quite difficult to predict how the Expert Advisor will behave after that.
3. If the Expert Advisor used only the indicator as an OOP-object, the situation would be no worse. Therefore, it is difficult to understand the reasoning behind the power of the prev_calculated mechanism when applied to Expert Advisors.
1. Nothing of the sort. I only assert that calculating indicators in an Expert Advisor is a huge nonsense.
2. It will behave normally, nothing unusual. Nobody knows what readings the indicator will have on the next bar, but so far there has been no global flood from it.
3. What does OOP have to do with it?1. Nothing of the sort. I only claim that calculating indicators in the Expert Advisor is a huge folly.
Is prev_calculated the reason? Name the reason.
2. It will behave normally, nothing unusual. No one knows what the indicator will show on the next bar, but so far there has been no global flood.
3. What does OOP have to do with it at all?It is convenient to simply refer to the indicator in the Expert Advisor via Indicator[NumBuffer][Pos]. Hence, we are talking about OOP. Instead of iCustom make new Indicator. In this case, everything will be inside the EA. Accordingly, the code will be even more optimal.
I.e. it is logical to write an OOP indicator for both visualisation and EA.
1. Is prev_calculated the cause? State the reason.
2. It is convenient to simply refer to the indicator in the Expert Advisor via Indicator[NumBuffer][Pos]. Hence, we are talking about OOP. Instead of iCustom do new Indicator. In this case, everything will be inside the EA. Accordingly, the code will be even more optimal.
I.e. it is logical to write an OOP indicator both for visualisation and for the Expert Advisor.
1. Yes. In prev_calculated. The only, undeniable and insurmountable. If someone has a different opinion, he is deluded.
2. iCustom can also be used through a gasket in the form of OOP. It's a personal matter and doesn't change anything fundamentally. The point is that you suggest what you don't know yourself, you suggest calculating indicators in the Expert Advisor, but see point 1 here and in my previous post.
1. Yes. It is. The only, undeniable, and irresistible one. If someone has a different opinion, they are deluded.
2. iCustom can also be used through a padding in the form of OOP. It's a personal matter and doesn't change anything fundamentally. The point is that you propose what you don't know yourself, you propose to calculate indicators in the Expert Advisor, but see point 1 here and in my previous post.
I assert that the code of indicators inside the Expert Advisor is not inferior and does not require visualisation (buffers).
I have highlighted your answer in bold. An argument, however.
1. I assert that the code of indicators inside the Expert Advisor is not inferior and does not require visualisation (buffers).
I have highlighted your answer in bold. An argument, however.
1. Unsubstantiated and erroneous statement.
2. Argument.