J'ai fortement consigné le code ci-dessus et j'en ai compris les raisons. Si CopyTicks (from > 0) obtient des ticks avant le plus récent, il peut en sauter certains.
Une réponse très importante du Service Desk.
En ce qui concerne le problème original - que CopyTicks sur le prochain appel peut donner plus de ticks pour la même période :
C'est effectivement le cas. Le problème est que les flux de données d'échange bid/ask et flipper/volume sont des flux différents, qui ne sont pas synchronisés les uns avec les autres déjà du côté de l'échange.
Pour cette raison, il y a des situations dans lesquelles il y a d'abord un appel d'offres avec le temps 12:12:12.300, et un peu plus tard un appel d'offres avec le temps 12:12:12.299.
Par conséquent, si vous demandez des données depuis le dernier tick (12:12:12.300), vous n'obtiendrez pas de nouveau flipper pour 12:12:12.299.
PS. Le terminal enregistre et envoie les ticks triés par heure. C'est-à-dire que la séquence temporelle des ticks donnés à CopyTicks est toujours croissante.
Il y a deux flux de réception de ticks - INFO et TRADE. TOUT est une union synthétisée (semble être du côté des terminaux), c'est pourquoi de telles mésaventures peuvent se produire.
C'est à cause de la synthèse qu'il y a eu de tels mots...
Slawa:
les enregistrements initiaux de tick après l'appel de CopyTicks ne contiendront pas de zéros, mais les valeurs actuelles de bid, ask et last au moment demandé.
Ainsi, lorsque vous travaillez avec TOUTES les tiques, vous devez être clairement conscient de ce à quoi vous avez affaire. Il est possible que les drapeaux à tiques soient également synthétisés. Je voudrais une spécificité complète sur ces questions.
Avec la bande, ce problème ne devrait pas se poser si CopyTicks fonctionne correctement.
Je pense que l'aide sera très sérieusement complétée.
fxsaber: Vous pouvez ajouter vous-même les surcharges éventuelles.
Je peux faire beaucoup, vous pouvez faire beaucoup, d'autres programmeurs peuvent faire beaucoup aussi, mais avec un peu de chance, les développeurs connaissent mieux le "stuffing" et peuvent créer des algorithmes rapides pour obtenir les tics nécessaires.
J'ai fortement consigné le code ci-dessus et j'en ai compris les raisons. Si CopyTicks (de > 0) obtient des ticks jusqu'au plus récent, il peut en sauter certains.
Exemple.
Ticks demandés avec de = 2016.09.29 11:05:55.564. J'ai eu trois ticks en réponse
Quelque temps plus tard, j'ai demandé l'historique des ticks à distance et j'ai obtenu un tick, que CopyTicks avait manqué auparavant.
Quel insecte !
Il semble qu'il y ait un conflit entre l'écriture et la lecture simultanées dans la base de données des tics.
1434 est le même bug pour les types TRADE. Reproduction du conseiller expert
#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");
}
}
Résultat
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
L'historique des tics en temps réel du fil TRADE ne contenait pas de tic avec l'heure 2016.10.04 10:37:08.773, qui est apparu plus tard dans l'historique.
Cela est quelque peu contradictoire avec ce que j'ai dit plus haut. Les problèmes ne concernent pas seulement le flux synthétisé ALL-flow, mais aussi le flux direct - TRADE.
Je voudrais profiter de cette occasion pour remercier les développeurs pour leur travail avec CopyTicks !
Je ne peux pas prétendre que CopyTicks fonctionne absolument correctement, mais j'ai réussi à travailler avec la bande parfaitement et à comprendre CopyTicks plus profondément.
Pour ne pas réinventer la roue, vous pouvez voir des exemples précis d'écriture d'indicateurs en tic-tac basés sur la bande ici et ici.
1434 - 1ms en moyenne prend pour obtenir CopyTicks déjà téléchargé 1000 ticks. Lentement, il semble.
Demande de TRADE0tic avec from_msc du dernier tick reçu précédemment. J'obtiens 3 ticks, mais en 0.3 - 0.9ms ! - Très lent maintenant.
J'ai fortement consigné le code ci-dessus et j'en ai compris les raisons. Si CopyTicks (from > 0) obtient des ticks avant le plus récent, il peut en sauter certains.
En ce qui concerne le problème original - que CopyTicks sur le prochain appel peut donner plus de ticks pour la même période :
C'est effectivement le cas. Le problème est que les flux de données d'échange bid/ask et flipper/volume sont des flux différents, qui ne sont pas synchronisés les uns avec les autres déjà du côté de l'échange.
Pour cette raison, il y a des situations dans lesquelles il y a d'abord un appel d'offres avec le temps 12:12:12.300, et un peu plus tard un appel d'offres avec le temps 12:12:12.299.
Par conséquent, si vous demandez des données depuis le dernier tick (12:12:12.300), vous n'obtiendrez pas de nouveau flipper pour 12:12:12.299.
PS. Le terminal enregistre et envoie les ticks triés par heure. C'est-à-dire que la séquence temporelle des ticks donnés à CopyTicks est toujours croissante.
Il y a deux flux de réception de ticks - INFO et TRADE. TOUT est une union synthétisée (semble être du côté des terminaux), c'est pourquoi de telles mésaventures peuvent se produire.
C'est à cause de la synthèse qu'il y a eu de tels mots...
les enregistrements initiaux de tick après l'appel de CopyTicks ne contiendront pas de zéros, mais les valeurs actuelles de bid, ask et last au moment demandé.
Avec la bande, ce problème ne devrait pas se poser si CopyTicks fonctionne correctement.
Je pense que l'aide sera très sérieusement complétée.
Vous pouvez ajouter vous-même les surcharges éventuelles.
Testé CopyTicks avec le drapeau COPY_TICKS_TRADE
Aucune différence.
Testé CopyTicks avec le drapeau COPY_TICKS_TRADE
Aucune différence.
Forum sur le trading, les systèmes de trading automatisés et le testeur de stratégie
Indicateur boursier mystérieux
fxsaber, 2016.09.30 21:26
1434 - le problème n'a pas été résolu.
J'ai fortement consigné le code ci-dessus et j'en ai compris les raisons. Si CopyTicks (de > 0) obtient des ticks jusqu'au plus récent, il peut en sauter certains.
Exemple.
Ticks demandés avec de = 2016.09.29 11:05:55.564. J'ai eu trois ticks en réponse
Quelque temps plus tard, j'ai demandé l'historique des ticks à distance et j'ai obtenu un tick, que CopyTicks avait manqué auparavant.
Quel insecte !
Il semble qu'il y ait un conflit entre l'écriture et la lecture simultanées dans la base de données des tics.
L'historique des tics en temps réel du fil TRADE ne contenait pas de tic avec l'heure 2016.10.04 10:37:08.773, qui est apparu plus tard dans l'historique.
Cela est quelque peu contradictoire avec ce que j'ai dit plus haut. Les problèmes ne concernent pas seulement le flux synthétisé ALL-flow, mais aussi le flux direct - TRADE.
1434 est le même bug pour les types TRADE. Conseiller en reproduction
1434 - 1ms en moyenne prend pour obtenir CopyTicks déjà téléchargé 1000 ticks. Lentement, il semble.
Demande de TRADE0tic avec from_msc du dernier tick reçu précédemment. J'obtiens 3 ticks, mais en 0.3 - 0.9ms ! - Très lent maintenant.
Pertinent ! Aucun moyen d'accélérer le processus ?
Je voudrais profiter de cette occasion pour remercier les développeurs pour leur travail avec CopyTicks !
Je ne peux pas prétendre que CopyTicks fonctionne absolument correctement, mais j'ai réussi à travailler avec la bande parfaitement et à comprendre CopyTicks plus profondément.
Pour ne pas réinventer la roue, vous pouvez voir des exemples précis d'écriture d'indicateurs en tic-tac basés sur la bande ici et ici.