Errori, bug, domande - pagina 689

 
Urain:

Alex, perché non prendono la multi-valuta come modello di base e lasciano che quelli che non ne hanno bisogno implorino i DC di accorciare la loro storia tagliando le barre sincrone.

Se avessi voluto usare il terminale come un MQ a valuta unica, mi sarebbe mancata la modalità multi-valuta e il problema sarebbe stato perché l'ho posizionato come un MQ multi-valuta, da cui tutti i problemi che sono seguiti.

cosa c'entrano le modelle o i modelli tester?

Il punto della piattaforma è chiaramente ricevere e memorizzare l'informazione iniziale nei terminali nella stessa quantità in cui è stata ricevuta dal server.

Gli sviluppatori non possono dare informazioni imparziali! Le informazioni sulle zecche sono tante quante ne esistono.

Se il modello di test multivaluta implica una barra ad ogni minuto, questo non è un modello del server, è un modello del tester.
Se
il modello di costruzione degli indicatori implica la presenza di una barra ad ogni minuto, non è un modello di lavoro server ma un modello di lavoro tester

Non dovete supplicare gli sviluppatori di cambiare il server per adattarlo ai loro modelli di percezione della storia o di test, non è costruttivo.

Se avete bisogno della storia mancante di minuti, dovete chiedere alle vostre società di brokeraggio di aggiungere le barre di ogni minuto mancante alla loro storia, con un unico volume.

 
hrenfx:

Chiedete al vostro broker di bypassare la stampella Metaquotes? La stessa stampella si applica ai single.

Avete bisogno che il server memorizzi l'ora di inizio della barra dei minuti non a :00 secondi ma al momento dell'arrivo del primo tick, per esempio a :05 o :24 ?

Se questo è tutto ciò di cui avete bisogno e questo risolverà molti problemi di test - il terminale e la qualità del vostro tester miglioreranno molto? Un tale offset di alcuni secondi è critico per i test multicurrency?

Non dimenticare che il tester modella tutti i prezzi all'interno di una barra usando il volume dei tick. Guadagnerete molto se la prima zecca arriva come ha fatto, e tutte le altre non arrivano affatto come nella vita reale?

Se questo spostamento non ha alcun effetto sui tick successivi, perché lo spostamento? Per la prima spunta corretta?

Mi sembra che senza un test sulla storia reale del tick - tenendo conto del tempo reale del primo tick e modellando quelli successivi - sia un beneficio immaginario.

 
sergeev:

Cosa c'entrano i modelli o le modelle tester?

Il punto della piattaforma è chiaramente accettare e memorizzare l'informazione originale nei terminali nella quantità che è apparsa e arrivata al server.

Gli sviluppatori non possono regalare nulla! La quantità di informazioni sulle zecche è la stessa che è stata ricevuta - non un byte di più, non di meno.

Se il modello di test multivaluta implica che ci sia una barra ogni minuto, questo non è un modello del server, è un modello del tester.
Se
il modello di costruzione di indicatori implica la presenza della barra ad ogni minuto, non è un modello di server, ma il modello dell'indicatore

Non andate a supplicare gli sviluppatori di cambiare il server per adattarlo alla loro percezione della storia o ai loro modelli di test, non è costruttivo.

Se avete bisogno della cronologia dei minuti mancanti, allora dovreste chiederlo - i vostri DC, che aggiungano le barre di ogni minuto mancante alla loro cronologia, con volumi unitari.

Noi falsifichiamo i fatti per il corso di pensiero richiesto :)

Il server trasmette i tick, dove vedi la cronologia dei tick?

D'altra parte il terminale riceve la cronologia, che è memorizzata dal server, ma perché è considerato corretto memorizzare la cronologia sul server in questo formato e non in un formato synchroblock?

Perché il server stesso non ha un generatore di frequenza?

Perché è considerato corretto affettare le barre in base al tempo, ma introdurre un generatore di frequenza non è più corretto?

Allora sbarazziamoci del tempo e passiamo alle croci e agli zeri. Lì non c'è praticamente nessun concetto di tempo.

Алгоритм генерации тиков в тестере стратегий терминала MetaTrader 5
Алгоритм генерации тиков в тестере стратегий терминала MetaTrader 5
  • 2010.05.21
  • MetaQuotes Software Corp.
  • www.mql5.com
MetaTrader 5 позволяет во встроенном тестере стратегий моделировать автоматическую торговлю с помощью экспертов на языке MQL5. Такое моделирование называется тестированием экспертов, и может проводиться с использованием многопоточной оптимизации и одновременно по множеству инструментов. Для проведения тщательного тестирования требуется генерировать тики на основе имеющейся минутной истории. В статье дается подробное описание алгоритма, по которому генерируются тики для исторического тестирования в клиентском терминале MetaTrader 5.
 
sergeev:

Volete che il server memorizzi l'ora di inizio della barra dei minuti non a :00 secondi, ma al momento del primo tick, per esempio a :05 o :24?

