Errors, bugs, questions - page 690
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
Fudging the facts to the required current of thought :)
Server transmits ticks, where do you see tick history???
On the other hand the terminal receives the history stored by the server, but why is it considered correct to store the history on the server in this format and not in synchro-bar???
Why server itself doesn't have frequency generator ???
Why is it considered correct to slice bars by time, but introducing a frequency generator is no longer correct ???
Let's get rid of time altogether and switch to zeros. There's basically no concept of time there.
That's exactly the way it is.
The other twist is that it allegedly requires some grandiose changes to the server.
The truth is that you can change nothing at all on the server. Zero! Everything is solvable by means of the terminal.
I can suggest variants of economical and beautiful realization. But that would only make sense if Renat "opens the subject".
The truth is that nothing can be changed on the server at all. Zero! Everything can be solved by means of the terminal.
I can suggest options for an economical and beautiful implementation. But it would make sense if Renat "opens the topic".
If we are talking only about synchronization of multibars (roughly speaking, removing holes) - then the server is 100% not involved.
Everything can be done by the terminal and the tester. If you want to go deeper, you'll have to make some changes on the server.
I always felt in my brain that multicurrency analysis should be avoided, or else I would get a rake in the forehead. I see that I avoided it for a reason.
It's easy to get slapped in the face with multicurrency. For example, you test a multi-currency, get MO = $2. And then it turns out that a significant part of this MO is just imaginary because of the unsynchronized simulated ticks and unsynchronized history itself - the opening price. And the more symbols are involved at the same time, the greater will be the effect of asynchronization. In this case the tester will always show the situation better than it was on the real account.
Only your own calculator will help. The multicurrency tester is formally, but its adequacy is greatly exaggerated.
Exactly right. There is no arbitrage in real and the tester shows arbitrage prices on seemingly accurate (not modelled) historical data - opening prices.
Why do you test arbitrage strategies in bar opening test mode?
This mode is intended only for rough testing and only for Expert Advisors that trade only by bar opening. To avoid such questions, we have implemented very accurate testing mode even in the bar opening method. After complaining about the speed, we have changed the speed mode and now it is your fault again?
Or are we talking about the potiq mode?
Or are we talking about the Potik mode?
About it. In this mode, there are arbitrage situations at bar open prices because bar open prices are not synchronised. But there is no arbitrage on bar close prices (almost, Ask close price is modelled), because they are synchronised.
And if you go from the open price spread to the average (the maximum, at a guess, should suffocate arbitrage), arbitrage on the open prices appears yet because of the inaccurate Ask price of the bar opening.
About it. In this mode, there are arbitrage situations on the bar opening prices because the bar opening prices are not synchronized. On the other hand, there is no arbitrage at bar closing prices because they are synchronized.
Do Sleep (say 1000) and look at the adjacent character. The bar is likely to be open.
Expectation of synchronization of neighbouring bars in the open prices mode is the same as in the Potik mode
It's easy to get slapped in the face with multicurrency. For example, you test a multi-currency, get MO = $2. And then it turns out that a significant part of this MO is just imaginary because of the unsynchronized simulated ticks and unsynchronized history itself - the opening price. And the more symbols are involved at the same time, the greater will be the effect of asynchronization. In this case the tester will always show the situation better than it was on the real account.
Only your own calculator will help. The tester's multicurrency is formally, but its adequacy is greatly exaggerated.
With the expectation of $2 and blatant pipsing of this kind, you can only cheat yourself.
It is clear that trying to catch tick divergence looks like an easier way to trade, but in practice on the retail forex will not work in the long run.
Do Sleep(say 1000) and look at the adjacent symbol. The bar is likely to be open.
A bar can be open at 00:00:01, but it can also be open at 00:00:20 - especially at night.
But even if after a second of waiting the bar will be available, the open prices will not become synchronized - the tester will show that EURUSD and GBPUSD had such and such prices simultaneously, while the real prices were in fact completely different. And it's not because of ticks modelling, but because of the fact that the opening price doesn't correspond to the price of the opening minute, or even the first seconds of that minute.
With an expectation of $2 and blatant pipsing of this kind, you can only fool yourself.
Why are you throwing around words? Low MO is not pipsing, it's just an average trade outcome. For example, you have TP = 100, SL = 100 - obviously, it's not a Pips? However, the MO may be close to zero. I will even say more, if you open and close positions randomly at all (which is also not exactly scalping), your MO will be equal to minus spread. At the same time, if you reverse all trades of your strategy, MO will not change - again, it will remain equal to minus spread.
Clearly, trying to catch tick divergence looks like an easier way to trade, but in practice on retail forex will not work in any length of time.
To catch (to trade in profit) tick divergences in real time on retail-FOREX is quite a solvable task at the moment. Obviously, you are not aware of the achievements of aggregation, which are already available to a common user. I'm not theorising with you, I'm speaking as a practitioner.
Once again, we are back to our bar, namely the frequency generator.
The bar should open at the time specified in the bar opening, and not with the arrival of a new tick, which will require a synchronizer with zero real volume and a flipper price.
Suddenly all questions about bar synchronization are removed.