Discussione sull’articolo "Il Prototipo di Robot di Trading" - pagina 2

Nuovo commento
 

Si consiglia di evitare questo design 

//------------------------------------------------------------------ CheckNewBar
bool CExpertAdvisor::CheckNewBar()          // funzione di controllo della comparsa di una nuova barra
  {
   MqlRates rt[2];
   if(CopyRates(m_smb,m_tf,0,2,rt)!=2)      // copiare le barre
     { Print("CopyRates of ",m_smb," failed, no history"); return(false); }
   if(rt[1].tick_volume>1) return(false);   // controllare il volume 
   return(true);
  }

poiché l'elaborazione del tick precedente può richiedere un tempo sufficiente a perdere l'arrivo del primo tick della nuova barra.

In questo caso, è possibile perdere l'apertura.

È meglio legarsi all'ora di apertura della barra, ma per questo è necessario salvare l'ora precedente della barra zero, ad esempio, per confrontarla con l'ora attuale della barra zero.

Se è uguale, non c'è una nuova barra.

Se è diverso, viene aperta almeno una nuova barra (successiva), dopo di che si inizializza l'ora memorizzata della barra zero con l'ora attuale della barra zero.

Questa soluzione è più affidabile.

Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства позиций
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства позиций
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства позиций - Документация по MQL5
 

Affrontate questo aspetto in un prossimo articolo:

  • ordini di stop-loss e take-profit di livello diverso *robusto* (cioè lato server) per negoziazione; questi sono *necessari* per evitare i problemi associati alle interruzioni della rete e del programma client (disconnessioni prolungate della rete, slittamenti indotti dal ritardo della rete (e riquotazioni), interruzioni del programma client o del sistema operativo, riavvii, crash (assenza prolungata del software lato client) ecc;) i cosiddetti ordini "virtuali" non bastano e nemmeno i sostituti non-OCO (no, non è *non* negoziabile, se la robustezza è un requisito gli ordini stop-loss e take-profit *devono* essere lato server, e se uno viene colpito l'altro *deve* essere rimosso *dal server* allo stesso tempo)
  • recupero *robusto* dello stato per trade in caso di crash; in altre parole, se il client/OS si blocca (e si riavvia automaticamente) voglio che l'EA sappia esattamente cosa è successo con i singoli trade e gli ordini in sospeso nel frattempo: riempito, chiuso, ancora attivo, quali ordini associati s/l e t/p appartengono a quale trade/ordine ecc. (no, la scrittura dello stato su disco *non* è sufficiente perché c'è una race condition tra l'apertura di un trade e la scrittura dello stato su disco e il programma client può bloccarsi proprio nel momento meno opportuno; i commenti agli ordini lato server potrebbero andare bene, *se* fossero modificabili).

Per quanto ne so, MT5 supporta solo *1* (uno) ordine s/l e t/p lato server *per strumento* (non per trade) e nessun ordine OCO (gli ordini OCO possono essere utilizzati per simulare ordini s/l e t/p per trade, ma anche in questo caso c'è una race condition). A meno che non venga affrontato quanto sopra, non mi impegnerei per più di 100 dollari a fare trading tramite MT5 (EA semplicistici a singolo ordine su singolo timeframe e a singola direzione). E non sono nemmeno sicuro dei 100 dollari.

 
olyakish:

Si consiglia di evitare questo design

poiché l'elaborazione del tick precedente può richiedere un tempo sufficiente a perdere l'arrivo del primo tick della nuova barra.

In questo caso, è possibile perdere l'apertura.

È meglio legarsi all'ora di apertura della barra, ma per questo è necessario salvare l'ora precedente della barra zero, ad esempio, per confrontarla con l'ora attuale della barra zero.

Se è uguale, non c'è una nuova barra.

Se è diverso, viene aperta almeno una nuova barra (successiva), dopo di che si inizializza l'ora memorizzata della barra zero con l'ora attuale della barra zero.

Questa soluzione è più affidabile.

Io l'ho fatto in questo modo:

bool CUniexp::checkNewBar(void)
{
   static datetime prevTime[1];
   datetime currentTime[0];
   CopyTime(_Symbol,_Period,0,1,currentTime);
   if (currentTime[0]==prevTime[0])
   {return (false);}
   else
   {
      prevTime[0] = currentTime[0];
      return (true);
   }
}
 
https://www.mql5.com/it/code/107
isNewBar
isNewBar
  • voti: 7
  • 2010.05.07
  • Prival
  • www.mql5.com
Функция анализа появления нового бара на заданном таймфрейме.
 

Compila ma il debugger fallisce.

il caricamento di C:\Program Files\MetaTrader 5\MQL5\Experts\Examples\eMyEA.ex5 non è riuscito.

 
Rosh:

Pubblicato il nuovo articolo Il prototipo di robot commerciale:

Autore: Алексей Сергеев


Grazie per l'ottimo articolo! Sono un principiante ma ho una domanda sul codice.


Nella funzione void CExpertAdvisor::TrailingPosition(long dir,int TS), c'è una riga:

sl=NormalSL(dir,apr,apr,TS,StopLvl); // calcola lo Stop Loss


Dobbiamo usare apr sia per il secondo che per il terzo argomento quando chiamiamo NormalSL? Pensavo che dovesse essere:

sl=NormalSL(dir,op,apr,TS,StopLvl);

poiché il secondo argomento dovrebbe essere il prezzo bid/ask per la direzione "specificata" (cioè la variabile op) piuttosto che la direzione "inversa" (cioè la variabile apr).


Grazie!

 
echostate:


Nella funzione void CExpertAdvisor::TrailingPosition(long dir,int TS), c'è una riga:

sl=NormalSL(dir,apr,apr,TS,StopLvl); // calcola lo Stop Loss


Dobbiamo usare apr sia per il secondo che per il terzo argomento quando chiamiamo NormalSL? Pensavo che dovesse essere:

sl=NormalSL(dir,op,apr,TS,StopLvl);

no.
il secondo e il terzo argomento devono essere apr.

perché il calcolo del tral deriva dal prezzo a cui verrà chiusa la posizione. La funzione Bid per l'acquisto e Ask per la vendita è corretta.

poiché il secondo argomento deve essere il prezzo bid/ask per la direzione "specificata" (cioè la variabile op) e non la direzione "inversa" (cioè la variabile apr).

dovrebbe essere calcolato dalla direzione "inversa". In questo caso, apr.
 
sergeev:

no.
il secondo e il terzo argomento devono essere apr.

perché il calcolo del tral deriva dal prezzo di chiusura della posizione. La funzione Bid per l'acquisto e Ask per la vendita è corretta.

deve essere calcolato dalla direzione "inversa". In questo caso, apr.


Grazie per la rapida risposta! Pensavo di essermi sbagliato.


Posso anche chiedere nella funzione

double CExpertAdvisor::CountLotByRisk(int dist,double risk,double lot) // calcolare il lotto in base alla dimensione del rischio
  {
   if(dist==0 || risk==0) return(lot);
   m_smbinf.Refresh();
   return(NormalLot(AccountInfoDouble(ACCOUNT_BALANCE)*risk/(dist*10*m_smbinf.TickValue())));
  }

perché abbiamo un "10" tra "dist" e "m_smbinf.TickValue()" nel valore di ritorno? Immagino che "dist" sia lo stop loss (in termini di pip) e "m_smbinf.TickValue()" sia il valore in dollari USA per pip e lotto per la coppia di valute. Non capisco quindi perché moltiplicare un altro "10" tra i due.

Grazie!

 
Grazie mille.
 

Articolo molto utile. Grazie mille!

123
Nuovo commento