Structure rules. Learning how to structure programmes, exploring possibilities, errors, solutions, etc. - page 17
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
Do I have to take your word for it?
and you will never agree with him.
he hasn't dealt with your task. so he's racking up "virtual" complications to justify his words.
forget it and move on.
Where is the trawl there? I understand that it is in the MM block?
or is it still in the market driver? because you need the current position to trawl.
I would also introduce a volatility predictor and put one more block to correct protective stops, precisely protective stops because (imho) exit by TP or SL is a force majeure for a normal TS.
Absolutely agree about force majeure, that's why I don't work with them. Only the protective ones.
I have thought about volatility forecasting but have not done it yet. If it is done, it will provide information to the driver, by itself. :)
and you will never agree with him.
He hasn't dealt with your problem, so he's making "virtual" difficulties to justify what he's saying.
Forget it and move on.
I'm not trying to, I'm not even writing for him ;-)
It just helps me to do a sort of FAQ on netting right here. sort of like a co-author. )))
// All the questions/assaults are predictable enough. All answers to them have long been discussed for a hundred kilometres in the vicinity. Nothing new.
// "I've got the kind of answers no one will even ask a question about..." (ц)
...
// "I have the kind of answers no one will even ask a question about..." (ц)
Such questions would even be interesting to hear without answers. )))
I suggest to go back to discussing the general principles of programming large projects.
One of the principles is called"data abstraction":
The system must not depend on the format of the input and output data.
Its job is to make the correct calculations by feeding universal signals to the inputs and producing universal signals to the outputs.
In this case, the system will not need to change when these formats change.
Adaptation to the formats is provided by converters/drivers at the system interface level.
As we can see:
Any Expert Advisor of mine built according to the described scheme carefully follows this principle and, for example, can be ported to MT4 immediately after upgrading the programming language to mql5, simply by replacing the market driver and input indicators.
All EAs built according to your scheme will have to be completely rewritten. I'm sorry, but the fact is there.
All EAs based on your scheme will have to be completely rewritten. I'm sorry, but the fact is there.
Not if the trading systems will 1) give trade orders through the strategy management module 2) only use the data provided by the strategy management module. The module itself will indeed have to be rewritten, as well as the driver.
The trading driver reduces the reliability of the system.
There is no need for a volatility meter. It is part of the TS.
Oh, Vladimir, it's not so easy with your circuit. You're saying that you only need to rewrite the driver? Well, 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 - another 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, to work with the positions - a third, so in the end there are twice as many modules, and the same amount of platform-dependent code.