Organising the order cycle - page 2
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
Because the price will move, and on each new call to OnTick, the condition for a new modification of the same, first in the list, order will be fulfilled. Especially if the modification will last 5 seconds ;)
Again, the question of relevance is touched on. One order will always be up-to-date. The others will be up to date. Your variant, on the other hand, is all orders not up to date.
Such a "backbone" would break the logic of an EA working with more than one order.
What would be the point in it if it would not give any advantage to systems with one order and would spoil the rest?
I'd love to understand what you mean, but I can't. I don't see the problem with the "if the wait time has passed, update the trading environment" principle.
Sorting by volume and/or distance from price before dealing with orders is the right thing to do. But we shouldn't assume that everyone who copies the code from the forum will implement it.
In that sense, my code is safer.
Well it wasn't written for newbies. You and I discuss it very well here - no water.
Again the issue of relevance is raised. One order will always be up to date. The others will be up to date if possible. Your option is that all orders are not up to date.
Actual - by how much?
Glad to understand what you mean, but it doesn't work. I don't see a problem with the "if the wait time has passed, update the trading environment" principle.
Your algorithm is fixated on the first order on the list, that's all.
In some situations this can be detrimental to the system (I have encountered it in practice).
Actual - by how much?
In my variant, both SLs would have been modified at 1.2375 or at the worst, at 1.2374. Bottom line: +30 pips on both orders.
At each step in your example the TS should know where its orders should be without any trade order. I.e. the TS cannot be attached in any way to where its orders are now. It only deals with calculating where they should stand and synchronizing the trading environment with what it has calculated through trade orders.
In your example, however, the result of the TS depends on whether OnTick has arrived at the high price or not. And the correct TS should be exactly up to that. She sees that such price was (even if the OnTick with it was missed), and therefore her SLs should be placed accordingly. And the synchronisation will do its job 100%.
And I don't understand why you keep saying that the second one is standing still. Even without synchronisation logic it will still be modified in the same way as in your variant. It's not like OnTick is called on the NewTick event, but as a normal internal function.
At each step in your example the TS needs to know where its orders should be without any trade order. That is, the TS can't be tied in any way to where the orders are now. It only deals with calculating where they should stand and synchronizing the trading environment with what it has calculated through trade orders.
It does, she knows. But it does not have time to synchronize it - while one modification is passing, the price moves further and a new calculated condition tells her to modify the first order again. And this happens all the time.
In your example, the result of TC depends on whether OnTick has come to the high price or not. And the correct TS should be exactly before that. She sees that such price was (even if the OnTick with it was missed), which means her SLs should be placed accordingly. And the synchronisation will do its job 100%.
It doesn't (in the example there was no SL level calculation).
And synchronisation won't do the job, as it won't have time (see above).
And I don't understand why you keep saying that the second one stands still. Even without synchronisation logic it will still be modified in the same way as in your variant. It's not like OnTick is called on the NewTick event, but as a normal internal function.
As usual, I understood it.
However, the price has already changed while modification was in progress and the forced call of OnTick already works with the new price, while the second order remains at the initial level.
There is no error. Perhaps too specific for you (but again, quite real, from life) situation.
It does, it knows. But it has no time to synchronise - while one modification passes, the price moves further, and the new calculated condition tells it to modify the first order again. And this happens all the time.
The example you have invented does not give us additional losses considering this logic. Now let me give you an example.
Suppose we trailing BuyLimits after the movement upwards in order to open at the necessary pullback. Almost Lucky-TC. If we drag a mountain of Limits every time, we won't catch a pullback with your option.
Well it's strange to give trade orders based on an outdated trading environment. But you stubbornly (like me) defend a different point of view.
Well it's strange to give trade orders based on an outdated trade environment. But you stubbornly (like me) defend a different point of view.
You have to choose the lesser of two evils.
Of course, the example with the limit stretching behind the price is better to implement in the "1 EA = 1 order in each direction" variant.
But in general it is better to keep all your orders under control.
But in general it is more correct to keep all your orders under control.
That is, you do not agree with the requirement for the TS to work only with the current trading environment.
That is, you disagree with the requirement for the TS to work only with the current trading environment.
If you have to sacrifice control of all the TC orders to do so - absolutely.
Imagine: you have a fleet of four trucks. Each of them is carrying valuable cargo from point A to point B. You need to monitor the route.
What would you prefer: to be in touch every minute with one of them, or every 2 minutes with all of them?
In the second case, the delay will be slightly longer, and all four may have to take a slight detour if you don't get them routed in time. But overall it will be better for the business than having one truck and losing the other three.
If you have to sacrifice control of all the TC orders to do so, absolutely.
Imagine: you have a fleet of 4 trucks. Each of them carries a valuable cargo from point A to point B. You need to control the route.
Would you rather be in touch every minute with one of them, or every 2 minutes with all of them?
In the second case, the delay will be slightly longer, and all four may have to make a slight detour if you fail to route them in time. But overall it will be better for business than spending one truck and losing the other three.
+1.
Perhaps the new idea wouldn't have arisen with the OOP approach, where a loop analogue with order brute force is hidden in some manager-like entity which, instead of calling OrderModify directly, generates a modify command (with all parameters) and puts it into a queue which is then processed. The idea is to divide the responsibility (which in this code is crammed into a single loop) between some entity analysing environment and an entity performing actions based on the analysis.
Perhaps this idea would not arise with OOP approach, when an analogue of loop with order search is hidden in some entity like manager, which instead of calling OrderModify directly generates command to modify (with all parameters) and puts it into a queue, which is then processed. The idea is to divide the responsibility (which in this code is crammed into a single loop) between an object of analysis of the environment and an object of carrying out actions based on the analysis.
The only way to avoid such a situation is to use asynchronous orders.
Otherwise there would still be a loop on the list of commands to be executed, which is, in fact, a loop on orders.
Only in a queue situation you would still have to make provisions to supersede an older unexecuted order relating to an order with a newer one. Otherwise the queue could overflow and orders would be sent out of the queue - obsolete.