Errors, bugs, questions - page 1998
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
This is the argument I didn't understand (when it was put forward by MQ) and I don't understand it now. Initialization is not going anywhere. Now it is entrusted to the application programmer and he does it anyway, but as practice shows, sometimes with errors. If it were done by a kernel, the performance would not be affected and there would be no errors.
For example, let's take an array of indicator buffer: when initializing the indicator, the buffer has a zero length. What is there to initialize with zeros? When another index is added, is it forced to be zeroed and then filled in with some value? What is this zeroing or filling with EMPTY_VALUE for? And if there is a need to assign PLOT_EMPTY_VALUE and not 0 or EMPTY_VALUE or to force one, but we need another... No matter how you slice it, you end up wasting your time...
And a custom array... The array is declared for some data different from zero and EMPTY_VALUE. So why should it be forcibly initialized with something?
So it turns out that it affects the performance in most cases.
But a custom array... The array is declared for some data other than zero and EMPTY_VALUE. So what's the purpose of forcefully initializing it with something?
To have less "tester's results don't match".
To make it less "tester results don't match".
Who needs it?
Write an article that says in every paragraph that you shouldn't order EAs from just anyone. You have to write your EAs correctly.
Who needs it?
Me and, I'm pretty sure, the developers.
To me and, I'm pretty sure, to the developers.
I doubt very much that such a trifle would put you in a bind. Either that or there's another reason.
I doubt very much that such a trivial thing can stump you. Either the reason is something else.
Even if I wrote perfectly (without making mistakes - which is not the case), it is normal to take someone's library (sometimes without source code - in the Marketplace) and use it, hoping that it is written competently. And there is no insurance that after that you will run into different results in the tester. And finding the real cause will be VERY difficult. And fixing it is sometimes impossible.
The goal is that from run to run the result is reproducible - identical, even with an error.
Probably the ideal solution would be to force initialisation for all programs by default + a compile switch to disable it (for those who are confident and want to speed up a couple of percent).
Initialization really takes a lot of resources. I threw out a piece of code with forced initialization and got almost 2 times faster in optimization)
And I stumbled upon an interesting thing. How is it possible that the drawdown is 120% and at the same time the result is in the top and plus?
When I test the strategy I get a drawdown of 109% and no margin call, while the balance keeps growing.Initialization really takes a lot of resources. I threw out a piece of code with forced initialization - it accelerated in optimization by almost 2 times)
Something you wrote incorrectly.
Full initialisation is not always necessary. For example, for an indicator that fills the buffer value for each bar in the loop (and does it regardless of whether the indicator buffer is initialized or not).
In this case it will be more economical without forced zeroing.
And why make up such unrealistic scenarios, in fact MQL programmer's mistakes? Obviously, full initialization is done only once, or when data pumping is detected. In this case, it would be more efficiently done by the kernel.