Ha registrato con forza il codice di cui sopra e ha capito le ragioni. Se CopyTicks (da > 0) riceve tick prima del più fresco, può saltarne alcuni.
Una risposta molto importante dal Service Desk.
Per quanto riguarda il problema originale - che CopyTicks sulla prossima chiamata può dare più tick per lo stesso periodo:
Questo è effettivamente il caso. Il problema è che i flussi di dati dello scambio bid/ask e flipper/volume sono flussi diversi, che non sono sincronizzati tra loro già sul lato dello scambio.
A causa di questo ci sono situazioni in cui prima arriva il bid/ask con il tempo 12:12:12.300, e un po' più tardi arriva il flipper/volume con il tempo 12:12:12.299.
Di conseguenza, richiedendo i dati dall'ultimo tick (12:12:12.300) non otterrete un nuovo flipper per 12:12:12.299.
PS. Il terminale salva e invia i tick ordinati per tempo. Cioè, la sequenza temporale di tick data a CopyTicks è sempre crescente.
Ci sono due flussi di ricezione delle zecche - INFO e TRADE. TUTTO è un'unione sintetizzata (sembra essere sul lato terminale), ecco perché possono verificarsi tali contrattempi.
È a causa di sintetizzato che ci sono state tali parole
Slawa:
i record di tick iniziali dopo la chiamata di CopyTicks non conterranno zeri, ma i valori attuali di bid, ask e last al momento richiesto
Quindi, quando si lavora con TUTTE le zecche, è necessario essere chiaramente consapevoli di ciò con cui si ha a che fare. È possibile che anche le bandiere di spunta siano sintetizzate. Vorrei una completa specificità su questi temi.
Con il nastro questo problema non dovrebbe sorgere con il corretto funzionamento di CopyTicks.
Penso che l'aiuto sarà integrato molto seriamente.
fxsaber: Potete aggiungere voi stessi qualsiasi sovraccarico.
Io posso fare molto, voi potete fare molto, anche altri programmatori possono fare molto, ma si spera che gli sviluppatori conoscano meglio il "ripieno" e possano creare algoritmi rapidi per ottenere i tick necessari.
Ha registrato con forza il codice di cui sopra e ha capito le ragioni. Se CopyTicks (da > 0) ottiene tick fino al più fresco, potrebbe saltarne alcuni.
Esempio.
Tick richiesti con da = 2016.09.29 11:05:55.564. Ho ricevuto tre tick in risposta
Qualche tempo dopo ho richiesto la cronologia dei tick da lontano e ho ottenuto un tick, che CopyTicks ha mancato prima
Un tale insetto!
Sembra che ci sia qualche conflitto di scrittura e lettura parallela del database delle zecche.
1434 è lo stesso bug per i tipi di commercio. Riproduzione di Expert Advisor
#include <TypeToBytes.mqh> // https://www.mql5.com/ru/code/16280long LastTime = 0; // time_msc-время последнего тика (самого свежего), полученного из историиint Count = 0; // Количество тиков в последенем запросе, у которых time_msc == LastTime// Возвращает свежие тики, пришедшие после предыдущего вызоваint GetFreshTicks( MqlTick &Ticks[], constuint flags = COPY_TICKS_TRADE, constuint count = 100000 )
{
int Res = 0;
MqlTick NewTicks[];
constint NewAmount = CopyTicks(Symbol(), NewTicks, flags, LastTime, count);
if ((NewAmount > 0) && (Count < NewAmount))
{
Res = ArrayCopy(Ticks, NewTicks, 0, Count);
// Взяли крайнее время из текущей истории
LastTime = Ticks[Res - 1].time_msc;
Count = 1;
// Находим (Count) в текущей истории количество тиков со временем LastTimefor (int i = Res - 2; i >= 0; i--)
{
if (Ticks[i].time_msc < LastTime)
break;
Count++;
}
}
return(Res);
}
string GetTickFlag( uint tickflag )
{
string flag = "";
#define TICKFLAG_MACRO(A) flag += ((bool)(tickflag & TICK_FLAG_##A)) ? " TICK_FLAG_" + #A : "";
TICKFLAG_MACRO(BID)
TICKFLAG_MACRO(ASK)
TICKFLAG_MACRO(LAST)
TICKFLAG_MACRO(VOLUME)
TICKFLAG_MACRO(BUY)
TICKFLAG_MACRO(SELL)
#undef TICKFLAG_MACRO
if (flag == "")
flag = " FLAG_UNKNOWN (" + (string)tickflag + ")";
return(flag);
}
#define TOSTRING(A) " " + #A + " = " + (string)Tick.A
string TickToString( constMqlTick &Tick )
{
return(TOSTRING(time) + "." + (string)IntegerToString(Tick.time_msc %1000, 3, '0') +
TOSTRING(bid) + TOSTRING(ask) + TOSTRING(last)+ TOSTRING(volume) + GetTickFlag(Tick.flags));
}
#define TOSTRING2(A) #A + " = " + (string)(A) + " "template <typename T>
bool ArrayEqual( const T &Array1[], const T &Array2[] )
{
constint Amount = MathMin(ArraySize(Array1), ArraySize(Array2));
bool Res = (Amount > 0);
if (Res)
for (int i = 0; i < Amount; i++)
if (_R(Array1[i]) != Array2[i]) // https://www.mql5.com/ru/code/16280
{
Print(TOSTRING2(i) + TOSTRING2(ArraySize(Array1)) + TOSTRING2(ArraySize(Array2)));
Print(TOSTRING2(TickToString(Array1[i])) + "\n" + TOSTRING2(TickToString(Array2[i])) + "\n");
Print(TOSTRING2(TickToString(Array1[i - 1])) + "\n" + TOSTRING2(TickToString(Array2[i - 1])) + "\n");
Res = false;
ExpertRemove();
break;
}
return(Res);
}
voidOnTick( void )
{
staticbool FirstRun = true;
staticMqlTick PrevTicks[];
if (FirstRun)
{
LastTime = TimeCurrent() * 1000;
Count = 0;
FirstRun = false;
}
MqlTick Ticks[];
// Взяли свеженькие тикиconstint Amount = GetFreshTicks(Ticks);
ArrayCopy(PrevTicks, Ticks, ArraySize(PrevTicks));
if (ArraySize(PrevTicks) > 0)
{
MqlTick NewTicks[];
// Взяли историю тиковPrint(CopyTicks(_Symbol, NewTicks, COPY_TICKS_TRADE, PrevTicks[0].time_msc, 1000000));
// Проверка на совпадение собираемой истории с самой историейPrint(ArrayEqual(NewTicks, PrevTicks) ? "Equal" : "Not Equal");
}
}
Risultato
2016.10.0410:36:17.743 Test13 (RTS-12.16,M1) Not Equal
2016.10.0410:36:17.743 Test13 (RTS-12.16,M1) ExpertRemove() function called
2016.10.0410:36:17.743 Test13 (RTS-12.16,M1)
2016.10.0410:36:17.743 Test13 (RTS-12.16,M1) TickToString(Array2[i-1]) = time = 2016.10.0410:37:07.791 bid = 99680.0 ask = 99690.0 last = 99690.0 volume = 4TICK_FLAG_LASTTICK_FLAG_VOLUMETICK_FLAG_BUY2016.10.0410:36:17.743 Test13 (RTS-12.16,M1) TickToString(Array1[i-1]) = time = 2016.10.0410:37:07.791 bid = 99680.0 ask = 99690.0 last = 99690.0 volume = 4TICK_FLAG_LASTTICK_FLAG_VOLUMETICK_FLAG_BUY2016.10.0410:36:17.743 Test13 (RTS-12.16,M1)
2016.10.0410:36:17.743 Test13 (RTS-12.16,M1) TickToString(Array2[i]) = time = 2016.10.0410:37:07.791 bid = 99680.0 ask = 99690.0 last = 99690.0 volume = 4TICK_FLAG_LASTTICK_FLAG_VOLUMETICK_FLAG_BUY2016.10.0410:36:17.743 Test13 (RTS-12.16,M1) TickToString(Array1[i]) = time = 2016.10.0410:37:08.773 bid = 99690.0 ask = 99700.0 last = 99690.0 volume = 1TICK_FLAG_LASTTICK_FLAG_VOLUMETICK_FLAG_SELL2016.10.0410:36:17.743 Test13 (RTS-12.16,M1) i = 144ArraySize(Array1) = 145ArraySize(Array2) = 1462016.10.0410:36:17.743 Test13 (RTS-12.16,M1) 1452016.10.0410:36:16.768 Test13 (RTS-12.16,M1) Equal
La cronologia dei tick raccolti in tempo reale del thread TRADE non conteneva un tick con tempo 2016.10.04 10:37:08.773, che è apparso più tardi nella cronologia.
Questo è in qualche modo incoerente con quello che ho detto sopra. I problemi non sono solo con il flusso ALL sintetizzato, ma anche con quello diretto - TRADE.
Vorrei cogliere l'occasione per ringraziare gli sviluppatori per il loro lavoro con CopyTicks!
Non posso affermare che CopyTicks funziona in modo assolutamente corretto, ma sono riuscito a lavorare perfettamente con il nastro e a capire CopyTicks più a fondo.
Per non reinventare la ruota, puoi vedere esempi di scrittura di indicatori di tick basati sul nastro qui e qui.
1434 - 1ms in media ci vuole per ottenere CopyTicks già caricato 1000 ticks. Lentamente, sembra.
Richiesta di TRADE0tic con from_msc dell'ultimo tick ricevuto in precedenza. Ottengo 3 tick, ma in 0.3 - 0.9ms! - Molto lento ora.
Ha registrato con forza il codice di cui sopra e ha capito le ragioni. Se CopyTicks (da > 0) riceve tick prima del più fresco, può saltarne alcuni.
Per quanto riguarda il problema originale - che CopyTicks sulla prossima chiamata può dare più tick per lo stesso periodo:
Questo è effettivamente il caso. Il problema è che i flussi di dati dello scambio bid/ask e flipper/volume sono flussi diversi, che non sono sincronizzati tra loro già sul lato dello scambio.
A causa di questo ci sono situazioni in cui prima arriva il bid/ask con il tempo 12:12:12.300, e un po' più tardi arriva il flipper/volume con il tempo 12:12:12.299.
Di conseguenza, richiedendo i dati dall'ultimo tick (12:12:12.300) non otterrete un nuovo flipper per 12:12:12.299.
PS. Il terminale salva e invia i tick ordinati per tempo. Cioè, la sequenza temporale di tick data a CopyTicks è sempre crescente.
Ci sono due flussi di ricezione delle zecche - INFO e TRADE. TUTTO è un'unione sintetizzata (sembra essere sul lato terminale), ecco perché possono verificarsi tali contrattempi.
È a causa di sintetizzato che ci sono state tali parole
i record di tick iniziali dopo la chiamata di CopyTicks non conterranno zeri, ma i valori attuali di bid, ask e last al momento richiesto
Con il nastro questo problema non dovrebbe sorgere con il corretto funzionamento di CopyTicks.
Penso che l'aiuto sarà integrato molto seriamente.
Potete aggiungere voi stessi qualsiasi sovraccarico.
CopyTicks testato con il flag COPY_TICKS_TRADE
Nessuna differenza.
CopyTicks testato con il flag COPY_TICKS_TRADE
Nessuna differenza.
Forum sul trading, sistemi di trading automatico e tester di strategie
Misterioso indicatore di azioni
fxsaber, 2016.09.30 21:26
1434 - il problema non è stato risolto.
Ha registrato con forza il codice di cui sopra e ha capito le ragioni. Se CopyTicks (da > 0) ottiene tick fino al più fresco, potrebbe saltarne alcuni.
Esempio.
Tick richiesti con da = 2016.09.29 11:05:55.564. Ho ricevuto tre tick in risposta
Qualche tempo dopo ho richiesto la cronologia dei tick da lontano e ho ottenuto un tick, che CopyTicks ha mancato prima
Un tale insetto!
Sembra che ci sia qualche conflitto di scrittura e lettura parallela del database delle zecche.
La cronologia dei tick raccolti in tempo reale del thread TRADE non conteneva un tick con tempo 2016.10.04 10:37:08.773, che è apparso più tardi nella cronologia.
Questo è in qualche modo incoerente con quello che ho detto sopra. I problemi non sono solo con il flusso ALL sintetizzato, ma anche con quello diretto - TRADE.
1434 è lo stesso bug per i tipi di commercio. Riproduzione del consulente
1434 - 1ms in media ci vuole per ottenere CopyTicks già caricato 1000 ticks. Lentamente, sembra.
Richiesta di TRADE0tic con from_msc dell'ultimo tick ricevuto in precedenza. Ottengo 3 tick, ma in 0.3 - 0.9ms! - Molto lento ora.
Rilevante! Non c'è modo di accelerarlo?
Vorrei cogliere l'occasione per ringraziare gli sviluppatori per il loro lavoro con CopyTicks!
Non posso affermare che CopyTicks funziona in modo assolutamente corretto, ma sono riuscito a lavorare perfettamente con il nastro e a capire CopyTicks più a fondo.
Per non reinventare la ruota, puoi vedere esempi di scrittura di indicatori di tick basati sul nastro qui e qui.