Discussing the article: "Developing a multi-currency Expert Advisor (Part 2): Transition to virtual positions of trading strategies" - page 5
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
It is not a fact that in the market the complication of the model will work better than a basket of simple TSs
It seems to me that the implementation of the highlighted is a very non-trivial task. Usually, strategy parameters are set at the start, and the opening/closing signals are determined by some algorithm while the strategy is running. If we save the history of openings in some unified form, then it will have to be fed to the input of the second strategy.... Is it so? If we give this information in the form of an algorithm (function) and its fixed parameters, won't it turn out that we have come to the same bagging, but with a backdoor?
https://t.me/fxsaberDiscussion/3877
Thank you very much, I read it with interest. I want to do just something similar, only with more automation, for which I plan to mercilessly put into operation your libraries for working with *.opt and *.tst files of the tester.
It seems to me that implementation of the highlighted is a very non-trivial task. Usually strategy parameters are set at startup, and opening/closing signals are determined by some algorithm while the strategy is running. If we save the history of openings in some unified form, then all of it will have to be fed to the input of the second strategy.... Is it so? If we give this information in the form of an algorithm (function) and its fixed parameters, won't it turn out that we have come to the same bagging, but with a backdoor?
I haven't thought about how to do it through the optimiser. No, it should turn out that each next strategy will improve the previous one, i.e. build on top of it. How exactly to visualise it is a matter of time. You can just look up how boosted trees work in the Internet and use them as a basis for your design. There may be a lot of nuances, yes. But I won't do it myself, because all this is already in the MO algorithms. And it is not a panacea, but it can be better than a TC portfolio in terms of its properties.
Hadn't thought about how to do it through the optimiser.
This is a routine that can be fully automated through connecting the appropriate mqh to mq5.
The algorithm is as follows.
So you can mix anything you want. It is obvious that even with a complete search, the final result will depend on the sequence in which the TSs are launched.
It is also clear that even on the SB there will be an improvement of indicators with each pass, but it will be a fitting.
Thank you very much, I have looked at the code. I will look into passing input parameters later. If it doesn't work out to take this approach completely, some points are likely to be very useful.
I applied the current results of my work with inputs again (in the appendix) to the code from this article.
Here is an example of what SimpleVolumesExpertSingle.mq5 has become.
I managed to achieve a one-time prescription of inputs(SimpleVolumesStrategyInput.mqh) in the code.
I applied the current results of my work with inputs again (in the appendix) to the code from this article.
An example of what SimpleVolumesExpertSingle.mq5 has become.
I managed to achieve a single entry of inputs(SimpleVolumesStrategyInput.mqh) in the code.
It seemed to me somehow noticeably easier than the previous variant. Although, maybe it's just that when you look at someone else's code once again, it becomes clearer and simpler each time. Thank you very much! While studying, a question arose, is it possible to place the code that comes after "// Copy-Paste update from here:" in an include file and plug it in instead of pasting it? It's not convenient to just experiment right now, so I thought I'd ask.
In the third article I haven't got to the input parameters yet :(. But it will come for sure.
While studying, a question arose, is it possible to place the code that comes after "// Copy-Paste update from here:" in an include file and plug it in instead of pasting it? It's not convenient to just experiment right now, so I decided to ask.
Unfortunately, you can't, because #include of the same file happens only once - the first encounter. After that it is ignored.
This is one of the reasons why you had to make a completely identical file with a different name here.
But in general, the Copy-Paste option is a couple of clicks. Understanding that code is not required.
In the third article, the input parameters have not yet reached the input parameters :(. But it will come for sure.
Your architecture is somewhat different from mine, so I didn't provide INPUT_STRUCT with a lot of things that would be useful in this project.
It's good that you didn't publish it, because I've redone it again - to the most concise and convenient version (it seems to be the final one).
I added group, string-inputs and some other small things for future convenience.
Pieces of application code to demonstrate how it is used.
It's a good thing they didn't post, as I've redone it again - to the most concise and user-friendly version (seems to be the final one).
Yes, very familiar situation. Everything seems to be there, and then you redo it and it's even better. I think that this is not the final version either, because you oriented on those scenarios of using parameters in code that have already been published. When it comes to building parameters into sets, and even more so to automatic building into sets, you'll probably find that you can improve/simplify as well.
Thanks!!!