Domande da un "manichino" - pagina 176

[Yedelkin]

Karlson:

3Б. Chiudere parzialmente aprendo una mezza vendita - OUT.

Peccato :/ Si scopre che ci possono essere diversi trade nella storia con la proprietà OUT, mentre la posizione esiste ancora.

[Anatoli Kazharski]

Yedelkin:
Male :/

Perché male? È semplice, se ho capito bene. Se OUT e c'è una posizione, allora c'è stata una riduzione di volume. Se OUT e nessuna posizione, allora la posizione è stata chiusa completamente.

[Yedelkin]

tol64:
Perché è male? Tutto è semplice, se ho capito bene. Se c'è una posizione e OUT, c'è stata una diminuzione di volume. Se OUT e non c'è nessuna posizione, allora la posizione è stata chiusa completamente.

La cosa brutta è questa. Il vostro approccio"Se OUT e c'è una posizione, c'è stata una riduzione del volume. Se non c'è OUT e non c'è posizione, allora la posizione è stata chiusa completamente" ha una caratteristica che trovo ingombrante, cioè la necessità di verificare ogni volta l'esistenza di informazioni sulla posizione nel database del terminale.

Sappiamo tutti che le informazioni nel terminale di base arrivano con un certo ritardo rispetto alla situazione reale. Quindi non possiamo escludere situazioni in cui il risultato del controllo è"c'è una posizione ed è OUT", ma in realtà la posizione è stata chiusa. In altre parole, è possibile ottenere informazioni imprecise e usarle come base per intraprendere azioni sbagliate, oppure ci si dovrà inventare controlli aggiuntivi, ritardi o qualsiasi cosa sia conveniente.

Ma si può fare a meno di tutti questi trucchi. In particolare, senza verificare la disponibilità della posizione. Per fare questo, è sufficiente lasciare una corrispondenza uno-a-uno tra la chiusura della posizione e la proprietà DEAL_ENTRY_OUT (corrispondenza - come è presentata ora in Handbook), e assegnare la riduzione del volume della posizione in una proprietà separata della transazione. Allora sarà sufficiente trovare nella storia (HistorySelectByPosition) una sola operazione con proprietà DEAL_ENTRY_OUT, ed essere sicuri che la posizione non è ridotta, ma esattamente chiusa, e che in nessun caso può essere invertita.

[Anatoli Kazharski]

Yedelkin:

La cosa brutta è questa. Il tuo approccio"Se OUT e c'è una posizione, c'è stata una riduzione del volume. Se non c'è OUT e non c'è posizione, allora la posizione è stata chiusa completamente" ha una caratteristica che trovo ingombrante, cioè la necessità di verificare ogni volta l'esistenza di informazioni sulla posizione nel database del terminale.

Sappiamo tutti che le informazioni nel terminale di base arrivano con un certo ritardo rispetto alla situazione reale. Quindi non possiamo escludere situazioni in cui il risultato del controllo è"c'è una posizione ed è OUT", ma in realtà la posizione è stata completamente chiusa. In altre parole, è possibile ottenere informazioni imprecise e usarle come base per intraprendere azioni sbagliate, oppure ci si dovrà inventare controlli aggiuntivi, ritardi o qualsiasi cosa sia conveniente.

Ma si può fare a meno di tutti questi trucchi. In particolare, senza verificare la disponibilità della posizione. Per fare questo, è sufficiente lasciare una corrispondenza uno-a-uno tra la chiusura della posizione e la proprietà DEAL_ENTRY_OUT (corrispondenza - come è presentata ora in Handbook), e assegnare la riduzione del volume della posizione in una proprietà separata della transazione. Allora sarà sufficiente trovare nella storia (HistorySelectByPosition) una singola operazione con proprietà DEAL_ENTRY_OUT e sapere con certezza che la posizione non è ridotta, ma esattamente chiusa, e che in nessun caso può essere invertita.

In OnTrade(), riceviamo la risposta dal server. Cioè, se controlliamo l'evento in OnTrade(), sapremo già con certezza se c'è una posizione o no. Anche se possiamo fornire opzioni standard come DEAL_ENTRY_FULLOUT (chiusura completa) oDEAL_ENTRY_PARTOUT (chiusura parziale) per rendere tutto perfettamente elegante.)))

Nel frattempo, si possono fare funzioni separate, in modo da non dover introdurre ogni volta "controlli ingombranti".

[Yedelkin]

tol64:

Anche se si potrebbero fare opzioni standard come DEAL_ENTRY_FULLOUT oDEAL_ENTRY_PARTOUT per rendere tutto perfettamente elegante.)))

Ecco di cosa si tratta. Non avremo nemmeno bisogno di fare dei controlli aggiuntivi in OnTrade che sembreranno troppo macchinosi rispetto alla soluzione proposta (FULLOUT / PARTOUT).

[Anatoli Kazharski]

Yedelkin:
Questo è il punto... Non bisognerebbe nemmeno fare dei controlli extra in OnTrade, il che sarebbe comunque macchinoso rispetto alla soluzione proposta (FULLOUT / PARTOUT).

Prova a fare una proposta al Service Desk. Forse lo prenderanno in considerazione e un giorno lo implementeranno.

[Yedelkin]

tol64:
Prova a fare una proposta al Service Desk. Forse lo prenderanno in considerazione e un giorno lo implementeranno.

L'ho già fatto :) Come errore linguistico...Wow, ci ho messo un'ora a comporre.

[Anatoli Kazharski]

Yedelkin:
L'ho già fatto :) Come lapsus... Wow, ci ho messo un'ora a comporre.

Non si può ancora definire un errore. Ma cosa puoi fare ora che sei già stato mandato. ))

[Yedelkin]

tol64:
Non si può ancora definire un errore. Ma cosa puoi fare ora che sei stato mandato. ))

Bene, qui è dove le categorie di valutazione entrano un po' in gioco :) Ho cercato di giustificare la categoria Errori :)

[Валерий]

Yedelkin:

Sì, ogni periodo corrisponde a un certo valore. Qualcuno l'ha postato sul forum un paio di anni fa. Puoi scoprirlo da solo eseguendo una linea come quella qui sotto:

Lo script stamperà i valori ENUM_TIMEFRAMES per tutti i periodi in sistema decimale:

void OnStart()
  {
//---
   for(int i=(int)PERIOD_CURRENT;i<=(int)PERIOD_MN1;i++)
     {
       ResetLastError();
       string period=EnumToString((ENUM_TIMEFRAMES)i);
       if(GetLastError())
        continue;
       Print(EnumToString((ENUM_TIMEFRAMES)i)+"="+IntegerToString(i));
     }
  }
//+------------------------------------------------------------------+