Organising the order cycle - page 4

New comment
 
fxsaber:

It will not be, as it is not strong.


First, the TS is written for the tester, where the trading conditions are ideal. If all is well, then they try to write the live version in such a way that it is as close as possible to what they see in the tester. Any other approaches to writing the TS are the hit-or-miss, not the algorithmization of the idea.

So here is the fundamental question, what is the closest combat situation to a tester? I voiced my opinion (and gave an example), I heard yours.

I face the task of translating the trading logic of an Expert Advisor from tick-testing in the strategy tester (MT4) to its work on a real account.

My reasoning:

In the tester, the Expert Advisor works not only in ideal trading conditions, but actually in another mode - in real time, i.e. it has time to calculate TS, and send an order and get its answer in a single tick, but it is not so in real trading. It appears that we have sort of two different robots - one of real time and one of no time. If we send/modify an order (even one!) to a real account = ping + execution time, etc. = at best 100-500ms, and during this time ticks go and they need to be counted - and we stand, wait... and then we get into the flow at random (where the price has gone during this time relative to our tick averages we don't know. + we must have missed some of the fastest and usually most important ticks). So, as a result, there may be nothing left of the strategy we executed in the tester.

Therefore, on reflection, I have come to the following:

  1. In the battle mode, the trading logic in the Expert Advisor is disabled, and it works, in fact, as a follower.
  2. The trading system is moved into the indicator and it generates opening and closing commands, and it is not waiting for the expert to execute these commands, but simply executes the TS it has in ideal conditions, almost like in the tester. As far as I know the indicator must not skip ticks, although I doubt it is technically possible - but at least it must skip them less than the Expert Advisor where this possibility was initially described in its documentation. + Even at the expense of separation of errors of calculation of TC should be less, because there are no interruptions to all sorts of secondary operations in relation to the logic of TC.
 
zenz:

So, on reflection, I have come to the following:

  1. In the battle mode the trading logic in the Expert Advisor is disabled and it works, in fact, as a copy machine.
  2. The trading system is moved into the indicator and it generates opening and closing commands, and it is not waiting for these commands to be executed by the Expert Advisor but simply executes the TS in ideal conditions, almost like in a tester. As far as I know the indicator must not skip ticks, although I doubt it is technically possible - but at least it must skip them less than the Expert Advisor where this possibility was initially described in its documentation. + Even at the expense of separation of errors in TC calculation should be less, because there are no interruptions to all sorts of secondary to the logic of TC operations.

Yes, I use the same approach - a kind of internal ideal tester with its own open orders and a copier which tries to materialize those virtual orders. This scheme bypasses a lot of serious problems very easily.


In MT5 it is easier because we can request the tick history there. And you can request it for several symbols.

 
Stanislav Korotky:

It's not about time, it's about logic (about time - that's in another thread ;-) ). Your logic (and my logic, as I agree with everything, including the car analogy) is to do the environment analysis "in one go and in one piece", rather than piecemeal. The processing of any side-effects is postponed until the next run, as these effects will be built into the new trading environment.

Well, if there was no time correction, then both logics (mine and fxsaber's) would be identical - all orders would be processed on every tick even after several errors.

The goal is precisely to approximate the reality with non instant execution to the ideal model obtained in testing.

 
fxsaber:

Yes, I use the same approach - a kind of internal ideal tester with its open orders and a copier that tries to materialize those virtual orders.

If you materialise with your approach (in a loop, staying on the first order until it successfully synchronises with reality), you may run into the same problem of the remaining orders being lost from view (or simply being processed later). But this is about the same, allegedly completed, topic).

 
Andrey Khatimlianskii:

If you materialise with your approach (in a loop, staying on the first order until it successfully synchronises with reality), you may run into the same problem of the remaining orders being lost from view (or simply being processed later). But this is about the same question that supposedly has been solved).

This is how we trade!

 
fxsaber:

We are waiting for an OOP example. And I still see it as the same backbone in the form of a loop. The logic will not change because first it will be for to determine what must be changed, and then for for on the decisions we have already made.

I will not write an example specifically for this task. But you may see a simplified concept of the approach in my blog. There the queue is not analyzed in depth but only checked for emptiness. Those who wish may improve it.

If by logic we mean the task "to modify a pile of orders due to changing prices", there is only one task. The question is what is more important: to modify all orders or modify them to fit the latest prices? Depending on your preferences, the logic will be different. A simple loop would guarantee that all orders are modified, and I am in favour of this option. As has already been said, the OOP provides a clear division of the task into responsibility blocks, and based on this decomposition, "all orders" is more important than "price relevance". This is clear even from the fact that prices change all the time, and orders are only there occasionally. They are more important.

 
Stanislav Korotky:

The PLO provides clarity in dividing the task into blocks of responsibility, and based on this decomposition "all orders" are more important than "price relevance"

Based on this decomposition, only the division follows. "Price relevance" in this PLO is achieved by setting a place in the queue.
 
fxsaber:
Based on this decomposition, only separation follows. "Price relevance" under this OOP is achieved by setting a place in the queue.

This is a bit of a "philosophy" now. The processing is by order queue and not by tick flow as suggested in the alternative. Anyway, I am withdrawing from this discussion. All arguments have already been made.

 
Stanislav Korotky:

Anyway, I am withdrawing from this discussion. All arguments have already been made.

There is already a tendency to end it that way.

 
fxsaber:

Below we will be touching on a subject which not only concerns MT4, but also MT5 with other platforms. But the logic will be written in MQL4 for easy perception, so in this branch.

Most often the backbone (the meat of any order) of order modification/deletion comes down to the following logic

Now, the approach is rare, but much more correct

After sending a trade order, the trade environment changes, so it is advisable to execute the entire trading logic of the TS from scratch immediately after the trade server responds.

Looping is one of the most dangerous programming tricks. It causes strange, rarely occurring errors, which are almost impossible to analyze.

Instead of looping, you should on the contrary try to finish the user thread as quickly as possible. If you want to keep your hand on the pulse - analyze OnTradeTransaction in MT5. MT4 is generally not suitable for such loops, because simplicity is, as they say, worse than theft.

1234567891011...15
New comment