New MetaTrader 5 Platform Build 5260: Enhancements in Algo Forge, extended OpenBLAS support, and new inheritance rules in MQL5 - page 8

New comment
 
@Dominik Egert #: May I ask, is this considered an error (on my side), a bug or now expected behaviour??
Your question is unclear. To what are you referring? Can you elaborate?
 
Fernando Carreiro #:
Your question is unclear. To what are you referring? Can you elaborate?
Sure, its about the variable name from the func-sig and the declaration in the local block.

They are the same, shouldn't that at least raise a warning?
 
Fernando Carreiro #:

Rodger all that; cept for the inference that you could not remove them or they couldnt be hidden or removed; as i have had them hidden/removed from almost as many years and builds that they were there. I have just forgotten how i did it, OR the ability i had was disabled in this latest build. I will keep searching. As i am sure that i still had the Ask and bid price showing at end of my tests, therefore changing the colours of these couldnt have been the way i hid them in the past.

 
Dominik Egert #:
Sure, its about the variable name from the func-sig and the declaration in the local block.

They are the same, shouldn't that at least raise a warning?
Why ? Different scope, it's all ok. It's like that since a very long time.
 
Alain Verleyen #:
Why ? Different scope, it's all ok. It's like that since a very long time.
So many details I currently miss. I was sure this was a warning before, but I guess it is only a warning in conjunction with global variables.
 
@Michael Charles Schefe #: Rodger all that; cept for the inference that you could not remove them or they couldnt be hidden or removed; as i have had them hidden/removed from almost as many years and builds that they were there. I have just forgotten how i did it, OR the ability i had was disabled in this latest build. I will keep searching. As i am sure that i still had the Ask and bid price showing at end of my tests, therefore changing the colours of these couldnt have been the way i hid them in the past.
I don't think that you "disabled" them. Rather I believe you were either using a different modelling, or the real tick data was mismatching the OHLC data and so the tester switched to "virtual ticks" and the lines disappeared.
 
Fernando Carreiro #:

EDIT: If you really want to hide them, then set the chart colours (F8) for the Ask price line and Bid price line to the "None", but I don't think that is very practical.

I now think that you are correct here; I think I had to have done just this, as you said: changed the colour of Bid and Ask to None, since I would have no reason to see these during a backtest.

Thanks for your "EDIT"(s). and NOTE: I only ever use real ticks mode.

 
Ilyas #:

Thank you for your message.

In the tooltip all integers type were interpreted as ulong.
I changed this behaviour, all integer type values will cast to the nearest unsigned type (special 1 bit integer type for bool) before output to the tooltip

Also for a double type values "%.16g" will be used instead of "%.15g" for the tooltip
The watchlist uses RYU for a double type values (IMHO it is fastest and precize algorithm)

Dear Ilyas,

I don’t think the watchlist is actually using RYU. In RYU’s implementation, you don’t manually specify "%.16g" or "%.15g" (see here ).

From what I see, the watchlist still relies on plain C printf() :

  1. "%.17g" for the displayed value in the watchlist

  2. "%.15g" for the tooltip


    The displayed values are always correct (though often longer than needed). The tooltip is shorter but sometimes wrong (BUG).

    RYU’s Dtoa() would automatically pick the shortest and correct format ( "%.15g" , "%.16g" , or "%.17g" ) to ensure round-tripping. If RYU were used, the tooltip would show 0.30000000000000004 , consistent with the Expert log output.

    I posted about this issue before, but it’s still unresolved. :(

    Edited:

    I suggest to use RYU for the displayed value. The tooltip will show the hex representation of double.

    Drachennest/src/ryu_64.h at master · abolz/Drachennest
    Drachennest/src/ryu_64.h at master · abolz/Drachennest
    • abolz
    • github.com
    Different algorithms for converting binary to decimal floating-point numbers - abolz/Drachennest
     
    amrali #:

    Dear Ilyas,

    I don’t think the watchlist is actually using RYU. In RYU’s implementation, you don’t manually specify "%.16g" or "%.15g" (see here ).

    From what I see, the watchlist still relies on plain C printf() :

    1. "%.17g" for the displayed value in the watchlist

    2. "%.15g" for the tooltip


      The displayed values are always correct (though often longer than needed). The tooltip is shorter but sometimes wrong (BUG).

      RYU’s Dtoa() would automatically pick the shortest and correct format ( "%.15g" , "%.16g" , or "%.17g" ) to ensure round-tripping. If RYU were used, the tooltip would show 0.30000000000000004 , consistent with the Expert log output.

      I posted about this issue before, but it’s still unresolved. :(

      Edited:

      I suggest to use RYU for the displayed value. The tooltip will show the hex representation of double.

      I do agree there is something unclear in Ilyas message (Watchlist is not using RYU, Ilyas probably confused Watch list and tooltip in his answer), though I think you are wrong to say the tooltip should be 0.30000000000000004, 0.3 is correct RYU value.

      The RYU algorithm is designed to find the shortest, correct decimal representation that, when converted back to a floating-point number, yields the original bit pattern.

       
      Alain Verleyen #:

      I do agree there is something unclear in Ilyas message (Watchlist is not using RYU, Ilyas probably confused Watch list and tooltip in his answer), though I think you are wrong to say the tooltip should be 0.30000000000000004, 0.3 is correct RYU value.

      Execuse me Alain, 0.30000000000000004 is the actual return value from RYU library. It is  consistent with the Expert log output.

      You can test yourself:

      void OnStart()
  {
   Print((0.1 + 0.2) == 0.3);                  // false (no round-trip)
   Print((0.1 + 0.2) == 0.30000000000000004);  // true (The shortest string, that round-trips)
   
   // verbose
   Print((0.1 + 0.2) == StringToDouble("0.3"));                  // false
   Print((0.1 + 0.2) == StringToDouble("0.30000000000000004"));  // true (shortest string that round-trips)
  }

      I don't have the souce code. Ilyas can confirm the issue.

      The RYU algorithm is designed to find the shortest, correct decimal representation that, when converted back to a floating-point number, yields the original bit pattern.

      Here, the shortest string may have 1,2,.. up to 17 significant digits. RYU only picks the shortest string that round-trips (when converted back to a floating-point ...)

      The MQL 5 Print() uses the RYU algorithm since build 3210.

      Debugger watchlist window / tooltip still do not. (rely on plain C wsprintf).


      12345678910
      New comment