Errors, bugs, questions - page 524
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
Besides, as far as I understood, closing of a trade by a stop loss is related to a losing trade in the result report of the tester (where the percentage of losing and profitable trades is located)
After upgrading to Build 507, I'm having two problems in the tester:
1. During optimisation when switching tester tabs, the terminal occasionally (not always) crashes;
2. If an enumeration was selected as an optimized parameter, then when trying to run one of the optimization results, the Expert Advisor does not see the value of this enumeration, i.e. it always equals to zero.
After upgrading to Build 507, I'm having two problems in the tester:
1. During optimisation when switching tester tabs, the terminal occasionally (not always) crashes;
2. If an enumeration was selected as an optimized parameter, then when trying to launch one of the optimization results, the Expert Advisor does not see the value of this enumeration, i.e. it always equals zero.
Please write to servicedesk with as many details as possible.
We know there is a problem with enumerations during optimization, but we can't reproduce the error in any way
I have written to servicedesk...
I have accepted your application and asked follow-up questions
...And here the question arises (rhetorical?)...
There are repeated additional calculations of the same values in the indicator, which of course give the same results. The solution seems to be obvious: to calculate once (when accessing historical data for the first time), put everything in the buffer and in other cases apply to the ready results. But...
The indicator has an already enormous number of buffers (at least 10 for storing the calculated data of the entire history on several different timeframes) - they are already being accessed with the corresponding initially calculated data. Now, in idea and as an option, there is a need to double the number of buffers.
Of course, this all depends on the hardware specifications: processor's processing power and the amount of memory. And that's who's going to win. But let's take the hardware as very average - not the latest home PC. Not too much of either, and not too little. It is difficult to decide right away whether to throw away memory or computational power.
So the question to a knowledgeable public: what do you recommend? Maybe there will be some arguments for one or another option... Either don't clutter up the memory by doubling calculated indicator buffers, and warm the processor, calculating the same thing every time you need it, or vice versa?
Thank you.
...Which begs the question (rhetorical?)...
...Of course, everything rests on the technical parameters of the hardware: the processing power of the processor and the amount of RAM. And that's who's going to win. But let's consider hardware to be rather average - not a recent home PC. Not too much of either, and not too little. It's hard to decide right away whether to throw away memory or computing power.
...
...And here the question arises (rhetorical?)...
There are repeated additional calculations of the same values in the indicator, which of course give the same results. The solution seems to be obvious: to calculate once (when accessing historical data for the first time), put everything in the buffer and in other cases apply to the ready results. But...
The indicator has an already enormous number of buffers (at least 10 for storing the calculated data of the entire history on several different timeframes) - they are already being accessed with the corresponding initially calculated data. Now, in idea and as an option, there is a need to double the number of buffers.
Of course, this all depends on the hardware specifications: processor's processing power and the amount of memory. And that's who's going to win. But let's take the hardware as very average - not the latest home PC. Not too much of either, and not too little. It is difficult to decide right away whether to throw away memory or computational power.
So the question to a knowledgeable public: what do you recommend? Maybe there will be some arguments for one or another option... Either don't clutter up the memory by doubling calculated indicator buffers, and warm the processor, calculating the same thing every time you need it, or vice versa?
Thank you.
Alternatively, why not use databases for your needs? Calculated, recorded... time has come - extracted in the most convenient form, use it.
Architecturally, the solution allows you to separate calculation and caching of results.
Alternatively, why not use databases for your needs? Calculated, recorded... it's time - extracted in the most convenient form, use it.
Architecturally, the solution allows you to separate calculation and caching of results.
I don't deny it, but the phrase "it's time" sounds funny, given that each reference will be replayed in OnCalculate at every tick. Either the DB has to lie entirely in RAM, or you'd have to slowly access the disk and shovel it to ashes. Although... what do I understand about DBMS...
However, isn't MQL a query language for DB? If so, it's already working with the database from the disk and the disk seems to be alive for now. There is no need to invent anything new here.
If you meant a different database and a specific (non-standard) way to access it, please explain. If you suggested to integrate MQL5 interaction with something else, it's too early for me, as I just started studying MLQ and am moving towards advanced kindling...
Very often the connection to the server is disconnected. However, the indicator shows a stable connection:
The terminal does not reconnect. I have to login manually. Is it possible to do this programmatically using MQL5?