Jian Chen #: I'm not sure but I did a simple test. The NormalizeDouble function should be working. Output: 2022.01.30 20:30:28.360MyTest1 (EURUSD,H1)Normalize double test: 0.2999999 = 0.30
You are using DoubleToString to the same number of digits, which cancels out any possible "bug" that NormalizeDouble may or may not have. Your test does not serve as a satisfactory evaluation of the situation.
Dark Ryd3r #: I confirm NormalizeDouble does not work and its an official bug and must be reported to ServiceDesk
It's not an issue with the NormalizeDouble, it's just an UI issue. The current UI is showing what doubles actually are, they have always been imprecise, it's just that before the update, the UI would not show the actual value.
All programmers should know how to deal with double/float imprecision, but when it comes to user experience, the previous behavior of the UI was ideal.
So it seems, that NormalizeDouble is in fact flawed in some way in this new build.
The only flaw is the fact that the function still exists, instead of pointing people to articles teaching about floating point, it promises something impossible with them that is to round it to specific numbers. Some numbers just can't be represented.
Alexandre Borela #: The only flaw is the fact that the function still exists, instead of pointing people to articles teaching about floating point, it promises something impossible with them that is to round it to specific numbers. Some numbers just can't be represented.
Yes, I am well aware of the downfall of using the function, and I have on many threads advocated NEVER using it. I am merely posting my results in order to help second those users that wish to request MetaQuotes to restore the previous functionality of the function and the display of parameters in the properties panel.
One more test to see if the normalising function has changed or not with the following script:
union LongDouble
{
long long_value;
double double_value;
};
voidOnStart()
{
double dbValue = 0.2999999, dbNormalised = NormalizeDouble( dbValue, 2 );
LongDouble ldNormalised;
ldNormalised.double_value = dbNormalised;
Print( "MT Build: ", __MQLBUILD__, ", Normalised Value as a Long: ", ldNormalised.long_value );
};
2022.01.3013:56:53.638 TestNormalize (EURUSD,H1) MT Build: 3164, Normalised Value as a Long: 45990759394707505152022.01.3013:57:59.295 TestNormalize (EURUSD,H1) MT Build: 3180, Normalised Value as a Long: 4599075939470750515
It seems to be working as before. The only difference seems to be the default display of the numbers and not the underlying data.
Alexandre Borela #: It's not an issue with the NormalizeDouble, it's just an UI issue. The current UI is showing what doubles actually are, they have always been imprecise, it's just that before the update, the UI would not show the actual value.
All programmers should know how to deal with double/float imprecision, but when it comes to user experience, the previous behavior of the UI was ideal.
Dark Ryd3r #: My EA Stopped sending orders due to this bug, so i explored and found this. Its an issue with NormalizeDouble which output can be seen
No, NormalizeDouble seems to be working just as before with no change. It seems to be only a "display" problem. See my previous posts here on the thread, especially Post #17.
I confirm NormalizeDouble does not work and its an official bug and must be reported to ServiceDesk
they have always been imprecise, it's just that before the update, the UI would not show the actual value.
All programmers should know how to deal with double/float imprecision, but when it comes to user experience, the
previous behavior of the UI was ideal.
Here are my results with the following script:
So it seems, that functionality in both the display and the NormalizeDouble has changed in some way in this new build.
EDIT: See later posts!
Here are my results with the following script:
So it seems, that NormalizeDouble is in fact flawed in some way in this new build.
The only flaw is the fact that the function still exists, instead of pointing people to articles teaching about floating point,
In both your examples, the double's value is actually ~0.299999999... the print function is what rounded the value.it promises something impossible with them that is to round it to specific numbers. Some numbers just can't be represented.
https://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html
https://floating-point-gui.de/
Metaquotes should deprecate it, as this function causes confusion to beginners everyday.
Here is a more thorough test with the following script:
From the above, it seems that it is more of only a default display problem and that NormalizeDouble is still working as before.One more test to see if the normalising function has changed or not with the following script:
It seems to be working as before. The only difference seems to be the default display of the numbers and not the underlying data.
I'm not sure but I did a simple test. The NormalizeDouble function should be working.
Output:
2022.01.30 20:30:28.360 MyTest1 (EURUSD,H1) Normalize double test: 0.2999999 = 0.30
try this
It's not an issue with the NormalizeDouble, it's just an UI issue. The current UI is showing what doubles actually are,
they have always been imprecise, it's just that before the update, the UI would not show the actual value.
All programmers should know how to deal with double/float imprecision, but when it comes to user experience, the
previous behavior of the UI was ideal.
No, NormalizeDouble seems to be working just as before with no change. It seems to be only a "display" problem. See my previous posts here on the thread, especially Post #17.