Errors, bugs, questions - page 689
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
Alex, why don't we accept the multi-currency model as a base model and let those who don't need it beg DCs to shorten their history by cutting out the synchro-bars.
If I wanted to use the terminal as a multi-currency MQ, I would have left it on a single currency basis and would have missed the multi-currency event, hence all the problems that followed.
what do models or tester models have to do with it?
The point of the platform is to clearly receive and store the initial information in the terminals in the same quantity as it was received by the server.
The developers may not give any unbiased information! There is only as much information on ticks as there is.
If the multi-currency testing model implies a bar at every minute, this is not a model of the server, this is a model of the tester.
If the model of building indicators implies the presence of a bar at every minute, it is not a model of the server, but a model of the work of the indicator
You don't have to beg the developers to change the server to fit their models of history perception or testing, it's not constructive.
If you need the missing history of minutes, you have to ask your brokerage companies to add the bars of each missed minute to their history, with a single volume.
Ask your broker to bypass the Metaquotes crutch? The same crutch applies to singles.
Do you need the server to store the start time of the minute bar not at :00 seconds but at the time of the first tick arrival, e.g. at :05 or :24 ?
If that's all you need and that will solve a lot of testing problems - will the terminal and the quality of your tester improve a lot? Is such an offset of several seconds critical for multicurrency testing?
Do not forget that the tester models all prices inside a bar using tick volume. Will you gain much if the first tick comes as it did, and all the others do not come at all like in real life?
If this shift has no effect on the next ticks, what's the shift for anyway? For the sake of the first correct tick?
It seems to me that without a test on the real tick history - taking into account the real time of the first tick and modelling subsequent ones - is an imaginary benefit.
What do models or tester models have to do with it?
The point of the platform is to clearly accept and store the original information in the terminals in the quantity that it appeared and came to the server.
The developers are not allowed to give anything away! The amount of information on ticks is the same as it was received - not a byte more, not less.
If the multi-currency testing model implies that there is a bar on every minute, this is not a model of the server, this is a model of the tester.
If the model of building indicators implies the presence of the bar at every minute, it is not a server model, but the model of the indicator
Do not go begging the developers to change the server to suit their history perception or testing models, it's not constructive.
If you need the missing history of minutes, then you should ask for it - your DCs, that they add bars of every missed minute to their history, with unit volumes.
We fudge the facts to the required course of thought :)
The server transmits ticks, where do you see the tick history?
On the other hand the terminal receives the history, which is stored by the server, but why is it considered correct to store the history on the server in this format and not in a synchroblock format ???
Why server itself doesn't have frequency generator ???
Why is it considered correct to slice bars by time, but to introduce a frequency generator is no longer correct???
Let's get rid of time altogether then and switch to crosses and zeros. There is basically no concept of time there.
Do you want the server to store the start time of the minute bar not at :00 seconds, but at the time of the first tick, for example at :05 or :24 ?
No, it's not about that. The only thing to do is to make the opening price of the bar correspond to the price that was on the real account at the moment of the minute opening. I.e., we have to make the tester showing the opening price of the bar at the opening minute not to lie.
Is such a shift of several seconds crucial for testing of multicurrency Expert Advisors?
Yes, it is, because it causes significant unsynchronization. For example, it creates an almost constant arbitrage situation between several related symbols at the opening prices.
Do not forget that the tester models all prices within a bar using the tick volume. Will you gain much if the first tick comes in as it did and all the others are not at all like they were in real life?
Much more than it was - the synchronization will be not only between the closing prices, but also between the opening prices. Moreover, multicurrency bars will be synchronized, which will free up a huge amount of computing resources during optimization, which are now spent on the same operation on every pass - synchronization.
It seems to me that without a test on the real tick history - to take into account the real time of the first tick and simulate the next ones - is an imaginary profit.
The task of storing multi-currency history is very similar to that of storing video. You need to store a valid sync frame and save changes from it.
At present there is no synchro frame at all, there are only synchro lines. Each line (currency pair) stores its changes and even the lines have no synchronization point.
We cannot reliably say that the price was exactly at this point (bar opening).
Since the bar opening was at xx:yy:00 and the opening tick was at xx:yy:12
Since the bar opening time was at xx:yy:00 and the opening tick was at xx:yy:12
To store it that way, you need to put a lot of effort into convincing the developers that it's the right thing to do and everyone will benefit.
But it is feasible (I mean the technical side). You just need to convince them to rewrite the server-side engine (and the terminal one as well) for storing and processing bars :)
In this situation, more resistance (80%) will be at the first stage of persuasion. And after that it's up to progamers.
May Veles and Ganesh help them
You cannot reliably say that at this point (bar opening) the price was exactly there.
As the bar opening time was at xx:yy:00 and the opening tick was at xx:yy:12
You can if you only target closing prices. But to do so, we need to track the minute (not bar) closing event, taking Close[1] as the current price.
Such workarounds are completely artificial crutches developers use, but it's a backdoor solution.
Even if the developers change the situation, the simulated Ask price will still give desynchronization, both with real and multicurrency analysis in the tester.
It is, because it gives serious unsynchronisation. For example, it creates an almost constant arbitrage situation between several interlinked symbols at the opening prices.
... Which doesn't really exist, but the tester creates the illusion in the tester that arbitrage exists.
Right?
... which doesn't really exist, but the tester gives the illusion to the tester that arbitration exists.
Right?
Quite right. There is no arbitrage in real life, and the tester shows arbitrage prices on seemingly accurate (not modelled) historical data - opening prices.
It's not good...
Here I always felt in my brain that multicurrency analysis should be avoided, or else I would get a rake in the forehead. It seems that I avoided it for a reason.