Errors, bugs, questions - page 2160
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
From MQ's point of view, apparently correctly. As always, decided for us what is more convenient.
Forum on trading, automated trading systems and testing trading strategies
There are no messages in the profile.
Renat Fatkhullin, 2018.03.08 10:31
Removed temporarily to reduce the amount of functionality working in compatibility mode.
We'll add new features as soon as the migration process is complete.
This is a new very large and feature rich system.
New chat rooms are being introduced.
From MQ's point of view, apparently correctly. As always, decided for us how to be more comfortable.
Moving on to the level of telepathic... )))))
Unclear bug in the main indicator. Appears only on timeframes below H1, and only at terminal startup. Text of error "S-v5 (EURUSD,M10) array out of range in 'S-v5.mq5' (211,54)" . Drawing is correct, but in reverse order, though time series flag is set for all buffers.
The composition of the template - the main indicator (#1) (where the error occurs), additional indicator (#2) (combination of several handles of the main indicator with different parameters (timeframe), indicator (#3) that displays arrows in the main chart on the signals from the indicator #1), indicator (#4) that displays arrows in the main chart on the signals from the indicator #2.
Switching timeframe, re-application of the template, if you remove any 2 indicators from 2 to 4 or only at number 1, the output of a new symbol from the market overview and application of this template - the error is not reproduced and rendering of all indicators is correct.
Compilation error
The error message does not allow the cause to be understood in the extensive code
below is clear
No error message
moreover, it is running and there is even a result (!)
In this variant:
no jump to the error line (by Enter)
Compilation error
In an attempt to speed things up when I was creating this example, I ran into one oddity completely by accident, which I just put on the shelf.
And now, when I tried to deal with this oddity, I got even more confused.
So, in the calculation I use the square root function sqrt(), which I decided to bypass by creating a double array.
Since I always take the square root from integers, creating an array looks like this:
It is logical to suppose that reading from the array SQRT[x] is faster than using the sqrt(x) function.
And this is confirmed by the check code:
the result shows a speed gain of ~1.5 times:
But when I replace the sqrt() function in the code with reading the array elements SQRT[], instead of speeding up, I get terrible lags.
Reading an item from the SQRT[] array takes many times, perhaps even an order of magnitude longer than running sqrt().
And I don't understand where speed leak occurs. The check code above tells you otherwise.
We can suppose that the compiler accesses a large array in some strange way and seems to "forget" about it at each loop turn and performs its own service indexing each time.
But this is either a logical or a strategic compiler bug. And you should obviously do something about it because this speed leak is very significant and difficult to detect because it's not so obvious.
I am attaching the script code to demonstrate this oddity.
The default run (arr=false) calculates sqrt(), but when you change arr to true, the square root value is taken from the array.
WHAT'S WRONG? WHY IS IT SLOW?
In an attempt to speed things up, when creating this example, I ran into one oddity completely by accident, which I just shelved.
It is logical to assume that reading from the array SQRT[x] is faster than taking sqrt(x).
From a dynamic array, it's not a fact.
Moreover, taking of the root is already in place at the level of SQRTSD processor's command. That is, you cannot beat the processor's implementation using the notorious cost of access in a dynamic array.
And this is confirmed by the verification code:
the result shows a speed gain of ~1.5 times:
I doubt that it is confirmed.
The code of this kind is like something out of a textbook on loop optimization. The code optimizer might make a sweet out of it because it is a very simple case:
That is, the performance measurement in the case of application of the deliberately perfectly optimised cases needs to be clearly related to the goals of the test.
The test in this case is wrong.
And I don't understand where the speed leakage occurs. After all, the above test code says otherwise.
Without seeing the final assembler code, I'm leaning towards:
Let's check the entire code carefully. It is interesting to find out what is the real reason.
From a dynamic array, not a fact.
Without seeing the final assembler code, I'm leaning towards:
Tried a static array - same thing.
As fast as sqrt is, I find it hard to believe that this function can be 10 times faster than just reading an array element.
Moreover, if in my example the canvas size is reduced, say 50x50 (there is an input parameter Size for this, you need to set 50 instead of 0),
and the array will be much smaller (5000 elements), the speed picture changes dramatically. There is no such a strong contrast anymore.
But I don't understand: does the array's size affect the speed of accessing its items?
Perhaps you are right about the simplicity of the check code.
I tried to make it a bit more complicated and the result is completely different: