Bug in MetaEditor Build 3566: Wrong display of double floating point numbers in the debugger window - page 3

New comment
 
fxsaber #:

I have to think every time which "short" number is in the equivalence group.

For example, it is not clear to me which of these numbers is greater or less than 0.3.

Displaying strings at maximum accuracy (17 s.f) for doubles hurts, because the format cannot represent real numbers very accurately. So, a shortest precise string hides those tiny representation errors from the user, and at the same time preserves the accuracy (roundtrip string -> double). 

 
We have a financial application that receives prices in decimal notation. Therefore, it is wrong when the terminal received a "short" price, and the debugger shows its "long" equivalent.

It is clear that the "short" and "long" representations are the same number. But at the entrance to the financial program from other market participants, it was precisely the "short" form that was delivered, as the initial form of filling in by a person who thinks in the decimal number system.
 
fxsaber #:
We have a financial application that receives prices in decimal notation. Therefore, it is wrong when the terminal received a "short" price, and the debugger shows its "long" equivalent.

It is clear that the "short" and "long" representations are the same number. But at the entrance to the financial program from other market participants, it was precisely the "short" form that was delivered, as the initial form of filling in by a person who thinks in the decimal number system.

Even for the experienced programmers!

That is why Microsoft debugger adopted the shortest form, although the longest 17 significant digits (%.17g) is extremely accurate.
 
amrali #:

although the longest 17 significant digits (%.17g) is extremely accurate.

They are not accurate, because are equal to (min+max)/2 of their equivalence group.

 

Display the binary value, do not get confused by the debugger output. This is a side effect of the %.17g display. You can re-test with Print().

DoubleToHexadecimal()
 
In general, there were enough arguments in favor of the fact that the debugger should show the "shortest" number from its equivalence group, and not the average.
 
fxsaber #:
In general, there were enough arguments in favor of the fact that the debugger should show the "shortest" number from its equivalence group, and not the average.

Yes it is the average: as equivalence group extends from representable floating point number +/- half epsilon on both directions. The representable fp number lies in the middle of the group.

I am facing the same resistance for change :-) like the first time I reported the bug in string conversion before. Now, the display of doubles from Print(), string(), Alert(), FileWrite() and dialogue boxes are fixed.

I will not add more to this post.

Thanks fxsaber!

 
amrali #:

Thanks fxsaber!

I am also grateful to you, because You proved me wrong in the first place.

 
The forum is a good place to exchange our ideas. I am also learning from your codes.
  
#property strict

#define TOSTRING(A) #A + " = " + (string)(A) + " "

#define DIGITS 2
#define FIRST_DIGIT 1

void OnStart()
{
  for (int i = (int)MathPow(10, DIGITS) - 1; i >= 0; i--)
  {
    const double Num = (double)((string)(FIRST_DIGIT) + "." + IntegerToString(i, DIGITS, '0'));
    
    if (Num != NormalizeDouble(Num, DIGITS))
      Print(TOSTRING(Num) + TOSTRING(NormalizeDouble(Num, DIGITS)));
  }
  
  Print(1.14 == NormalizeDouble(1.14, 2)); // MT5-false, MT4-true.
}
12345
New comment