MetaEditor build 1490 - pagina 6

Nuovo commento
 
Andrey Dik:
https://www.mql5.com/ru/forum/162399/page3#comment_3894115
Da qualche tempo, quando una posizione viene capovolta, il suo ID di posizione CAMBIA. Questo è mostrato nell'aiuto (è anche descritto lì). Da qui le incongruenze.
 
Andrey Barinov:
Da un po' di tempo a questa parte, quando una posizione viene capovolta il suo ID di posizione viene CAMBIATO. Questo è mostrato nell'aiuto. Da qui le incongruenze.

Non è questo il problema.

Il Service Desk ha detto che lo risolveranno, una correzione sarà disponibile nella build di oggi.

 
Andrey Dik:

Il Service Desk ha risposto che una correzione sarà disponibile nella build di oggi.

1491 - nessuna correzione.
 
fxsaber:
1491 - non è stato fissato.

Sfortunatamente - no.

A proposito, non è affatto chiaro come l'attuale sistema di contabilità delle posizioni separerà la parte della posizione che ha chiuso la posizione precedente e la parte rimanente della nuova posizione (questa divisione non esiste attualmente). Sembra che il problema sia più profondo di quanto possa sembrare a prima vista.

 
Andrey Dik:

Sfortunatamente - no.

A proposito, non è affatto chiaro come l'attuale sistema di contabilità delle posizioni separerà la parte della posizione che ha chiuso la posizione precedente e la parte restante della nuova posizione (questa divisione non esiste attualmente). Sembra che il problema sia più profondo di quanto possa sembrare a prima vista.

Ecco di cosa si tratta

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

MetaEditor build 1490

fxsaber, 2016.12.05 11:32

Sì, anche seDEAL_ENTRY_INOUT è incluso nel numero di compravendite della posizione, non sarà di alcuna utilità a meno che non si espanda ENUM_DEAL_PROPERTY_*.
 
fxsaber:
Circa lo stesso

A mio parere, al contrario, l'enumerazione non dovrebbe essere ampliata, ma accorciata. QuindiDEAL_ENTRY_INOUT è un'entità inutile che non fa nulla.

Ecco un esempio di come appare ora

IN; +1.0; ID 0

IN; +0,2; ID 0

IN/OUT; -2.0; ID 1 // è stata creata una nuova posizione con un nuovo ID ma non ci sono scambi in essa; tutti gli scambi si riferiscono alla posizione precedente; quindi la commissione e gli swap sono 0.0

IN; +0.2; ID 1 // il primo trade è apparso nella lista ed è l'unico

quindi una parte del volume non si è spostata in una nuova posizione e non è visualizzata da nessuna parte, quindi gli swap e le commissioni non saranno presi in considerazione per questa parte di volume nella posizione ID 1 (blu e verde, liste corrispondenti di compravendite)


Ora come la vedo io, e come dovrebbe essere logicamente e storicamente (quale decisione prenderà MQ è l'ipotesi di chiunque):

IN; +1.0; ID 0

IN; +0,2; ID 0

OUT; -1.2; ID 0 // la parte del volume dell'affare che è andato alla posizione che viene chiusa

IN; -0.8; ID 1 // è apparsa una nuova posizione con il nuovo ID, il trade è presente come resto, il trade è nella lista, ed è il primo

IN; +0.2; ID 1 // il secondo trade nella lista

Così, il tipo di accordo IN/OUT non è affatto necessario. In questo modo tutto è considerato correttamente e le liste di accordi in posizioni sono complete, possiamo adeguatamente ottenere i valori delle commissioni e degli swap per gli accordi corrispondenti. E se ci sarà la necessità di determinare quali operazioni (una parte è andata a chiudere e l'altra ad aprire una nuova posizione) fanno parte di un ordine, sarà molto facile farlo - operazioni OUT e IN che hanno lo stesso tempo (segnate in grassetto).

 
Andrey Dik:

A mio parere, al contrario, l'enumerazione non dovrebbe essere ampliata, ma accorciata. QuindiDEAL_ENTRY_INOUT è un'entità inutile che non dà nulla.

Una transazione è un'entità di esecuzione che non dipende dalla piattaforma. E le bandiere ENTRY sono una sciocchezza della MQ.

Se c'era un solo scambio nel mercato, non puoi rappresentarlo come due, anche se sarebbe conveniente.

MQ ha fatto di tutto per aggiungere la virtualizzazione - modalità Hedge. Fare anche una semplice virtualizzazione per uno scambio è una cattiva decisione.

Ma l'estensione delle proprietà di transazione dà convenienza senza le potenziali stampelle.

 
fxsaber:

Una transazione è un'entità di esecuzione che non dipende in alcun modo dalla piattaforma. E le bandiere ENTRY sono un espediente di MQ.

Se c'era un solo scambio nel mercato, non puoi rappresentarlo come due, anche se sarebbe conveniente.

MQ ha fatto di tutto per aggiungere la virtualizzazione - modalità Hedge. Fare anche una semplice virtualizzazione per uno scambio è una cattiva decisione.

Ma estendere le proprietà della transazione dà convenienza senza potenziali stampelle.

Beh, stavo solo esponendo la mia opinione.

E che tipo di estensione salverebbe la giornata? Avete ancora bisogno di determinare in qualche modo quale parte della transazione si riferisce alla vecchia posizione e quale alla nuova.

 
Andrey Dik:

E che tipo di espansione salverebbe la situazione? C'è ancora modo di determinare quale parte dell'accordo è per la vecchia posizione e quale per la nuova.

Sta agli sviluppatori decidere. Il tuo suggerimento mi piace di più. Ma capisco che richiede la virtualizzazione, il che è inaccettabile.
 

1491 - Alpari-MT5-Demo. Gli screenshot mostrano lo stesso posto

Terminale

Tester di zecche reali

I candelabri non corrispondono l'uno all'altro - nel tester sono sfocati. Inoltre, il tempo storico del tester e del terminale differiscono di un'ora.

CopyTicks nel terminale restituisce gli stessi dati del tester - un'ora di differenza. Pertanto, le zecche non corrispondono completamente alle barre.

Quindi come fidarsi di MT5, il tester, quando c'è un completo autocredito? Perché gli sviluppatori non hanno degli EA di riferimento da far girare nel tester e sapere con certezza che funziona chiaramente? È un casino totale.

12345678
Nuovo commento