Errori tipici e come affrontarli quando si ha a che fare con l'ambiente del trading - pagina 2

 

fxsaber:

La funzione che indica la necessità di un involucro è segnata in rosso. Il suo problema è descritto qui. Qualcuno potrebbe ricordare che questo è un antico problema di riapertura delle posizioni, che nei tempi antichi veniva risolto con Sleep, aspettando che la posizione si aprisse dopo OrderSend. Ma in realtà, questo problema non ha nulla a che fare con OrderSend. Devi essere in grado di leggere correttamente l'ambiente di trading.

Quella di destra è un semplice esempio.

L'elenco degli ordini, come l'elenco delle posizioni, non viene aggiornato istantaneamente. Penso che non possiamo fare a meno di Sleep-crutch.

Probabilmente più corretto è OnTradeTransaction

 
Aleksey Lebedev:

La lista degli ordini, come quella delle posizioni, non si aggiorna istantaneamente. imho, non possiamo fare a meno di Sleep-crutch.

Probabilmente, sarebbe meglio usare OnTradeTransaction.

Se c'è un problema in attesa dell'aggiornamento dell'ambiente, come può aiutare Sleep? O aiuterà o non aiuterà.

Quindi, l'approccio dovrebbe essere dall'altra parte: dopo aver inviato un ordine per aprire una posizione o impostare un ordine pendente, dovremmo aspettare il risultato e non inviare altri ordini per aprire o impostare. Quindi, abbiamo bisogno di una bandiera che gestiamo noi stessi invece di affidarci a Sleep che dà solo il ritardo dell'esecuzione del programma ma non controlla il risultato di una richiesta di scambio inviata dal programma stesso che deve sapere cosa fare dopo - impostare una bandiera e lavorare secondo la logica dei risultati in attesa. Dopo aver atteso il risultato, la bandiera viene rimossa.

 
Artyom Trishkin:

Domanda: cosa succede se dopo aver inviato un ordine di compravendita fino al prossimo tick l'ordine a mercato non viene piazzato dal server?

Sarà esattamente come su MT4 - se non c'è niente, non verrà contato.


Ci possono essere diverse ragioni per un tale ordine di scambio

  1. OrderSend o OrderSendAsync di terze parti - non dal programma in cui leggiamo l'ambiente commerciale. Può anche non essere dal terminale in cui il programma è in esecuzione. In questo caso, non si può fare nulla. Tutto è lo stesso di MT4 in queste situazioni.
  2. OrderSend o OrderSendAsync - sono avviati dal programma in cui viene letto l'ambiente di trading. Nel caso di OrderSend, tutto è chiaro, poiché OrderSend terminerà la sua esecuzione con un risultato chiaro. Nel caso di OrderSendAsync possiamo fare due cose - passare i dati agli eventi successivi secondo il primo paradigma, o fare OrdersAsyncWait() (non ho il codice), come viene fatto in una normale simulazione di trasferimento dati asincrono in MT4 (implementazione di thread multipli).
Probabilmente dovrei dire qualche parola su OrderSendAsync in MT4. In qualsiasi fase dell'esecuzione del programma è possibile vedere quanto è occupato un thread commerciale corrispondente e cosa sta facendo esattamente. In questo senso, l'asincronia personalizzata in MT4 ci dà molte più possibilità di quella di MT5. Ma in MT4 è implementato eseguendo "client" su ogni grafico, cioè costoso. In MT5 è possibile scrivere la stessa funzionalità e anche senza molti grafici - eseguendo lo script su un oggetto OBJ_CHART, ma ci sarà comunque un leggero ritardo. Cioè OrderSendAsyncCustom sarà leggermente più lento di OrderSendAsync, ma sarà ancora molto più veloce di OrderSend + tutti i vantaggi dell'implementazione personalizzata.
 
Aleksey Lebedev:

La lista degli ordini, come quella delle posizioni, non si aggiorna istantaneamente. imho, non possiamo fare a meno di Sleep-crutch.

Probabilmente, sarebbe più corretto usare OnTradeTransaction

MqlTradeTransaction può essere necessario solo quando si sceglie il paradigma appropriato quando si lavora con OrderSendAsync. In altri casi, OnTradeTransaction == OnTrade in senso e non gioca più ruolo di OnTick o OnTimer.


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

Errori tipici e come risolverli quando si lavora in un ambiente di trading

fxsaber, 2018.02.19 22:36

