I decided the most precise solution as is already common practise would be comparing the integer values of price as those are deterministic to computer. The threshold value for tick should also be an integer and you will use that at your discretion (whether it should be median value, whether you want to round up or down etc.). You only have to compare the prices up to the digit after the minimum tick size as William pointed and cut out the rest which are not meaningful as they don't represent values the instrument, per its specification should trade at.
double price1=1.0043278006;
double price2=1.0043224;
//round threshold for decimal systemint threshold=5;
/*int32 word size should be capable of handling mantissa of 5 decimal accuracy(which seems to be max
for instruments) for faster calc, but free to use long if this is not case*/int price1_precise=(int)MathFloor(price1*MathPow(10,_Digits+1));
int price2_precise=(int)MathFloor(price2*MathPow(10,_Digits+1));
//Anything more than or equal to 5 is tick in this casebool price_delta_is_tick=MathAbs(price1_precise-price2_precise)>=threshold;
PrintFormat("Result of %d minus %d is %d which is a tick? %s",
price1_precise,price2_precise,
price1_precise-price2_precise,
(string)(price_delta_is_tick));
//=========================================================//Result of 1004327 minus 1004322 is 5 which is a tick? true
William Roeder #: except with zero never compare doubles for equality
if (a > b)
if (a - b > Point / 2.)
if (a >= b)
if (a - b > -Point)
if (a != b)
if (MathAbs(a - b) > Point / 2.)
The fact that this old post kept going for 8 pages after William posted his solution is a bit odd. If there's anything wrong with this please let me know because that's the method I'm currently using every time I compare doubles.
IMHO, MQL has __,no concept__ of (fixed maximum/minimum) real number's significant digits built-in the programming language, as commonly known and familiar to most programmers using most other programming language.
Therefore it is easily to make calculation and logic comparisson errors (BUGs).
Thus, __always__ use NormalizeDouble() and double check your codes' expexted result.
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. (MT42013)) (MT52022))
Vladislav Boyko #: Does this mean that the expression (!_greater(a, b)) is equivalent to _lessOrEqualWay1(a, b) and is equivalent to _lessOrEqualWay2(a, b)?
It seems that from a mathematical point of view this is not true.
a 0.00810000, b 0.00510000, x 0.00300000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00840000, b 0.00540000, x 0.00300000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00870000, b 0.00570000, x 0.00300000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00900000, b 0.00600000, x 0.00300000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00930000, b 0.00630000, x 0.00300000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00960000, b 0.00660000, x 0.00300000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00990000, b 0.00690000, x 0.00300000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.01020000, b 0.00720000, x 0.00300000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.01050000, b 0.00750000, x 0.00300000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.01080000, b 0.00780000, x 0.00300000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
---
a 0.00099000, b 0.00009000, x 0.00090000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00108000, b 0.00018000, x 0.00090000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00198000, b 0.00108000, x 0.00090000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
---
a 0.00027000, b 0.00000000, x 0.00027000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00029700, b 0.00002700, x 0.00027000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00032400, b 0.00005400, x 0.00027000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00054000, b 0.00027000, x 0.00027000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00056700, b 0.00029700, x 0.00027000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00059400, b 0.00032400, x 0.00027000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00062100, b 0.00035100, x 0.00027000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00064800, b 0.00037800, x 0.00027000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00067500, b 0.00040500, x 0.00027000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00070200, b 0.00043200, x 0.00027000, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
---
x = 0.00008100: No such values found in the given range.
---
a 0.00003888, b 0.00001458, x 0.00002430, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
a 0.00004131, b 0.00001701, x 0.00002430, lessOrEqualWay1 false, lessOrEqualWay2 false, notGreater true
---
Combinations analyzed: 1847338041
#define _lessOrEqualWay1(a, b) ((a) - (b) < x)
#define _lessOrEqualWay2(a, b) ((b) - (a) > -x)
#define _greater(a, b) ((a) - (b) > x)
#define _notGreater(a, b) (!_greater(a, b))
#define _toStr(a) (a) ? "true" : "false"long combinations = 0;
voidOnStart()
{
double X = 0.01;
for(int i = 0; i < 5; i++)
{
X *= 0.3;
findValues(X);
Print("---");
}
Print("Combinations analyzed: ", combinations);
}
void findValues(double x) {
int numOfPrints = 0;
double step = x / 10.0;
for (double a = 0.0; a <= 0.1; a += step) {
for (double b = 0.0; b <= 0.1; b += step) {
combinations++;
bool lessOrEqualWay1 = _lessOrEqualWay1(a, b);
bool lessOrEqualWay2 = _lessOrEqualWay2(a, b);
bool notGreater = _notGreater(a, b);
if (lessOrEqualWay1 != lessOrEqualWay2 || lessOrEqualWay2 != notGreater) {
PrintFormat("a %.8f, b %.8f, x %.8f, lessOrEqualWay1 %s, lessOrEqualWay2 %s, notGreater %s",
a, b, x, _toStr(lessOrEqualWay1), _toStr(lessOrEqualWay2), _toStr(notGreater));
numOfPrints++;
if(numOfPrints > 9)
return;
}
}
}
if(numOfPrints < 1)
PrintFormat("x = %.8f: No such values found in the given range.", x);
}
I decided the most precise solution as is already common practise would be comparing the integer values of price as those are deterministic to computer. The threshold value for tick should also be an integer and you will use that at your discretion (whether it should be median value, whether you want to round up or down etc.). You only have to compare the prices up to the digit after the minimum tick size as William pointed and cut out the rest which are not meaningful as they don't represent values the instrument, per its specification should trade at.
except with zero never compare doubles for equality
if (a > b)if (a >= b)if (a != b)The fact that this old post kept going for 8 pages after William posted his solution is a bit odd. If there's anything wrong with this please let me know because that's the method I'm currently using every time I compare doubles.
NormalizeDouble, It's use is usually wrong.
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)
Print out your values to the precision you want with DoubleToString - Conversion Functions - MQL4 Reference.
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)
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)
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))
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)
Prices you get from the terminal are already correct (normalized).
PIP, Point, or Tick are all different in general.
What is a TICK? - MQL4 programming forum (2014)
@William Roeder, is the following correct?
I use half the tick size instead of half the point. A variable named "halfTickSize" is declared in the code where these macros are used.
'_lessOrEqual' I came up with myself, but I see that my way is different from what is here:
Forum on trading, automated trading systems and testing trading strategies
Can price != price ?
Roel, 2014.07.29 10:09
case LTE: return(b-a>-Point/2.);I still can’t logically prove to myself that my method and the method from the post I quoted are equivalent
is the following correct
This is how I tested my method and everything seems to be correct
If these expressions are equivalent (for <=):
Then the expression for >= can also be written in two ways:
But it looks like I need some sleep😄If '>' can be expressed like this:
#define _greater(a, b) ((a) - (b) > x)And '<=' can be expressed like this:
Does this mean that the expression (!_greater(a, b)) is equivalent to _lessOrEqualWay1(a, b) and is equivalent to _lessOrEqualWay2(a, b)?
[EDIT]
This question can be answered using school mathematics, I just forgot this part of mathematics a little. Is there anyone here who knows school math?
Does this mean that the expression (!_greater(a, b)) is equivalent to _lessOrEqualWay1(a, b) and is equivalent to _lessOrEqualWay2(a, b)?
It seems that from a mathematical point of view this is not true.