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

[fxsaber]

amrali #:

Good explanation and examples.

[amrali]

fxsaber #:

Good explanation and examples.

This may be off-topic, but to show how other programming language display floating point numbers. Many of them use the shortest-round trip string representation (binary double -> string conversion),

because:

1. it is mathematically correct (i.e., round-tripping to the exact binary value, according to IEEE 754 semantics). 

2. It is shorter, so more easy for users to understand.

These are screenshots of code snippets in python, javascript  and java.

And, the links to the online compilers:

https://www.programiz.com/python-programming/online-compiler/

https://www.programiz.com/javascript/online-compiler/

https://www.programiz.com/java-programming/online-compiler/

[Alexey Petrov]

This not a bug, but feature to show the 'real'/longest representation of a double value. If you want to see the short representation, put the mouse cursor over it - it will be shown in a tooltip.

It's not planned to be changed at the moment.

[fxsaber]

Alexey Petrov #:

This not a bug, but feature to show the 'real'/longest representation of a double value. If you want to see the short representation, put the mouse cursor over it - it will be shown in a tooltip.

If I call a spade a spade, then this is an incompetent answer.

[amrali]

Alexey Petrov #:

This not a bug, but feature to show the 'real'/longest representation of a double value. If you want to see the short representation, put the mouse cursor over it - it will be shown in a tooltip.

It's not planned to be changed at the moment.

You have a good point of view to display numbers in 17 significant figures. But, I see it adds zero extra information as both string repr. are correct. Also, the tooltip for 0.30000000000000044 (0.3) is wrong. They are not equal.

Edit:

this is a screenshot of Visual studio 2022

[Ilyas]

amrali #:

You have a good point of view to display numbers in 17 significant figures. But, I see it adds zero extra information as both string repr. are correct. Also, the tooltip for 0.30000000000000044 (0.3) is wrong. They are not equal.

Edit:

this is a screenshot of Visual studio 2022

This means that the first number is accurate and the second cannot be represented exactly.
In general, digits at the end of the second have no significance and indicate the inaccuracy of the number

0.3 can be represented only as number which little bit greater than 0.3

[amrali]

Ilyas #:

This means that the first number is accurate and the second cannot be represented exactly.
In general, digits at the end of the second have no significance and indicate the inaccuracy of the number

0.3 can be represented only as number which little bit greater than 0.3

Hello Ilyas

The Visual studio debugger means that the first number is rounded without a tiny round-off error (i.e., rounded to the closest binary approximation to the real value 0.3, with a representation error less than a half epsilon.).

The second number has a roundoff error as a result of arithmetic floating point addition (different from the correct real result by >= 1 epsilon).

Using round-tripping on the output from the debugger to check for accuracy of the displayed strings:

StringToDouble("0.3") == 0.3;                                       // true

StringToDouble("0.30000000000000004") == 0.1 + 0.2;  // true

This reflects the fact that:

Console.WriteLine(0.3 == 0.1 + 0.2) => false as the two quantities are different in floating-point arithmetic.

So, the the strings displayed by the debugger watch window are the shortest precise strings and they reflect that difference.

Edit:

What this means for users when adopting the shortest round-trip strings? 

If a string has many significant digits > expected digits of the result, then this indicates that a roundoff error has occurred (due to any arithmetic floating point operation: + - * /, log, etc).

For example, if the shortest string displayed for a takeprofit price calculated as Ask price + some distance contains digits at the end (> symbol digits), then this warns the programmer that rounding (to digits/ticksize) is needed to chop the roundoff error due to fp addition.

[fxsaber]

void OnStart()
{  
  double x1 = 0.299999999999999962;
  double x2 = 0.3;
  double x3 = 0.300000000000000016;
  
  Print(x1 == x3); // true
  
  double y1 = 0.300000000000000017;
  double y2 = 0.1 + 0.2;
  double y3 = 0.300000000000000072;

  Print(y1 == y3); // true
  
  Print(x3 == y1); // false
  
  DebugBreak();
}

Debugger shows average value: (x1+x3)/2, (y1+y3)/2. And should show it: x2,  (y1+y3)/2

[amrali]

Yes, as because too many close "real" numbers are encoded to the same "floating-point" number, we can call them an equivalence group. Numbers within the same group are equal (same bits), and numbers from two different groups are not equal (different binaries).

What is related to the topic, if I give you a binary value, which string will you choose to display the value (binary -> string conversion). 

fxsaber, do not you feel that mql debugger confuse you? Although the numbers are very precise to 17 sig digits, but you cannot cope with that. You need something else shorter and also correct. Using Print() to get the shortest strings will be convenient than using the debugger.

[fxsaber]

amrali #:

Yes, as because too many close "real" numbers are encoded to the same "floating-point" number, we can call them an equivalence group. Numbers within the same group are equal (same bits), and numbers from two different groups are not equal (different binaries).

What is related to the topic, if I give you a binary value, which one will you choose to display that binary value (binary -> string conversion). 

fxsaber, do not you feel that mql debugger confuse you?

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.