No, non si tratta di questo. L'unica cosa da fare è far corrispondere il prezzo di apertura della barra al prezzo che era sul conto reale al momento dell'apertura del minuto. Cioè, il tester non deve mentire quando mostra il prezzo di apertura della barra al minuto di apertura.

Un tale spostamento di alcuni secondi è cruciale per il test di Expert Advisors multivaluta?

Sì, lo è, perché causa una significativa insincronizzazione. Per esempio, crea una situazione di arbitraggio quasi costante tra diversi simboli correlati ai prezzi di apertura.

Non dimenticare che il tester modella tutti i prezzi all'interno di una barra utilizzando il volume del tick. Quanto guadagnerete se la prima zecca arriva come è arrivata e tutte le altre non sono affatto come nella vita reale?

Molto più di quello che era - la sincronizzazione non sarà solo tra i prezzi di chiusura, ma anche tra i prezzi di apertura. Inoltre, le barre multivaluta saranno sincronizzate, il che libererà un'enorme quantità di risorse di calcolo durante l'ottimizzazione, che ora sono spese per la stessa operazione ad ogni passaggio - la sincronizzazione.

Mi sembra che senza un test sulla storia reale dei tick - per tenere conto del tempo reale del primo tick e simulare i successivi - sia un profitto immaginario.

Ho già scritto sopra che non si tratta del tempo del primo tick. Ma riguardo alla magnificenza della storia delle zecche - questo è un mito nella maggior parte dei casi. Per la maggior parte dei TC, la storia M1 Bid + Ask OHLC è sufficiente.
 

Il compito di memorizzare la storia di più valute è molto simile a quello di memorizzare un video. È necessario memorizzare un frame di sincronizzazione valido e salvare le modifiche da esso.

Attualmente non c'è nessun telaio sincro, ci sono solo linee sincrone. Ogni linea (coppia di valute) memorizza i suoi cambiamenti e anche le linee non hanno un punto di sincronizzazione.

Non possiamo dire con certezza che il prezzo era esattamente a questo punto (apertura del bar).

Dato che l'apertura della barra era alle xx:yy:00 e il tick di apertura era alle xx:yy:12

 
Urain:

Dato che l'ora di apertura della barra era alle xx:yy:00 e il tick di apertura era alle xx:yy:12

Per immagazzinarlo in questo modo, bisogna impegnarsi molto per convincere gli sviluppatori che è la cosa giusta da fare e che tutti ne beneficeranno.

Ma è fattibile (intendo il lato tecnico). Devi solo convincerli a riscrivere il motore lato server (e anche quello del terminale) per memorizzare ed elaborare le barre :)

In questa situazione, più resistenza (80%) sarà al primo stadio della persuasione. E dopo di che dipende dai programmatori.

Che Veles e Ganesh li aiutino

 
Urain:

Non si può dire con sicurezza che a questo punto (apertura del bar) il prezzo era esattamente lì.

Perché l'ora di apertura della barra era alle xx:yy:00 e il tick di apertura era alle xx:yy:12

È possibile se si punta solo ai prezzi di chiusura. Ma per farlo, è necessario tracciare l'evento di chiusura del minuto (non della barra), prendendo Close[1] come prezzo corrente.

Questi workaround sono stampelle completamente artificiali che gli sviluppatori usano, ma è una soluzione backdoor.

Anche se gli sviluppatori cambiano la situazione, il prezzo simulato di Ask darà ancora desincronizzazione, sia con l'analisi reale che con quella multivaluta nel tester.

 
hrenfx:

Lo è, perché dà un'insincronizzazione seria. Per esempio, crea una situazione di arbitraggio quasi costante tra diversi simboli interconnessi ai prezzi di apertura.

... Che in realtà non esiste, ma il tester crea l'illusione nel tester che l'arbitraggio esista.

Giusto?

 
joo:

... che in realtà non esiste, ma il tester dà l'illusione che l'arbitraggio esista.

Giusto?

Esattamente giusto. Non c'è arbitraggio nella vita reale e il tester mostra prezzi di arbitraggio su dati storici apparentemente accurati (non modellati) - prezzi di apertura.
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы индикаторов / Ценовые константы
Документация по MQL5: Стандартные константы, перечисления и структуры / Константы индикаторов / Ценовые константы
  • www.mql5.com
Стандартные константы, перечисления и структуры / Константы индикаторов / Ценовые константы - Документация по MQL5
 
hrenfx:
Abbastanza giusto. Non c'è arbitraggio nella vita reale, e il tester mostra prezzi di arbitraggio su dati storici apparentemente accurati (non modellati) - prezzi di apertura.

Non è buono...

Qui ho sempre sentito nel mio cervello che l'analisi multivalutaria doveva essere evitata, altrimenti mi sarei preso un rastrello in fronte. Sembra che l'abbia evitato per un motivo.

Motivazione: