Errors, bugs, questions - page 2360
![MQL5 - Language of trade strategies built-in the MetaTrader 5 client terminal](https://c.mql5.com/i/registerlandings/logo-2.png)
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
Error for developers.
The script does not compile, identify why))). Use attached file.
Same file:
All compiles, remove Error line
Everything compiles, delete line Error
line length limitation in the editor
Limiting the length of a line in the editor
A string is not displayed when it becomes longer than 4095 characters.
Please explain to a fool why this is the case here?
Suppose we can only operate on odd numbers, and if the result of an arithmetic operation becomes an even number, it is assumed to be the nearest odd number above, then
33 != 31
I spent several hours on searching for divergences. I found this
The peculiarities double know, but not such that if you change the order of addition (except for the relatively very different numbers), the result is different! Please explain to a fool why this happens here?
You only need to look at the bottom two lines in the source.
As you yourself like to say, the agolithm that is laid down for the accuracy of rounding double to the same number at the limit of the specified accuracy is "crooked". The reason, obviously, is that the same value obtained by different methods (swapping multipliers, opening parentheses, etc.) in double representation can turn out to be different numbers, maximally close to the desired one from different sides. Round up to the next digit, and then you decide how to deal with the last one...
When you do size+point, you overflow the mantissa followed by rounding/rejection (depending on fpu mode.
In general, the result of two doublets will be the same only if they are obtained in the same way (unless you count cases where we are dealing with integers).
Thanks for the answers, each one was valuable. For the first time I encountered (noticed) that adding the same items to the PRICE, but in different sequence creates different PRICES. Hence different results in the Tester.
When discussing dubs, it was clear when and why they could be compared to each other. But the price plus points and different output result is the first time the TC result has been so clearly affected.
It turns out that to avoid these ambiguities, we need to add a mizzen less than half a point to the calculated price, and then normalise.
It turns out that in order to avoid these ambiguities, we need to add to the calculated price a mere fraction less than half a point, and then normalise.
And there is also an opinion that if the results of TC change a lot from such insignificant things, you should say "thank you" and throw such TC in the trash.
Thanks for the replies, each one was valuable. First encountered (noticed) that adding the same items to a PRICE, but in a different sequence creates different PRICES. Hence different results in the Tester.
When discussing dubs, it was clear when and why they could be compared to each other. But the price plus points and different output result is the first time the TC result has been so clearly affected.
It turns out that to avoid these ambiguities, we need to add a mizzen less than half a point to the calculated price, and then normalise.
Maybe it is worth mapping in the features?
And there is also the opinion that if the results of a TC change a lot from such small things, you should say "thank you" and throw such a TC in the trash.
They don't change much, they just change. That's enough to start an investigation.