Bogue MQL5 lors du travail avec l'accès aux séries chronologiques iClose/iOpen, etc. - page 8

Nouveau commentaire
 
Slava:

Il est possible d'essayer de déterminer.

S'il s'agit de minutes, vous pouvez comparer l'heure de la dernière barre avec TimeCurrent(). Si ce n'est pas M1, vous pouvez demander iTime(_Symbol,PERIOD_M1,0) et comparer avec TimeCurrent().

Vous pouvez comparer le cours acheteur ou le dernier cours (selon le symbole) avec le cours de clôture de la dernière barre. Vous pouvez demander directement à SymbolInfoTick le symbole actuel. En plus de l'offre et de la demande, il y a aussi le temps de tic-tac.

Merci, au moins quelques informations sur où et comment chercher les bugs si quelque chose a mal tourné.

mais je pense, que tout de même besoin d'une fonction intégrée pour vérifier l'état, ou mieux encore, il devrait être un drapeau, comme int _LastError, qui stockerait le nombre de ticks manqués, il serait utile lors de l'appel OnCalculate() - dans les calculs complexes ne retour immédiat, pour libérer le flux du symbole

 
Igor Makanu:

Merci, au moins quelques informations sur où et comment chercher les bugs si quelque chose a mal tourné.

mais je pense, que tout de même besoin d'une fonction intégrée pour vérifier le statut, ou mieux encore, ce serait un drapeau, comme int _LastError, qui stockerait le nombre de ticks manqués, il serait pratique lors de l'appel OnCalculate() - dans les calculs complexes faire immédiatement retour, pour libérer le flux de symboles

pensé, réfléchi.... ce n'est pas la solution. que sera la connaissance des ticks manqués (Slava dit, qu'il est garanti que l'indicateur reçoit TOUS les ticks, et ce fait conduit à toutes les pendaisons non seulement des programmes MQL, mais même du terminal client) ? dans tous les cas, ces ticks devront être collectés et traités, et cela signifie, si nous avons manqué un tick, pourquoi espérer soudainement que la prochaine fois ce sera possible ? - c'est un cercle vicieux.

Je pensais... L'arrivée d'un nouveau tick devrait interrompre toutes les opérations, les calculs dans l'indicateur à ce moment-là, et toute fonction MQL standard devrait retourner une erreur pendant son exécution, si un nouveau tick arrive à ce moment-là ... Le travail avec l'indicateur devient alors clair, pratique et prévisible. Pour les autres types de programmes (scripts, Expert Advisors), il est presque inutile.

Et toutes sortes de vérifications de tics dans l'indicateur pour leur pertinence - pour dire les choses clairement, ce n'est pas la solution.

 

Nous avons une idée pour les indicateurs, qui ne contiennent pas le flag #property tester_everytick_calculate, d'inclure le mode de calcul basé sur la réception du paquet de ticks, au lieu de chaque tick.

Cela résoudra radicalement le problème des indicateurs lents, en préservant la possibilité d'un traitement garanti de chaque tick pour certains indicateurs.

 
Renat Fatkhullin:

Nous avons une idée pour les indicateurs, qui ne contiennent pas le flag #property tester_everytick_calculate, d'inclure le mode de calcul sur la base de la réception d'un paquet de ticks, au lieu de sur chaque tick.

Cela résoudra de façon spectaculaire le problème des indicateurs retardés, en préservant la possibilité d'un traitement garanti de chaque tick pour certains indicateurs.

Ainsi, vous serez en mesure d'avoir un indicateur très rapide avec un tel design ?

//+-------------------------------------------+
int OnInit() 
  {
  EventSetMillisecondTimer(200);
//-
  return(INIT_SUCCEEDED);
 }

//+-------------------------------------------+
int OnCalculate (const int rates_total,
                 const int prev_calculated,
                 const datetime& time[],
                 const double& open[],
                 const double& high[],
                 const double& low[],
                 const double& close[],
                 const long& tick_volume[],
                 const long& volume[],
                 const int& spread[])
 {
  // Здесь ничего не делаем, нам не нужен в данном случае OnCalculate
  return(rates_total);
 }

//+-------------------------------------------+
void OnTimer()
 {
  // Здесь расчёты, и вывод информации на график в виде графических объектов
 }

Si c'est le cas, c'est une excellente nouvelle !

 
Renat Fatkhullin:

Nous avons une idée pour les indicateurs, qui ne contiennent pas le flag #property tester_everytick_calculate, d'inclure le mode de calcul sur la base de l'acceptation du paquet de ticks, au lieu de chaque tick.

Cela résoudra radicalement le problème des indicateurs lents, en préservant la possibilité d'un traitement garanti de chaque tick pour certains indicateurs.