Ci sono due paradigmi di lavoro con l'ambiente di trading, scrivendo EAs.

  1. Gli ingressi degli eventi (OnTick, OnTimer, ecc.) dipendono l'uno dall'altro. Ci sono informazioni che DEVONO avere tra gli eventi (non per la velocità, come la cache, ma per l'usabilità). Per esempio, dobbiamo salvare il risultato di OrderSendAsync e usarlo in OnTradeTransaction. Le cache NON sono informazioni obbligatorie e sono usate solo per accelerare. Ecco perché non li consideriamo subito.
  2. Gli ingressi degli eventi (OnTick, OnTimer ecc.) NON sono dipendenti l'uno dall'altro. Ogni ingresso è da zero. Più o meno come uno script che tu stesso esegui su ogni evento.

Evidenziato denota che lo stesso codice commerciale viene eseguito in ogni funzione On. Il corrispondente codice non commerciale completa tutto il resto.

 
fxsaber:

Sarà esattamente come su MT4 - se non c'è niente, non sarà contato.

Cioè - al prossimo tick il programma invia una nuova richiesta di apertura. Di conseguenza, abbiamo lo stesso problema: aperture multiple.

L'Expert Advisor dovrebbe avere la seguente logica:

  1. Riceviamo un segnale per aprire una posizione o impostare un ordine pendente
  2. Controlla il numero di ordini/posizioni, se non c'è un segnale per aprire una nuova posizione - esci (al punto 1).
  3. Controlla il flag di attesa della risposta del server:
    1. La bandiera è alzata - uscire (al passo 1)
    2. Bandiera omessa - continua
  4. Il flag è omesso - invia un ordine di trading (il numero di tentativi è limitato) e controlla il codice di ritorno
    1. L'ordine è stato eseguito - imposta il flag di attesa
    2. Ordine fallito - chiama la funzione di correzione dell'ordine commerciale e vai al punto 4
  5. Il flag di attesa è sollevato - controlla il cambiamento dell'ambiente commerciale
    1. L'ambiente di trading non è cambiato - esci (vai al passo 1).
    2. L'ambiente è cambiato - viene piazzato un ordine pendente o viene aperta una posizione - rimuovi il flag di attesa e esci (al passo 1).
 
Artyom Trishkin:

Cioè, al prossimo tick, il software invia una nuova richiesta di apertura. Di conseguenza, abbiamo lo stesso problema: aperture multiple.

Sarebbe bene leggere tutto il post.

L'EA dovrebbe avere la seguente logica:

  1. Abbiamo ricevuto un segnale per aprire una posizione o impostare un ordine pendente
  2. Controlla il numero di ordini/posizioni, se non c'è un segnale per aprire una nuova posizione - esci (al punto 1).
  3. Controlla il flag di attesa della risposta del server:
    1. La bandiera è alzata - uscire (al passo 1)
    2. Bandiera omessa - continua
  4. Il flag è omesso - invia un ordine di compravendita (il numero di tentativi è limitato) e controlla il codice di ritorno
    1. L'ordine è stato eseguito - imposta il flag di attesa
    2. Ordine non eseguito - chiamare la funzione correggere l'ordine e andare al punto 4
  5. Il flag di attesa è sollevato - controlla il cambiamento dell'ambiente commerciale
    1. L'ambiente commerciale non è cambiato - uscire (al passo 1).
    2. L'ambiente è cambiato - viene piazzato un ordine pendente o viene aperta una posizione - rimuovi il flag di attesa e esci (al passo 1).

Il flag di attesa è disponibile solo per il secondo caso e per OrderSendAsync. Per OrderSend, il flag di attesa non è affatto necessario. OrderSendAsync senza flag di attesa è OrdersAsyncWait().

Si può verificare qualsiasi teoria nella pratica.

Guidati da risultati pratici.
 
fxsaber:

È una buona idea leggere il post per intero.

Il flag di attesa è possibile solo per il secondo caso e per OrderSendAsync. Per OrderSend il flag di attesa non è affatto necessario. OrderSendAsync senza flag di attesa è OrdersAsyncWait().

Qualsiasi teoria può essere testata nella pratica

Sono guidato dai risultati pratici.

Beh, ho scritto per la modalità asincrona. Con il sincrono non c'è bisogno di aspettare - il risultato è già lì nella risposta della query.

 
Artyom Trishkin:

Beh, ho scritto per la modalità asincrona.

Una risposta dettagliata è stata data fin dall'inizio.

 
fxsaber:

Una risposta estesa è stata data fin dall'inizio.

Devo averlo letto male :)

Non ho visto nessun passo per aggirare l'errore di scoperta multipla. Solo "paradigmi" generali ;)

Ecco perché ho delineato la logica approssimativa, che è ridondante - il flag è controllato in una funzione (wrapper) che apre le posizioni / imposta gli ordini pendenti. O forse anche nella funzione di tracciamento del segnale.

Bisogna pensare al modo migliore.

 
Artyom Trishkin:

il flag è controllato nella funzione (wrapper) di apertura delle posizioni/posizionamento degli ordini pendenti. O forse anche nella funzione di tracciamento del segnale.

Preferisco di gran lunga la soluzione via OrdersAsyncWait(), quando l'uscita dalla funzione On è sempre fatta senza stato di sospensione. Quindi la prossima lettura dell'ambiente di trading con una lavagna pulita è il più rilevante possibile.

Usare OrderSendAsync dovrebbe essere sempre appropriato. L'unica situazione in cui sarebbe opportuno inviare diversi (> 1) ordini di compravendita, indipendenti l'uno dall'altro, su un segnale. Pertanto, la cosa OrderSendAsync non ha mai senso in tutti gli altri casi.


SZZY C'è un argomento separato in cui OrderSendAsync è molto rilevante - multi-advisors: diversi TS indipendenti in un Expert Advisor. L'OrderSend è raramente adatto lì e anche OrderAsyncWait( const string Symb) non va bene perché non è permesso in linea di principio alcuno Sleep.

Motivazione: