On one application of the OOP - 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
The main thing is how to use it afterwards. To try different inputs, you can do this in bulk by input set number. I.e. there is a collection of input sets. If convenient, then as an array of functions. The simplest ones - unconditional buy or sell by market. Or conditional)). And then we will run the optimizer and look through the different entry sets.
Yes, it seems so far, we set strategy number in settings and optimize by number in optimizer. But this is for the first time, I have been dreaming to do self-optimization on the fly for a long time.
What is the purpose of this self-optimization (target function)?
The aim is obvious. Firstly, the optimiser in the tester is missing the current day, at least in MT4 for sure. And I do it for MT4.
Secondly, the market may change sharply during the day, without any reason (news). Probably you've noticed it, a sluggish flat... And suddenly, as if mustard has been spread under the tail, quotes start to tear. Either it's a flat, or it's total chaos.
I think we can classify such conditions and include the required modification of the strategy when defining them. How to do it? I do not have enough guts to create an AI. But the method of optimization can indirectly determine the state.
So far, these are just untested thoughts.
Yes, it seems so far, in the settings we set the number of strategies and optimize by numbers in the optimizer. But this is for the first time, for a long time I have a dream to do self-optimization on the fly.
Your client wants to wrap all the strategies he knows into one expert, as I understand it. You will not be able to finish this task until you have a list of strategies. I suggest drawing up the ToR together.
If PLUS to this list of strategies you touch upon the issue of self-optimization, then write him a neural network, don't reinvent the wheel and don't boggle your client's mind with knowledge of basic programming. This is exactly what he asks of you.
And can I give you an example of a "bashing"?
Here you go. Hierarchy of trading classes in the standard library:
It implies that the money management module is an Expert Advisor. Trailing Stop is also an Expert Advisor. Expert Advisor includes other Expert Advisors. This inconsistent inheritance results from the fact that both trailing stop and money management need access to some private data and methods of a basic Expert Advisor.
By the way, there are long garlands of inheritance. CIndicators use CIndicatorBuffer that in its turn calls its superior methods. As the result, a simple tracing of the indicator value becomes a very confusing task. After three recursive calls, we completely lose the sense of where something is coming from.
And this is just one example of poor inheritance. In fact, any more or less large hierarchy of classes based on inheritance almost always becomes inconsistent, confusing and recursive. Which makes debugging and further development extremely difficult.
We think that the depth of inheritance should be limited to 1-2 levels. Moreover, the first level should inherit from the global and universal definition of the zero level CObject (all are objects) and implement the specific entity "Expert", "Indicator", "Trailing Stop". The second level should implement the specific implementation of "Expert Advisor based on MACD", "SMA indicator", "Trailing Stop", etc. But the use of the third level must be severely punished and prosecuted.
In other words, it turns out that classification is a truly valuable tool only when it is:
Your client wants to wrap all the strategies he knows into one expert, as I understand it. You will not be able to finish this task until you have a list of strategies. I suggest drawing up the ToR together.
If PLUS to this list of strategies you touch upon the issue of self-optimization, then write him a neural network, don't reinvent the wheel and don't boggle your client's mind with knowledge of basic programming. This is exactly what he asks of you.
Here you go. Hierarchy of trading classes in the standard library:
It implies that the money management module is an Expert Advisor. Trailing stop is also an Expert Advisor. Expert Advisor includes other Expert Advisors. This inconsistent inheritance results from the fact that both trailing stop and money management need access to some private data and methods of a basic Expert Advisor.
By the way, there are long garlands of inheritance. CIndicators use CIndicatorBuffer that in its turn calls its superior methods. As the result, a simple tracing of the indicator value becomes a very confusing task. After three recursive calls, we completely lose the sense of where something is coming from.
And this is just one example of poor inheritance. In fact, any more or less large hierarchy of classes based on inheritance almost always becomes inconsistent, confusing and recursive. Which makes debugging and further development extremely difficult.
We think that the depth of inheritance should be limited to 1-2 levels. Moreover, the first level should inherit from the global and universal definition of the zero level CObject (all are objects) and implement the specific entity "Expert", "Indicator", "Trailing Stop". The second level should implement the specific implementation of "Expert Advisor based on MACD", "SMA indicator", "Trailing Stop", etc. But the use of the third level must be severely punished and prosecuted.
Now I understand the idea. By the way, the simple way I have implemented this in my trading robots as I pointed out. Only the names are different.
ZS: What did you make such a graph in? Something a la Doxygen?
Here you go. Hierarchy of trading classes in the standard library:
It implies that the money management module is an Expert Advisor. Trailing stop is also an Expert Advisor. Expert Advisor includes other Expert Advisors. This inconsistent inheritance results from the fact that both trailing stop and money management need access to some private data and methods of a basic Expert Advisor.
By the way, there are long garlands of inheritance. CIndicators use CIndicatorBuffer that in its turn calls its superior methods. As the result, a simple tracing of the indicator value becomes a very confusing task. After three recursive calls, we completely lose the sense of where something is coming from.
And this is just one example of poor inheritance. In fact, any more or less large hierarchy of classes based on inheritance almost always becomes inconsistent, confusing and recursive. Which makes debugging and further development extremely difficult.
We think that the depth of inheritance should be limited to 1-2 levels. Moreover, the first level should inherit from the global and universal definition of the zero level CObject (all are objects) and implement the specific entity "Expert", "Indicator", "Trailing Stop". The second level should implement the specific implementation of "Expert Advisor based on MACD", "SMA indicator", "Trailing Stop", etc. But the use of the third level must be severely punished and prosecuted.
In other words, it turns out that classification is a truly valuable tool only when it is:
+ very true thoughts.
ZS: What was such a graph drawn up in? Something a la Doxygen?
Yes, if only ;) Carpeled over this in SnagIt for about an hour. Made it especially for my article.