Is the linear deceleration a programming error or a feature of MT4? - page 11
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
I'd really like to know who MetaQuotes is, can I take a message?
I took a quick look at the code. A passage from Lermontov's poem immediately came to mind:
Now to your question:
-Aleks-:
At the stage of strategy refinement, and especially tactics, you have to order all sorts of additions to test the idea, at this stage it is quite possible to tolerate the slowness of the Expert Advisor.
But I was surprised by such 6 times slower speed compared to the main version of the EA. Optimization ofEA tuning is necessary at least for analytical data gathering.
Do I understand correctly that it is impossible to read other people's code and it is better to order another version of the EA after we will get a successful one, but it must be written from scratch, and only in this case, we can be sure of high speed and reliability? Personally I think that compiler's part of the task is to cut out duplicate operations, for example...
I'm not talking about this code, but globally in general. So you refute this statement?If you order a programmer who write in the style of "horses and people mixed up" - you have to rewrite not twice or three times, but all the time and always at 100%, for all increasing budget. If you order from professionals, changing requirements by 20%, 40% or even 80% will not require rewriting code not only completely, but even on the same percentage as of the changes. But with a budget of "<$50" forget about it.
Am I correct in assuming that there should be an artificial delay when orders are sent to open orders, but without waiting for confirmation that they have opened?
Of course, the Expert Advisor should handle any order sending errors. In the simplest case - to display a message about the unsuccessful opening of the order. In the more advanced version, it will decide on further actions.
So I need an EA to replace me, and further actions are very relevant here... But it's not sure that they will be timely (for example, the price has already gone very far from the calculated entry point).
Didn't let it send. Ask the coder to use IsTradeContextBusy to check.
Thanks for the tip, but I was talking about these very nuances in the next thread. How would I know about it?
If you are using the 509 build, there are 8 threads there. The situation with IsTradeContextBusy should not occur.
If it does, see the point above.
You can also use more than one terminal.
I don't understand, does the number of terminals affect how an order is passed? I mean, we can launch several terminals for one and the same account and send an order to open an order from each terminal and if half of them slams down, the other half will execute the order successfully? I thought the order must be processed by the DC and only then accept the next one...
I had a quick look at the code. A passage from Lermontov's poem immediately came to mind:
Now to your question:
If you order a programmer who writes in the style "people and horses mixed up", you have to rewrite it not twice or thrice, but all the time and always at 100%, for the ever-increasing budget. If you order from professionals, changing requirements by 20%, 40% or even 80% will not require rewriting code not only completely, but even on the same percentage as of the changes. But with a budget of "<$50" forget about it.
Right now it's costing me more than $100 and I know I'll be adding more to it. The maths works out like this:
10 revisions at $30 gives you a cost of $300, while 10 at $50 gives you a cost of $500. Saving like $200 is significant for me. But when I'm happy with it, I will be able to order an EA from scratch (removing unnecessary things) and it will cost about $80. This approach justifies itself, especially when development is in progress. Except for the nerves you have to wear out... but that's as luck would have it.
You've got it wrong. There should not be any artificial delays. MT5 has a simple event model which should be used instead of sleep() delays
Thanks for the tip, but these are the nuances I discussed in the next thread. How should I know about them?
I do not need to go into them and look for something.
If someone hinted how it should be, and you find a lack of it in your code, you better change the coder silently. Do not create branches.
I don't understand, does the number of terminals affect how an order is passed? I.e. you can start several terminals on the same account and send an order to open an order from each of them, and if half of them get choked, the other half will execute the order successfully?
The number of terminals will be equal to the number of threads to be sent. 10 terminals will send 1 order - there will be 10 orders.
So I need an EA to replace me, so further actions are very relevant... but it's not sure that they will be timely (for example, the price has already gone very far from the calculated entry point).
At the moment the Expert Advisor costs me more than $100 and I know that I will be adding more. So that's the maths:10 revisions at $30 gives an expense of $300, while 10 at $50 gives an expense of $500. Saving like $200 is significant to me. But when I am satisfied with it, I will be able to order my Expert Advisor from scratch (removing unnecessary things) and it will cost $80. This approach justifies itself, especially when development is in progress. Except that you have to wear out your nerves... but it's a matter of luck.
This is the wrong approach on your part.
You order the code for the tester, warn about the importance of speed of optimization, make the necessary improvements in it. And only after the test version is ready, you order the real version with completely tested logic and all the modifications/recommendations.
You will save much more money. No?
You don't have to look into them and find out what's what.
If someone hinted how it should be, and you find a lack of it in the code - silently change the coder. Do not create branches.
the number of terminals - the same multiplicity of threads to send. 10 terminals will send 1 order - there will be 10 orders.
And what about the brokerage company? After all, it is the terminal that has a stuck order! What is the reason to send a multitude of orders then?
This is a wrong approach from your side.
You order the code for the tester, notifying it of the importance of the optimization speed, and introduce the necessary improvements in it. And only after the tester version is ready, order the real version with completely debugged logic and all the necessary modifications/recommendations.
You will save much more money. No?
Well, to start with, I didn't initially suggest that the speed of testing is very much dependent on the tester or real implementation.
And as for the rest, that's what I do, testing, refining ... or are you saying that the price will be many times less if I immediately write "I'm not for real, but testing"?
What about the DC? After all, it is him who has a stuck order!? What is the sense then to send a bunch of orders?
If you do not need to send a dozen orders all at once, then I do not insist.
You may send one by one from one terminal and wait for the context to become free and so on.
The whole dozen may be sent in a couple of minutes.
No, well, if you don't need a dozen at a time, then I don't insist.
You can send one at a time from one terminal, wait for the context to release, and so on.
You might be able to send a whole dozen in a couple of minutes.
So I'm asking, because I don't know how orders are processed by brokerage companies - in parallel or sequentially?
in parallel or sequentially?
Bids come in sequentially. but it's not certain that Buy will execute faster than the next sell, because there is sometimes another liquidity provider.
But to simplify the world - always think that it goes in series.
the only reason for this information is to stay on topic.