Caratteristiche del linguaggio mql4, sottigliezze e tecniche - pagina 6

[fxsaber]

fxsaber:
A differenza di MQL5, in MQL4 gli array statici possono cambiare dimensione.

Non sempre

Forum sul trading, sistemi di trading automatico e test di strategie di trading

Nuova versione della piattaforma MetaTrader 5 build 1595: accesso alla storia dei prezzi

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]

C'è sempre stato un bug in MT4 nel Trailing Stop. Se si guarda durante un forte movimento di prezzo verso l'alto e verso il basso,
si può vedere lo SL che si muove su e giù. Qui ha catturato un piccolo movimento, accade molte volte più grande
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
L'ho ottenuto quando SL = 2 (ultima cifra per semplicità), nel tick successivo il prezzo è salito e il terminale ha dato un ordine di aumentare SL a 4.
Al tick successivo è sceso ma lo SL è ancora a 2. Il terminale emette un ordine per portare SL a 3.
Il server, come una giraffa dal collo lungo, elaborò il primo ordine e portò SL a 4. Il server ha elaborato il secondo ordine e ha diminuito SL a 3.
Quindi, il terminale invia ordini extra senza senso e questo aumenta il carico sul server.
Inoltre, c'è il rischio di perdite inutili per il trader a causa del movimento inverso di SL.
Questo vale anche per il programma seguito da EA o script . In parte lo correggiamo spostando lo SL a passi di 3...5 pip.

Cosa fare. Salvataggio del valore di SL, emesso nell'ultimo OrderModify.
E poi calcolare l'ordine successivo in base a questo valore.
Sarebbe così: due ordini in meno al server, spostando SL solo in avanti, riducendo il carico della CPU del computer
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]

Quando si modificano gli ordini, è spesso necessario confrontare il TP/SL precedente con il nuovo valore da modificare. Se proviamo a modificarlo con il vecchio valore, otterremo l'errore #1.

Prendiamo l'esempio di confrontare il vecchio SL (100,03) e il nuovo SL (100,02) per USDJPY (Cifre = 2). È scritto nell'aiuto:

Il secondo metodo consiste nel confrontare la differenza normalizzata di due numeri reali con un valore zero. Confrontare la differenza di numeri normalizzati con lo zero è inutile, poiché come risultato di qualsiasi operazione matematica con numeri normalizzati il risultato non è normalizzato.

Cioè, il confronto deve essere fatto in questo modo:

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

Ma a volte il broker può dare prezzi non normalizzati. E per esempio, abbiamo il prezzo 100,025, non 100,02. Avendo confrontato secondo lo schema di cui sopra, otterremo la differenza di 0,01, cioè possiamo modificarla. Ma avendo passato per la modifica normalizzata a Digits 100.025, in realtà passeremo 100.03 e di conseguenza otterremo l'errore #1.

In generale, per esperienza finora sono giunto alla conclusione che a cifre uguali per le modifiche è meglioconfrontare la differenza dei numeri normalizzati con lo zero (ciò che l'aiuto non raccomanda di fare).

Script da controllare:

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:

Sì, si può fare. Questo è il primo modo di confronto dato nell'aiuto. Stavo solo sottolineando la trappola della normalizzazione dei numeri reali in cui io stesso sono caduto, usando il secondo metodo raccomandato nella documentazione.

[Artyom Trishkin]

I commenti non pertinenti a questo argomento sono stati spostati in "Organizzazione del ciclo dell'ordine".

[fxsaber]

A differenza di OrderProfit() in MT4 OrderCommission() memorizza i dati non arrotondati ai centesimi.

SZZ In OrderPrint() la commissione è arrotondata (come nella GUI).

[Artyom Trishkin]

fxsaber:

A differenza di OrderProfit() in MT4 OrderCommission() memorizza i dati non arrotondati ai centesimi.

SZZ In OrderPrint() la commissione è arrotondata (come nella GUI).

Quindi, cosa devo fare per ottenere il valore corretto di OrderProfit()+OrderComission()+OrderSwap()?

[fxsaber]

Artyom Trishkin:

Di conseguenza, per ottenere il valore corretto di OrderProfit()+OrderComission()+OrderSwap(), cosa bisogna fare?

Niente! Questo è il valore più corretto. A causa di questa commissione, possiamo vedere nella GUI che la commissione totale differisce di un centesimo dalla somma dei numeri mostrati dalla GUI.

[Artyom Trishkin]

fxsaber:

Niente! Questo è il valore più corretto. Grazie a questa commissione, si può osservare nella GUI che la commissione totale differisce di un centesimo dalla somma dei numeri che la GUI mostra.

Allora non lo capisco affatto. Cosa intendi per "OrderCommission() memorizza i dati non arrotondati ai centesimi"? Dove sono arrotondati? E come sono arrotondati?