MT5/mql5 reported and confirmed bugs. - page 3

You are missing trading opportunities:
- Free trading apps
- Free Forex VPS for 24 hours
- 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
Build 3180 but this is not specific to this build, it's an old one.
On indicators, MT5 can set automatically a level "0" depending of the buffer values. There is no way to disable this behaviour or to customize the level line drawing.
Forum on trading, automated trading systems and testing trading strategies
Custom Indicator showing ZERO level, though not defined anywhere in the code
Alain Verleyen, 2022.01.27 17:56
Actually it's buggy, as this automatic 0 line doesn't respect what is defined in the code (style, color...).
Bug in MQL string() function. Wrong conversion of double -> string
Build 3182 but this is not specific to this build, it's an old one.
A bug is found in string() function where wrong conversion of double -> string.
If you convert an arbitrary double-precision floating-point number to a decimal string, and then convert that back to floating-point, you should recover the original floating-point number. In other words, the conversion will round-trip.
The string() function may return wrong string representation of double numbers that cannot round-trip into the same numeric value.
This also affects any implicit cast inside Print(), Alert(), Comment(), FileWrite().
This a sample script to reproduce the bug:
If you convert an arbitrary double-precision floating-point number to a decimal string, and then convert that back to floating-point, you should recover the original floating-point number. In other words, the conversion will round-trip.
This is an incorrect statement. The following expression is not an identity.
Bug in MQL string() function. Wrong conversion of double -> string
Build 3182 but this is not specific to this build, it's an old one.
A bug is found in string() function where wrong conversion of double -> string.
If you convert an arbitrary double-precision floating-point number to a decimal string, and then convert that back to floating-point, you should recover the original floating-point number. In other words, the conversion will round-trip.
The string() function may return wrong string representation of double numbers that cannot round-trip into the same numeric value.
This also affects any implicit cast inside Print(), Alert(), Comment(), FileWrite().
This a sample script to reproduce the bug:
Build 3182 but this is not specific to this build, it's an old one. A bug is found in string() function where wrong conversion of double -> string.
If you convert an arbitrary double-precision floating-point number to a decimal string, and then convert that back to floating-point, you should recover the original floating-point number. In other words, the conversion will round-trip.
The string() function may return wrong string representation of double numbers that cannot round-trip into the same numeric value. This also affects any implicit cast inside Print(), Alert(), Comment(), FileWrite().
This a sample script to reproduce the bug:
The maximum precision that DoubleToString supports is 16 digits, but a double has much more than that. So there is no guarantee the the round-trip conversion will return to the original. Also, given that some numbers can actually have a recurring pattern after the decimal point, there will never be a string conversion that can guarantee a round-trip conversion to the original.
So, it's not a bug but a simple limitation of the conversion function between something that is represented in base 2 and another that a representation of base 10.
This is an incorrect statement. The following expression is not an identity.
In JavaScript: Number.toString() --> round-trips
In Python: Repr() --> round-trips
In C #: Double.ToString("R") --> round-trips
In C: printf("%.17g", str) --> round-trips
Recently, this identity became a rule that should be fulfilled in major programming languages, as a trade-off between readibility and correctness.
I posted before Repr() function which adopts a shortest round-trip conversion, with similar results to David M. Gay's dtoa.c library (Dragon4).
How to Print Floating-Point Numbers Accurately (1990) https://lists.nongnu.org/archive/html/gcl-devel/2012-10/pdfkieTlklRzN.pdf
Test this in mql
Then test the same example in your browser js pad or any online javascript pad and check the difference.
In JavaScript: Number.toString() --> round-trips
In Python: Repr() --> round-trips
In C #: Double.ToString("R") --> round-trips
In C: printf("%.17g", str) --> round-trips
Recently, this identity became a rule that should be fulfilled in major programming languages, as a trade-off between readibility and correctness.
I posted before Repr() function which adopts a shortest round-trip conversion, with similar results to David M. Gay's dtoa.c library (Dragon4).
Please pay attention to what was stated. The MQL5 function has a limitation of 16 digits, but a double has more precision. Round-trip is not guaranteed.
Even in the other languages with more precision, there are still numbers that will fail if they have a repeating pattern when converted from binary to decimal.
https://en.wikipedia.org/wiki/Floating-point_arithmetic
Binary-to-decimal conversion with minimal number of digits
Converting a double-precision binary floating-point number to a decimal string is a common operation,
MQL5 implements a bad historic algorithm for conversion double -> str. That is why the forum is full of questions about floating point numbers weirdness.
Here is a proof of my point of view that it is as bug in the implementaion