MetaEditor build 1490 - pagina 6
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
https://www.mql5.com/ru/forum/162399/page3#comment_3894115
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.
Il Service Desk ha risposto che una correzione sarà disponibile nella build di oggi.
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.
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.
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_*.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).
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.
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.
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.
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.