Organising the order cycle - page 3
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
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 valuable cargo from point A to point B. You need to monitor the route.
What would you prefer: to have communication 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.
Thanks for the association, but it doesn't seem to amount to trade logic. The issue seems to be fundamental and touches on very different principles of TC construction.
The only way to avoid this situation would be to use asynchronous orders.
Otherwise there would still be a loop on the list of commands to be executed, which is essentially 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 the orders sent out of the queue would be obsolete.
Thanks for the association, but it does not seem to amount to trade logic. The question seems to be fundamental and touches on completely different principles of TC construction.
I am willing to listen to your association. Yes, the question is fundamental.
I disagree. A queue with delayed execution of commands already gives asynchrony. We are not looking at a new environment in the command loop. Indeed, there can only be one command in the queue to modify a particular order.
Requesting a new environment, in general, takes a minimum of time. The lion's share is spent waiting for a response from the server.
You can delegate command execution to another (or even several other) EA, but it will still be sequential command execution. I don't think the result will be any different from the built in order cycle.
Ready to listen to your association. Yes, the question is fundamental.
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), yours is heard.
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 so that in the real world 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.
Still haven't heard why, in your opinion, when working with the first order in the list, the results will be closer to the tester (we are still discussing a system with multiple orders).
Still haven't heard why you think the results will be closer to the tester when working with the first order in the list (still discussing a multi-order system).
And this is almost postulated rather than proven, unfortunately. As is your option.
Yes, no need to twist my approach somewhat, it's not about the first order, it's about restarting the whole TS after any pause.
And this is almost postulated rather than proven, unfortunately. Neither is your option.
Yes, no need to twist my approach somewhat, it's not about the first order, it's about restarting the whole TS after any pause.
I agree, working with only the first order will only work in certain circumstances.
I think the discussion has exhausted itself.
I think the discussion has exhausted itself.
Yes, thank you. The way the discussion was conducted was very different from the parallel ones...
Requesting a new environment generally takes a minimum of time. The lion's share is spent waiting for a response from the server.
You can delegate command execution to another (or even several other) EA, but it will still be sequential command execution. I don't think the result will be any different from the built-in loop on orders.
It's not about time, it's about logic (about time - that's in another thread ;-) ). Your logic (and my logic, since I agree with everything, including the auto analogy) is to do environment analysis "in one fell swoop and in one piece", rather than piecemeal. Processing any side effects is postponed until the next run, because these effects will be built into the new trading environment.
Another EA is out of the question. Everything can be done in one. And of course, the result will be equivalent to a cycle. Just then the code will be logically more understandable and actually prove our logic.
Another EA is out of the question. Everything can be done in one. And of course, the result will be equivalent to a loop. It's just that then the code will be logically clearer and actually prove our logic.
We are waiting for an OOP-example. And I still see it 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 on the decisions we have already made.