Features of the mql4 language, subtleties and techniques - page 6

[fxsaber]

fxsaber:
Unlike MQL5, in MQL4 static arrays can change size.

Not always

Forum on trading, automated trading systems and trading strategy testing

New version of MetaTrader 5 build 1595 platform: access to price history

fxsaber, 2017.05.01 16:36

#property strict

template <typename T>
struct ARRAY
{
  T Simple[100];
};

void OnStart()
{
  int ArraySimple[100];
  ARRAY<int> Array;

  Print(ArrayResize(Array.Simple, 10)); // MQL4: -1
  Print(ArrayResize(ArraySimple, 10));  // MQL4: 10
  
  Print(ArraySize(ArraySimple));        // MQL4: 10
  Print(ArraySize(Array.Simple));       // MQL4: 100
}

[Konstantin Erin]

There has always been a Trailing Stop bug in MT4. If you watch during a strong up and down price movement,
you can see the SL moving up and down. Here caught a small movement, happens many times bigger
2017.05.22 10:53:38.563 '9898616': trailing stop #1465775202 -> 1.29765
2017.05.22 10:53:38.483'9898616': trailing stop #1465775202 -> 1.29764
2017.05.22 10:53:33.236'9898616': trailing stop #1465775202 -> 1.29763
2017.05.22 10:53:33.130'9898616': trailing stop #1465775202 -> 1.29764
2017.05.22 10:53:32.813 '9898616': trailing stop #1465775202 -> 1.29762
Got it when SL = 2 (last digit for simplicity), on the next tick the price went up and the terminal gave an order to raise SL to 4.
On the next tick it went down but SL is still at 2. The terminal issues an order to raise SL to 3.
The server, like a giraffe with a long neck, processed the first order and raised SL to 4. The server processed the second order and decreased SL to 3.
So, the terminal sends extra meaningless orders and it increases the load on the server.
In addition, there is the risk of unnecessary loss for the trader because of SL's reverse movement.
This also applies to program trailing by EA or script . Partly we correct it by moving SL in steps of 3...5 pips.

What to do. Saving the value of SL, issued in the last OrderModify.
And then calculate the next order based on this value.
It would be like this: two less orders to server, moving SL only forward, reducing computer CPU load
2017.05.22 10:53:38.563 '9898616': trailing stop #1465775202 -> 1.29765
2017.05.22 10:53:33.130 '9898616': trailing stop #1465775202 -> 1.29764
2017.05.22 10:53:32.813 '9898616': trailing stop #1465775202 -> 1.29762

[Vasiliy Pushkaryov]

When modifying orders, it is often necessary to compare the previous TP/SL with the new value to be modified. If we try to modify it with the old value, we will get error #1.

Let us take the example of comparing the old SL (100.03) and the new SL(100.02) for USDJPY (Digits = 2). It is written in the help:

The second method involves comparing the normalized difference of two real numbers with a zero value. Comparing the difference of normalized numbers to zero is useless, since as a result of any mathematical operation with normalized numbers the result is non-normalized.

That is, the comparison must be made in this way:

if(NormalizeDouble(100.03 - 100.02, Digits) != 0) // можно модифицировать

But sometimes the broker can give non-normalized prices. And for example, we got the price 100.025, not 100.02. Having compared according to the above scheme, we will get the difference of 0.01, i.e. we can modify it. But having passed for modification normalized to Digits 100.025, we will actually pass 100.03 and accordingly we will get error #1.

In general, by experience so far I came to conclusion that at equal Digits for modifications it's betterto compare difference of normalized numbers with zero (what the help doesn't recommend to do).

Script to check:

void OnStart()
{
  double a = 0.02;
  double b = 0.015;
  
  Print(" norm1 dif=", ND(a - b));            // результат = 0.01
  Print(" norm2 dif=", ND(a) - ND(b));        // результат = 0.0
}

double ND(double d) {return NormalizeDouble(d, 2);}

[Yurij Kozhevnikov]

if(MathAbs(a-b)>=Point)

[Vasiliy Pushkaryov]

Yurij Kozhevnikov:

Yes, you can do that. This is the first way of comparison given in the help. I was just pointing out the real number normalisation trap that I myself fell into, using the second method recommended in the documentation.

[Artyom Trishkin]

Comments not relevant to this topic have been moved to "Organising the order cycle".

[fxsaber]

Unlike OrderProfit() in MT4 OrderCommission() stores data not rounded to cents.

SZZ In OrderPrint() the commission is rounded (as in GUI).

[Artyom Trishkin]

fxsaber:

Unlike OrderProfit() in MT4 OrderCommission() stores data not rounded to cents.

SZZ In OrderPrint() the commission is rounded (as in GUI).

Therefore, what should I do to obtain the correct value of OrderProfit()+OrderComission()+OrderSwap()?

[fxsaber]

Artyom Trishkin:

Accordingly, to get the correct value of OrderProfit()+OrderComission()+OrderSwap(), what should be done?

Nothing! This is the most correct value. Thanks to this commission, we can see in the GUI that the total commission differs by a cent from the sum of the numbers shown by the GUI.

[Artyom Trishkin]

fxsaber:

Nothing! This is the most correct value. Thanks to this commission, you can observe in the GUI that the total commission differs by a cent from the sum of the numbers the GUI shows.

Then I don't understand it at all. What do you mean by "OrderCommission() stores data not rounded to cents"? Where are they rounded? And how are they rounded?