Lot Step Epsilon Bug Demonstrator

Nearly every published lot-normalisation snippet floors volume/lotStep to find the largest whole number of steps, then multiplies back. That is exactly correct in decimal arithmetic, but wrong in binary floating point whenever the division "should" land precisely on a whole number and instead lands a fraction below it: 0.15 / 0.05 evaluates to 2.9999999999999996, not 3.0. MathFloor() of that is 2, not 3, so the naive pattern normalises 0.15 lots down to 0.10 - a third of the position silently gone, with no error, no warning, and nothing in the log to flag it, because MathFloor() and multiplication are both working exactly as documented. This is not a rare edge case picked to look dramatic. Any volume that is an exact multiple of the broker's lot step is a candidate, because that is precisely the case binary floating point represents worst - a value that "should" be a whole number lands a few ulps to one side of it, and which side depends on the specific decimal digits involved, not on how large or small the numbers are. The script runs four real volume/lotStep pairs through both a naive MathFloor implementation and a guarded one, printing the raw division result at 17 significant digits so the sub-step drift is visible: 0.15 lots at a 0.05 step (the headline case, a whole step lost); 0.29 lots at a 0.01 step (a very common broker step size, one classic case where 0.29 divided by 0.01 evaluates to 28.999999999999996); a matched pair that does not trigger the bug, so the guard can be seen agreeing with the naive version when nothing is wrong; and the live symbol's own real lot step against an input test volume. The guarded version adds a small epsilon before flooring, so a division binary arithmetic pushed just below a whole number lands back on it, then rounds the result to the lot step's own decimal precision to remove any residual floating-point noise the multiply-back step introduces. Notes and limitations - This is a read-only arithmetic demonstration - it sends no orders and needs no connected trading account. - The guarded function's decimal-place detection (how many digits to round the result to) is derived from the lot step value itself at runtime, capped at 8 iterations - broker lot steps finer than 8 decimal places are not expected and are not specifically handled. - Whether the live-symbol pair (using the broker's real lot step) actually reproduces the bug depends on that specific step value and the input test volume - the script reports honestly whether it did or did not for whichever pair was run, rather than assuming every broker's step value is affected. - Real trading code should also apply MODE_MINLOT and MODE_MAXLOT bounds after normalising to the lot step - this script isolates the flooring bug specifically and does not implement the full normalisation pipeline a live order-sizing function would need.

Script · MT5 · v1.0 · Free

Tags: Volume · Binary Options · Alerts · MT5 Script · MQL5 Source Code

MQL4 & MQL5 scripts · PolyMaria