Tester supporting MG4 scripts and advisors - page 10
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 didn't say that.
I haven't touched on this topic at all and don't plan to get involved.
Apparently, it seemed to me:
And the integrated stoplots and takeprofits are actually virtual and are thrown out for execution on the market when the time comes. This solution has a good side - it saves on CS (collateral, margin).
Think about what the new data access features provide and why this is the case.
MetaTrader 4 has limited depth of history, separate timeframes and direct access to the bars of its symbol via Open/High/Low/Close/Time[xxx]. Such direct access is very expensive to implement in terms of resources and CPU cost. Consider that each Expert Advisor has its own local copy of this data to avoid conflicts with other Expert Advisors and the terminal itself.
When the number of symbols grows (for example, in MT5 you can have 5 000-10 000 symbols), and using the deep one-minute history as the basis of all timeframes, it is no longer possible in principle to use the methods of MT4. There is not enough RAM, and copying large chunks kills performance. That's why MT5 no longer automatically maintains a hidden and expensive copy of the chart for each expert.
Instead we've moved to very economical CopyXXX functions where the developer exactly requests to the local array as much data as he needs, not the whole available chart. Then there is the fastest possible handling of local data (instead of the old rather expensive Open/High/Low/Close/Time[xxx]), plus the author can cache that data and use it sparingly on the next call. The memory and CPU savings are enormous. Additionally, the platform itself is particularly hands free to manage vast databases - access to them is always on demand (instead of unsupervised direct access) and this allows for flexible management of caches.
It should also be noted that the simplicity of Open/High/Low/Close/Time[xxx] calls in MQL4 was limited to the current symbol and timeframe, and all other data for other symbols and timeframes was obtained using iClose/iLow(...) functions, which caused serious delays. The transition in MQL5 to a single CopyXXX function model has radically improved the situation, allowing developers to obtain the required data chunks by one request, and not to make multiple blocked calls (think of all the blocks in each single call to iClose).
...
How about CopyXXX performance?
In terms of memory savings - no questions. But it is more expensive to call CopyXXX for each tick than to copy an array of quotes into a buffer once and access it by a direct index of Rates[X] type. Here we have a classical programming dilemma: "To save memory vs. to save CPU time".
No less than an MT5. Now address the same question to yourself, only replace a B with an A.
Go learn what the MARKET is! Trader, you know....
So you're saying that MT4 can, say, store spread history or "know" about real volumes (without all the crutches and other totally inadequate solutions)?
Do you agree that in the real market the spread is clearly not fixed? Go and in the MT4 tester try to test the EA on quotes with changing spreads, then we'll talk.
I don't care as much about the rest of the world as I do about the interests of the development of experts with complex logics. ;)
The compromise solution would be to organise virtual orders at the MT5 level. Then there would be both netting that someone needs and the old logic of working with orders.
Will you take the risks of such a "visualisation"?
In MT5, everyone who wanted to has long used the solution by hedging with trades on different instruments with a high degree of correlation.
Yes, this may require a lot more margin than in MT4, but common sense says it right.
Of course, no one has cancelled the "virtual" scheme in this case.
So you're saying that MT4 can, say, store spread history or "know" about real volumes (without all the crutches and other inadequate solutions)?
Do you agree that in the real market the spread is clearly not fixed? Go and in the MT4 tester try to test the EA on quotes with changing spreads, then we'll talk.
You will take the risks of such "visualization"?
In MT5, everyone who wanted to is using a hedging solution by using trades in different instruments with a high degree of correlation.
Thank God, there is MT4 for now. :) You may use it on one instrument if you wish. You may use different instruments.
What do you see as the risks?
What about the performance of CopyXXX?
In terms of memory saving - no questions. But it is more expensive to call CopyXXX for each tick than to copy an array of quotes into a buffer once and access it by a direct index of Rates[X] type. Here we have a classical programming dilemma: "To save memory vs. to save CPU time".
CopyXXX has the same speed as iClose/iOpen/iXXXX functions. Only iXXX returns one element at a time and CopyXXX returns many and thus is more efficient and faster.
Probably, you don't consider that MT4 forcibly copies _all_ history of the local chart into local (cache) EA's market environment before each tick handler start. And this is very expensive, although we have a method for economical updating of this information. The special function RefreshRates in MQL4 causes forced refreshing of caches and history of the local chart.
Calling CopyXXX is much more efficient, and the developers have a very precise and accurate mechanism of caching previously requested data. For example, you don't need to re-request deep history on every tick, but store/write it locally and access it as quickly as possible.
If we compare the old methods of "direct" (not actually direct access) access Open/High/Low/Close and work with local array double local[xxxx], the latter is many times faster. Therefore, it is better to copy to yourself locally and then have fast local access to repeatedly queried data.
Thank God there's an MT4 for now. :) With it, you can use one instrument at a time. You may use different instruments.
What do you see as the risks?
When developing/using "trading platforms" there are certain costs and risks, which someone eventually takes on.
As for "virtualisation" in software from other developers
This is a good thing, as long as everything is used for itself and the people implementing the solution understand what they are doing.
The main costs will be: money spent on developing the system, money spent on keeping it up and running and time spent on implementing the project.
The main risks: too much time or money will be spent to implement a viable project (the project will not pay off), the project will not be effective compared to other solutions, hidden errors in the code or algorithms will be introduced during project implementation.
Yes, banks and other market players resort to developing their software with the necessary functionality, but they spend a huge amount of time and resources. Meanwhile, they absolutely assume all the risks.
Concerning the work with MT5 (different variants using MT5)
Here of course MQ did most of the work, but also introduced certain restrictions on functionality.
The main costs will be: money spent to maintain the performance of the system and time spent on implementing the project.
The main risks: the project will not be efficient compared to other solutions, there will be hidden errors in the code or algorithms when implementing the project, you will have to constantly monitor the performance of the entire system (protect it from software and hardware problems; monitor communication quality, power supply, data security, etc.).
You can of course think of a commercial application (allowing other people to use it), with certain limitations and caveats.I'd like to take a look at
Here is an example where the simplicity and ease of use of OOP when writing simple programmes is particularly evident.