Structure rules. Learning how to structure programmes, exploring possibilities, errors, solutions, etc. - page 18
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
Oh, Vladimir, it's not so easy with your circuit. You're saying that you only need to rewrite the driver? But I've counted a lot more platform-dependent parts:
How will you get the market history and the trade history? And the information on the current position will not be taken from the terminal, by any chance? And if you have to implement the volatility module - one more platform-dependent API?
Will you write adapters? How many of them will there be? For the market history - one adapter, for the trading history - another one, for working with the positions - a third one. So, in the end, there will be twice as many modules, and the same amount of platform-dependent code.
That's not how I see the problem.
Just everything that is red is quite stable, all that comes from the platform does not change over the years, if you need for another platform, there is also a well-established API, rewrite no problem.
But all modules with green arrows are their own, and almost always active rework (there is no limit to the ideal).
The directional forecaster was written, then came the new idea to deepen and expand, well, like now it is buy, but we have to get ready for sell, slowly reduce the volume.
So I started to use two modules.
MM Corrector is also a dynamic scheme, now it works with positions, then suddenly it had an idea and decided to change it for long positions (smooth market entry).
Market Driver should be stable because it has output to platform-dependent API, therefore formalization is clear, but there will be a lot of twisting, because API provides a lot of possibilities.
That's not how I see the problem.
Just everything that is red is quite stable, everything that comes from platform doesn't change for years, if you need it for another platform there is also a well-established API, rewriting is not a problem.
One of the important ideas in the scheme is not the number of platform-dependent parts, but their strict localization. That is: TS itself (predictors + MM-modules) - it is a platform-independent design, but the data sources are indicators and market driver, respectively dependent (trade history, fed to the input of the recommendations corrector - is also essentially the indicator).
The consequence - a clearly limited zone of intervention clearly distinguishable and non-overlapping at
1. Migration.
2. Improvement of the TS, in particular, scaling.
But all modules with green arrows are their own, and almost always an active redesign (there is no limit to the ideal).
The directional forecaster was written, then came the new idea to deepen and expand, well, like now it is buy, but we need to prepare for sell, slowly reduce the volume.
So I started to use two modules.
The MM Corrector is also a dynamic scheme, now it works with the position, then all of a sudden it got wise and decided to change it for equity (smooth market entry).
The Market Driver should be stable because it has output to platform-dependent API, therefore the formalization is clear, but there will be a lot of mess because API provides a lot of features.
Nobody promised absence of complications :) But think if all those direct API calls are not localized in driver, but mixed with codes of predictors and MM-modules.............
;)
Nikolay, your post is very sensible, however I undertake to defend the proposed scheme (its universality).
I agree, I just want to clarify (on this occasion) for Vasily. One of the important ideas in the scheme is not the number of platform-dependent parts, but their strict localization. That is: TS itself (predictors + MM-modules) - it is a platform-independent design, but the data sources are indicators and market driver, respectively dependent (trade history, fed to the input of the recommendations corrector - is also essentially the indicator).
The consequence - a clearly limited zone of intervention clearly distinguishable and non-overlapping at
1. Migrations.
2. Improvement of the TS. In particular, scaling.
However, if we carefully stick to the division of platform-dependent/independent parts of the system, then for example in our current situation we can easily support development of EAs for both platforms (MT4/5), that would be a hassle in platform-dependent trading systems.There can be any number of modules inside the components marked in the scheme. This is normal. I think that only their clear pipeline arrangement is useful. Which should not be mixed up inside the code without absolutely unavoidable necessity. i.e. You should avoid shuffling as much as possible. This allows you to always have well-defined and convenient module docking points when scaling towards multitools. Look at the scheme from this angle, you'll find it yourself.
See above. // But the MM corrector input is the most convenient point to integrate a cloud of single-currency (single-instrument more accurate) forecasters into a multi-currency (multi-instrumental) kitchen.Nobody promised complete absence of complexities. :) But think if all these direct API-calls are not localized in driver, but mixed with codes of predictors and MM-modules.............
;)
OK, let's use that as a basis (but add a stop module, seems reasonable and no one has any objections),
and think what else is missing in this scheme, or redo it.
OK, let's take it as a basis (but add a module for working with stops, as it seems reasonable and no one has any objections),
and think about what else is missing in this circuit, or rework it.
I will think about rework-improvement (let it cook).
The lack is more obvious - this scheme obviously lacks the GUI (visual monitoring/control subsystem). I want to develop a unified (and convenient!) scheme of interaction of the Expert Advisor with the GUI. So far, I am spontaneous in this matter, which really annoys me. I would like to achieve the same goal (full data abstraction in both directions). That's why I suggested the EA/GUI interface task for training, I'm interested in it mercantile-wise, I wanted to get some ideas from the public.
There can be any number of modules inside the highlighted in the scheme components. This is normal. I find it only useful to have their clear pipeline arrangement. Which should not be shuffled within the code without absolutely unavoidable necessity. I.e. This allows you to always have well-defined and convenient docking points when scaling towards multitools. Look at the diagram from this angle and you'll find it yourself.
Unlimited module sprawl leads to serious problems in the future. You have the Expert Advisor's logic practically dispersed into different modules. The modules themselves will interact with each other, and there is no guarantee that the links between them will not turn into a tangle. Imho, all squares marked green are elements of one trading system. Decomposing them into different modules violates one of the main programming principles: encapsulation of data and methods within one task.
Since everyone has started to publish their own schemes, I will continue too. This time it is even more abstract scheme:
Black arrows describe rigid relationships. The grey ones are private interrelations inside the module, they are not important. Also, trading robot class can directly address platform API, but platform-independency is reduced.
Unlimited module sprawl leads to serious problems in the future. You have the Expert Advisor's logic practically dispersed into different modules. The modules themselves will interact with each other, and there is no guarantee that the links between them will not turn into a tangle. Imho, all squares marked green are elements of one trading system. Decomposing them into different modules violates one of the main programming principles: encapsulation of data and methods within one task.
Since everyone has started to publish their own schemes, I will continue too. This time it is an even more abstract scheme:
Black arrows describe rigid relationships. The grey ones are private interrelations inside the module, they are not important. Also, the trading robot class has the right to directly access the platform API, but this reduces platform-independence.
On the redesign-improvement side, I'll think about it (let it brew).
The lack is more obvious - this scheme obviously lacks GUI (visual monitoring/controlling subsystem). I want to develop a unified (and convenient!) scheme of interaction between the Expert Advisor and the GUI. So far, I am spontaneous in this matter, which really annoys me. I would like to achieve the same goal (full data abstraction in both directions). That's why I suggested the EA/GUI interface task for training, I'm interested in it mercantile-wise, I wanted to get some ideas from the public.
Go from the task. What are the most demanded tasks in the GUI?
Go from there. Describe what you want to get, select common headings, make a framework, then add some more stuff, see how easy it is to change the framework.
Then you will understand how it should be, rewrite it all over again. I see it that way.
MetaDriver says it right, and his system is correct. Dick_fx would also add that the "trading driver" should work with 10-20 platforms to use the best prices.
But using such a correct system is convenient only under ideal conditions - no errors in strategy, no user intervention, no force majeure... And in reality this is rarely the case.
Let me give an example of dick_fx: 25 strategies are working, aggregator (trade driver) collects them into a net position and puts them into the market, everything is OK. Suddenly, something goes wrong in 17-th strategy and it gives unhealthy forecasts - it says to open at 50% of the deposit. Expert Advisor opens obediently.
What does a trivial locker a la MT4 do:
Now let's move on to "correct accounting". What should the trader do to correct the error (a 50% margin trade - an obvious logic error)?
The question is: Which is easier? Obviously, the variant with MT4.
And what is cheaper? Obviously, the Netting option.
What is the conclusion? Make a market driver with a GUI from MT4 ;)
And one more thing.
This is all the reasoning of "right" traders, and even programmers. If they do it for their own pleasure, on the account with a good deposit, then it is the only way to do it.
If we touch upon the expert writing, it turns out that nobody needs it "right". The crowds of traders-customers cannot be changed, so one has to write "for them".
The "quit my job" option is accepted! =)
And one more thing.
This is all the reasoning of "right" traders, and even programmers. If they do it for their own pleasure, on the account with a good deposit, then it is the only way to do it.
If we touch upon the expert writing, it turns out that nobody needs it "right". The crowds of traders-customers cannot be changed, so one has to write "for them".
The "quit my job" option is accepted! =)