Et si vous faites une fonction standard pour obtenir un tableau multidevises synchronisé, ce sera une vraie fête.

 
Renat Fatkhullin:

Nous avons une idée pour les indicateurs, qui ne contiennent pas le flag #property tester_everytick_calculate, d'inclure le mode de calcul sur la base de la réception d'un paquet de ticks, au lieu de sur chaque tick.

Cela résoudra radicalement le problème des indicateurs lents, en préservant la possibilité du traitement garanti de chaque tick pour certains indicateurs.

Bonne idée !

Et de préférence, il devrait fonctionner sans aucune#propriété par défaut.

Si quelqu'un en a besoin autrement, alors qu'il mette#propriété.

 
La solution pour recevoir les ticks par paquets est bonne et probablement pas très chère, si nous n'avons pas besoin de temps réel (mais on ne sait pas comment les EA fonctionneront avec les indicateurs qui travaillent sur les prix "d'hier", mais passons).

Mais il existe une autre catégorie de problèmes - en temps réel, à chaque instant. Dans ce cas, soit vous avez le temps d'effectuer des calculs après un tick avant que le tick suivant n'arrive, soit vous ne l'avez pas, et alors la solution de trading ne sera pas pertinente (il n'y a pas de troisième voie). C'est pourquoi il n'y a qu'une seule façon correcte de résoudre le problème : interrompre tous les calculs en cours et renvoyer l'erreur lorsqu'un nouveau tick arrive. Sinon, on peut oublier le temps réel. Aujourd'hui, les ticks sont de plus en plus rapides chaque jour, et le chemin à parcourir est encore long. Il est donc nécessaire de planifier l'avenir, sans compter qu'il est impossible de traiter tous les ticks sans décalage dans le temps dans le présent.

 
_o0O:
La solution pour recevoir les ticks par paquets est bonne et probablement pas très chère, si nous n'avons pas besoin de temps réel (mais on ne sait pas comment les EA fonctionneront avec les indicateurs qui travaillent sur les prix "d'hier", mais passons).

Mais il existe un autre type de tâches - en temps réel, à chaque instant. Soit vous avez le temps d'effectuer des estimations après la réception d'un tick, soit vous ne l'avez pas, et la solution commerciale ne sera pas pertinente (il n'y a pas de troisième alternative). C'est pourquoi il n'y a qu'une seule façon correcte de résoudre le problème : interrompre tous les calculs en cours et renvoyer l'erreur lorsqu'un nouveau tick arrive. Sinon, on peut oublier le temps réel. Aujourd'hui, les ticks sont de plus en plus rapides chaque jour, et le chemin à parcourir est encore long. Il est donc nécessaire de planifier l'avenir, sans compter qu'il est impossible de traiter tous les ticks sans décalage dans le temps dans le présent.

La plupart des indicateurs EAs travaillent avec des barres fermées[1], c'est pourquoi le saut des ticks n'a pas d'importance, c'est le cas pour les indicateurs travaillant avec des ticks, mais ils ne sont pas nombreux, ils peuvent juste être alloués"#property tester_everytick_calculate".

Et encore une fois, si vous avez besoin de super-crochets, vous n'avez pas besoin d'un indicateur pour cela, tout cela peut être écrit dans le code du conseiller expert. Il n'est donc pas raisonnable de ralentir le travail de l'indicateur au nom de chaque tick.

Nous attendons"#property tester_everytick_calculate".

 
Vitaly Muzichenko:

La plupart des indicateurs EAs travaillent avec des barres fermées[1], c'est pourquoi le saut des ticks n'a pas d'importance, c'est le cas pour les indicateurs travaillant avec des ticks, mais ils ne sont pas nombreux, ils peuvent juste être alloués"#property tester_everytick_calculate".

Et encore une fois, si vous avez besoin de super-crochets, vous n'avez pas besoin d'un indicateur pour cela, tout cela peut être écrit dans le code du conseiller expert. Il n'est donc pas raisonnable de ralentir le travail de l'indicateur au nom de chaque tick.

En attente de"#property tester_everytick_calculate"


OK, et en quoi ce que tu as dit est en désaccord avec ce que j'ai dit ?
 
Cela peut être utile à quelqu'un. J'ai un indicateur multi-devises, donc les principaux calculs capacitifs je les fais dans le bloc d'initialisation et seulement le rendu dans oncalculus. Mais c'est une solution pour les situations où les lignes de l'indicateur elles-mêmes ne contiennent pas de calculs complexes. Dans mon cas, c'est un indicateur de portefeuille qui affiche un graphique du comportement du portefeuille.
12345678910
Nouveau commentaire