By the way, about zero, FastLog2 doesn't check for zero, which gives it a head start. But it's still 1.5-2 times slower than log2 if tested correctly).
2019.01.0504:43:12.372 TestLog (EURUSD,H1) Result log2: sum=1400005128 time=297 ms
2019.01.0504:43:12.635 TestLog (EURUSD,H1) Result log2_: sum=1400018381 time=262 ms
2019.01.0504:43:12.809 TestLog (EURUSD,H1) Result _FastLog2: sum=1400004095 time=174 ms
By the way, about zero, FastLog2 doesn't check for zero, which gives it a head start. But it's still 1.5-2 times slower than log2, if tested correctly).
Of course, we should remove zero check from log2 or add the same one to FastLog2.
The question is really about the speed of the computational part. In log2, everything is calculated purely by shifts and additions. FastLog2 uses table values after clever conversions involving multiplication. This code is very old, it was used back in the days of math coprocessors, the situation may well have changed since then.
Checked it in C++. Yes, FastLog2 is indeed the fastest. Clever code, though ) Perhaps the reason is that bitwise operations are much faster than comparison operations.
I have tested all the codes in MT4. In MT4 the compiler does not perform any optimization (i.e. the variant with sum shows the same relative results as my original variant without sum), and in MT4 log2 runs faster than FastLog2. And in MT5 optimization is already performed without summing (i.e. the code apparently is not executed completely), and FastLog2 variant is faster than log2. What conclusions can be drawn from this I don't know, because there are no details about how the code optimizer works there and there.
This is the standard behavior of MQL5: static variables start after global variables.
Is that why every static variable of a class/structure has to be declared after the structure itself? And even without assigning any value to it... Maybe we should suggest that the compiler does all this automatically?
This is essentially a bug, an incorrect sequence of program code execution. The compiler should not allow this in principle. You should yell at the developers more often about this.
In C++ code is processed by the compiler strictly from top to bottom, so everything from above is already initialized. And you cannot access the code below. That's why everything is clear. And since the developers introduced their own rules here, let them provide the correct order of code execution.
In C++, code is processed by the compiler strictly from top to bottom, so anything on top is already initialized. And you can't access the bottom one. That's why everything is clear.
Allow the use of cookies to log in to the MQL5.com website.
Please enable the necessary setting in your browser, otherwise you will not be able to log in.
You are signed in. Two-factor authentication has been disabled. Set it up again and scan a new QR code, or continue with two-factor authentication disabled.
By the way, about zero, FastLog2 doesn't check for zero, which gives it a head start. But it's still 1.5-2 times slower than log2 if tested correctly).
And what is incorrect about it?
Because even your version of the test produces:
By the way, about zero, FastLog2 doesn't check for zero, which gives it a head start. But it's still 1.5-2 times slower than log2, if tested correctly).
Of course, we should remove zero check from log2 or add the same one to FastLog2.
The question is really about the speed of the computational part. In log2, everything is calculated purely by shifts and additions. FastLog2 uses table values after clever conversions involving multiplication. This code is very old, it was used back in the days of math coprocessors, the situation may well have changed since then.
This is standard MQL5 behaviour: static variables come after global variables.
You can get very seriously messed up because of this.This is the standard behavior of MQL5: static variables start after global variables.
Is that why every static variable of a class/structure has to be declared after the structure itself? And even without assigning any value to it... Maybe we should suggest that the compiler does all this automatically?
This is essentially a bug, an incorrect sequence of program code execution. The compiler should not allow this in principle. You should yell at the developers more often about this.
In C++ code is processed by the compiler strictly from top to bottom, so everything from above is already initialized. And you cannot access the code below. That's why everything is clear. And since the developers introduced their own rules here, let them provide the correct order of code execution.
In C++, code is processed by the compiler strictly from top to bottom, so anything on top is already initialized. And you can't access the bottom one. That's why everything is clear.
There is less flexibility.