Fare un servizio di certificazione per i programmatori... - pagina 6

 

Sì ragazzi....

già la classificazione è in palio :))))

 
VOLDEMAR:
Se non hai niente di buono da dire, non dire niente o almeno parlane ..... Se tu sapessi qualcosa, me lo mostreresti... O è troppo brutto? O non sanno niente ....

non c'è niente da discutere.

In realtà faresti meglio a pettinare le tue funzioni di invio degli ordini per la correttezza dell'ordine che viene inviato al server.

Vorrei che il messaggio di errore fosse prima del server, non dopo aver ricevuto l'errore).
Документация по MQL5: Стандартные константы, перечисления и структуры / Коды ошибок и предупреждений / Ошибки компиляции
Документация по MQL5: Стандартные константы, перечисления и структуры / Коды ошибок и предупреждений / Ошибки компиляции
  • www.mql5.com
Стандартные константы, перечисления и структуры / Коды ошибок и предупреждений / Ошибки компиляции - Документация по MQL5
 
MrGold166:
Questo è il punto dell'overshooting dalla fine, non c'è niente di militare nel processare un ordine due volte. Nel caso peggiore ci impedisce solo se contiamo gli ordini, per esempio il prezzo medio, un ordine sarà contato 2 volte. Anche se interferisce fortemente con i calcoli, al prossimo tick tutto tornerà a posto e metteremo il take profit dove dovrebbe essere. Nella mia memoria con più di 50 ordini e con il peggiore cosiddetto "broker" asiatico (sì, sapete chi intendo) questo non è mai successo dopo che il conto è stato scambiato (sapete perché). Ma anche questo può essere evitato:

int i,last_ticket;
for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {
   if(OrderTicket()==last_ticket) continue;
   last_ticket=OrderTicket();
   }

E come si può garantire che non si avrà la stessa situazione la prossima volta che si spunta, sì, niente.

E il caso peggiore può venire, calcolerete la media sbagliata e aprirete un ordine sbagliato e il prossimo tick non avrà importanza.

Non è il numero di ordini che conta, ma l'ambiente di trading, la presenza di stop reali, la presenza di altri EA nel conto.

 
MrGold166:
Ma anche questo può essere evitato:

int i,last_ticket;
for(i=OrdersTotal()-1;i>=0;i--) if(OrderSelect(i,SELECT_BY_POS) {
   if(OrderTicket()==last_ticket) continue;
   last_ticket=OrderTicket();
   }
Teoricamente più di un ordine potrebbe cambiare stato
 
A100:
Teoricamente lo stato di più di un ordine potrebbe cambiare

Un'idea valida, non ho pensato a due, mi sono bloccato su uno.

Così si torna al punto di partenza, quindi come risolvere le collisioni con questa funzione.

 
sandex:

Idea valida, non ho pensato a due, mi sono bloccato su uno.

Così si torna al punto di partenza, quindi come risolvere le collisioni con questa funzione.

   int j=OrdersTotal();
   for(int i=j-1;i>=0;i--)
   {
      if(OrderSelect(i,SELECT_BY_POS))
      {
      }
   }
   if(j!=OrdersTotal())return(0);

Eventualmente, ricalcolare di nuovo. se il numero di ordini di entrata e di uscita non sono uguali.

 
A100:
Teoricamente più di un ordine potrebbe cambiare

E allora? Anche se tutti cambiano, non analizzeremo comunque gli stessi scambi.

Se stiamo parlando di uno scambio nella lista che è cambiato, allora può cambiare dopo che siamo passati attraverso la ricerca - prima di mettere il profitto totale.

 
snowman:

Semmai, ricalcolare di nuovo se il numero di ordini di entrata e di uscita non è uguale.

Nel caso generale anche il numero di ordini può essere uguale, solo che possono essere ordini diversi
 
snowman:

Se il numero di ordini di entrata e di uscita non è uguale, allora ricalcolalo di nuovo.

Questo non ci aiuterà nemmeno se viene aperto un ordine in sospeso, la quantità di ordini sarà salvata ma i parametri no. D'altra parte, questo non ci disturberebbe affatto, se non avessimo incluso nell'importo un ordine pendente appena aperto, va bene così. (Non vedo davvero una situazione in cui questo possa causare un errore). Questa situazione può verificarsi solo in una serie speciale di circostanze, una delle quali è un sacco di tick, cioè la prossima iterazione sarà molto presto e l'errore sarà corretto. Se il rimbalzo dell'ordine avviene tra i tick, questo non è un problema per noi.

Spesso vediamo i codici di altri programmatori dove l'enumerazione viene fatta decine di volte per iterazione separatamente per calcolare un mucchio di parametri e questo è un problema.

 
MrGold166:

E allora? Anche se tutti cambiano, non analizzeremo comunque gli stessi scambi.

Se stiamo parlando di uno scambio nella lista che è cambiato, allora può cambiare dopo che siamo passati attraverso la ricerca - prima di mettere il profitto totale.

Non mi riferivo al calcolo applicato a una situazione specifica, ma al caso generale. Penso che il doppio conteggio e/o il sottoconteggio abbiano importanza, a volte criticamente
Motivazione: