forex-scalping.com

Comparing prices in MQL without floating point surprises

A small coding issue that causes real bugs in EAs: comparing prices directly with == or even with > and <.

Prices are stored as double precision floating point numbers. A price that should be 1.08500 might be stored as 1.0849999999 or 1.0850000001. If your EA checks whether the bid equals your level, it might never be true. If it checks whether the bid is above the level, it might be true one tick too early or too late.

The usual fix is to normalise before comparing. NormalizeDouble(price, _Digits) rounds to the symbol's digits. Comparing two normalised values is much safer. Another approach is to compare the difference to half a point: if the absolute difference between two prices is less than _Point divided by two, treat them as equal.

The same applies to lot sizes. Your sizing calculation might come out to 0.2300000001 lots, and the broker will reject it if it isn't a multiple of the volume step. Round it down to SYMBOL_VOLUME_STEP, clamp it between minimum and maximum volume, and then send it.

Stops and targets need it too. Send a stop price with too many decimals and some brokers reject the order with invalid stops.

None of this is exciting. It's just the kind of thing that turns a good strategy into an EA that behaves strangely.

Pip and point confusion is a close cousin of this bug. On five digit pairs a point is a tenth of a pip, and on three digit yen pairs the same applies. Gold can be two or three digits depending on the broker. Hard coding a value like 0.0001 for a pip will work on EURUSD and break on USDJPY and gold. Calculate pip size from _Digits and _Point instead, and test the EA on at least one yen pair and gold before trusting it on everything. A helper function that returns pip size for any symbol is a few lines and can be reused in every EA you write.

Tick size is not always the same as point. On most FX symbols it is, but on some indices and metals the minimum price change is larger than one point. Sending a stop or limit at a price that isn't a multiple of the tick size can get rejected. SYMBOL_TRADE_TICK_SIZE gives you the right value, and rounding prices to it before sending removes a whole class of invalid price errors. It's easy to miss because EURUSD never shows the problem. Gold and index CFDs are where it usually shows up first, often on a broker you've just started using.

In Python backtests the same issue appears. Pandas and numpy use the same floating point doubles, so equality checks on prices can silently fail. Using numpy isclose with a tolerance of half a point, or rounding columns to the right number of decimals before comparing, avoids it. Another option is to store prices as integers in points. That's how many professional systems do it, and it removes the problem completely, at the cost of converting back when you display values for a human. Whichever route you take, use it everywhere in the code so comparisons behave the same way throughout the backtest.

Write a few small tests for the rounding functions on their own. Feed them awkward values like 0.0299999 lots, a stop price with seven decimals, a yen price, a gold price, and check the outputs by hand. Five minutes of this catches bugs that would otherwise only show up live as rejected orders at the worst moment. The MQL5 tester can run a script once with the results printed to the journal, which is enough for this kind of check. Keep those tests in the project so they run again whenever the sizing code changes.

Tick size versus point bites on JPY quotes and gold more often than on euro pairs. On many brokers XAUUSD has two decimals with a tick size of 0.01, but on some it is 0.05 or 0.1, and a stop calculated from a percentage of ATR lands on a price the server rejects. A small helper that does MathRound(price / tick) * tick and then NormalizeDouble with the symbol digits covers both cases. Running the EA once on a demo with each symbol you plan to trade usually catches these before they cause a missed trade.