Comparing prices

New comment
 

Hello,

I would like to warn the community about comparing prices.

Code like:

Close[n] < Close[n+2]

is not reliable and gives invisible differences for the logic from what you can tell, when using Digits to limit the number of displayed digits. I just found this out by going a bit crazy on code that evaluated "true" where it should be "false".

It turned out there is a difference in the 12th (!) decimal in case of "equal" prices, in my case .299999999490 and .299999999494

which gave "true" in the condition above, where I would have expected "false" by what is displayed with (5) Digits of course.

Very funny (bug/feature). 

 
flofri:

Hello,

I would like to warn the community about comparing prices.

Code like:

Close[n] < Close[n+2]

is not reliable and gives invisible differences for the logic from what you can tell, when using Digits to limit the number of displayed digits. I just found this out by going a bit crazy on code that evaluated "true" where it should be "false".

It turned out there is a difference in the 12th (!) decimal in case of "equal" prices, in my case .299999999490 and .299999999494

which gave "true" in the condition above, where I would have expected "false" by what is displayed with (5) Digits of course.

Very funny (bug/feature). 

That’s reality.  Displaying a value with decimal precision does not alter the actual value
 
Hello, instead use LT(Close[n], Close[n + 2]) to handle these issues.

 
flofri: It turned out there is a difference in the 12th (!) decimal in case of "equal" prices, in my case .299999999490 and .299999999494

  1. Floating point has an infinite number of decimals, it's you were not understanding floating point and that some numbers can't be represented exactly. (like 1/10.)
              Double-precision floating-point format - Wikipedia, the free encyclopedia

    See also The == operand. - MQL4 programming forum (2013)

  2. Print out your values to the precision you want with DoubleToString - Conversion Functions - MQL4 Reference.

  3. SL/TP (stops) need to be normalized to tick size (not Point) — code fails on non-currencies.
              On 5Digit Broker Stops are only allowed to be placed on full pip values. How to find out in mql? - MQL4 programming forum #10 (2011)

    And abide by the limits Requirements and Limitations in Making Trades - Appendixes - MQL4 Tutorial and that requires understanding floating point equality Can price != price ? - MQL4 programming forum (2012)

  4. Open price for pending orders need to be adjusted. On Currencies, Point == TickSize, so you will get the same answer, but it won't work on non-currencies. So do it right.
              Trailing Bar Entry EA - MQL4 programming forum (2013)
              Bid/Ask: (No Need) to use NormalizeDouble in OrderSend - MQL4 programming forum (2012)

  5. Lot size must also be adjusted to a multiple of LotStep and check against min and max. If that is not a power of 1/10 then NormalizeDouble is wrong. Do it right.
              (MT4 2013)) (MT5 2022))

  6. MathRound() and NormalizeDouble() are rounding in a different way. Make it explicit.
              MT4:NormalizeDouble - MQL5 programming forum (2017)
              How to Normalize - Expert Advisors and Automated Trading - MQL5 programming forum (2017)

  7. Prices (and lots) you get from the terminal are already correct (normalized).

  8. PIP, Point, or Tick are all different in general.
              What is a TICK? - MQL4 programming forum (2014)

 

Yes, I appreciate your formally correct answer, but... I only warned for the trap. These prices are of course not real (  .299999999490 and .299999999494) and this is unexpected behaviour.

Apart from the judgemental "it's you were not understanding floating point and that some numbers can't be represented exactly." (after university math and physics, and over 40 years of programming, therefore the solution was found in microseconds or less) that was not a question) -thanks anyway for the informative answer for the community.



William Roeder #:

  1. Floating point has an infinite number of decimals, it's you were not understanding floating point and that some numbers can't be represented exactly. (like 1/10.)
              Double-precision floating-point format - Wikipedia, the free encyclopedia

    See also The == operand. - MQL4 programming forum (2013)

  2. Print out your values to the precision you want with DoubleToString - Conversion Functions - MQL4 Reference.

  3. SL/TP (stops) need to be normalized to tick size (not Point) — code fails on non-currencies.
              On 5Digit Broker Stops are only allowed to be placed on full pip values. How to find out in mql? - MQL4 programming forum #10 (2011)

    And abide by the limits Requirements and Limitations in Making Trades - Appendixes - MQL4 Tutorial and that requires understanding floating point equality Can price != price ? - MQL4 programming forum (2012)

  4. Open price for pending orders need to be adjusted. On Currencies, Point == TickSize, so you will get the same answer, but it won't work on non-currencies. So do it right.
              Trailing Bar Entry EA - MQL4 programming forum (2013)
              Bid/Ask: (No Need) to use NormalizeDouble in OrderSend - MQL4 programming forum (2012)

  5. Lot size must also be adjusted to a multiple of LotStep and check against min and max. If that is not a power of 1/10 then NormalizeDouble is wrong. Do it right.
              (MT4 2013)) (MT5 2022))

  6. MathRound() and NormalizeDouble() are rounding in a different way. Make it explicit.
              MT4:NormalizeDouble - MQL5 programming forum (2017)
              How to Normalize - Expert Advisors and Automated Trading - MQL5 programming forum (2017)

  7. Prices (and lots) you get from the terminal are already correct (normalized).

  8. PIP, Point, or Tick are all different in general.
              What is a TICK? - MQL4 programming forum (2014)

 
amrali #:
Hello, instead use LT(Close[n], Close[n + 2]) to handle these issues.

Thanks, practical solution in most cases!
 
Paul Anscombe #:
That’s reality.  Displaying a value with decimal precision does not alter the actual value
the point is more that the listed prices appear to have a significant 12th digit where that is not the case.
 
flofri #:
Thanks, practical solution in most cases!
Yes in most case, I agree. Very tiny numbers that are very close to zero requires a special approach that is mostly not required for a trading robot. 

Edit:
For numbers close to zero AlmostEqual() is more precise as it compares numbers using epsilon.
New comment