FORTS Veuillez nous aider - page 9

Nouveau commentaire
 
komposter:

Quelle est la différence entre "pas" et "pas prêt" pour le programme (et le programmeur) ?

Si les données ne sont pas prêtes, il y aura une erreur.

Ou peut-être que cette information n'est pas non plus disponible instantanément, c'est pourquoi elle n'est pas affichée.

Et afin d'éviter de "rentrer" dans le serveur.

Aussi, vous êtes notre "lecteur"... Question :

Pourquoi construire les séries chronologiques si les données sont prêtes ( CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times) ) ?

Если мы успешно прошли все проверки, то сделаем последнюю попытку обойтись без обращения к торговому серверу. Сначала узнаем начальную дату, для которой доступны минутные данные в формате HCC.
Запросим это значение функцией SeriesInfoInteger() с модификатором SERIES_TERMINAL_FIRSTDATE и опять сравним со значением параметра start_date.

   if(SeriesInfoInteger(symbol,PERIOD_M1,SERIES_TERMINAL_FIRSTDATE,first_date))
     {
      //--- there is loaded data to build timeseries
      if(first_date>0)
        {
         //--- force timeseries build                                            
         CopyTime(symbol,period,first_date+PeriodSeconds(period),1,times);
         //--- check date
         if(SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date))
            if(first_date>0 && first_date<=start_date) return(2);
        }
     }
 
MigVRN:
C'est exact - il charge et prépare ce qui est là. Mais étant donné que tout retard dans l'indicateur ralentit le chat avec tout ce qui en dépend - nous avons fait en sorte que dans les indicateurs si la série n'est pas prête au moment de l'appel - la fonction renvoie une erreur et INITIALISE la préparation des données. Après un certain temps, il ne retournera plus d'erreur. C'est ce qui se passe dans vos journaux.

MigVRN !

Chukcha a relu l'aide et n'est PAS d'accord avec vous.

"C'est exact - ilcharge et prépare à la fois ce qui est là."

C'est votre spéculation....

Mais l'aide indique que la fonction SeriesInfoInteger avec l'identifiantSERIES_TERMINAL_FIRSTDATE

Il devrait revenir :

SÉRIE_TERMINALE_PREMIÈRE DATE

Première date de l'historique par symbole dans le terminal du client, quelle que soit la période.

Il ne doit rien préparer !

Il existe des données dans l'historique du terminal - obtenez la date.

Non - il renvoie "0".

 
Un nouveau jour et un tour et encore un tour.
 
barabashkakvn:
Un nouveau jour et un tour et encore un tour.
Montrer dans la référence, quelque chose d'AUTRE
 
papaklass:
Préparez les données et travaillez avec elles. Vous pouvez dire 150 fois que quelque chose ne va pas, et obtenir 150 réponses sur ce qu'il faut faire. C'est votre travail, alors prenez soin de vous !

Merci, mais vous savez très bien que TOUT doit être prouvé.

SD pense que retourner 0, lorsque les données sont présentes, n'est pas une erreur de leur fonction.

Si c'est le cas, cela DOIT être écrit dans la documentation !

 

Mikalas:

Devrait, ne devrait pas - c'est tout ce dont nous parlons. Vous pouvez voir par vous-même comment cela fonctionne :)

Le seul point sur lequel je peux être d'accord est qu'il n'est pas tout à fait clair quelles données sont prêtes TOUT DE SUITE (disponibles à tout moment) et quelles données le terminal prépare lorsque vous y accédez.

Je( !) comprends que lorsqu'on accède à des données de séries temporelles (temps et prix, nombre de barres, énumérationENUM_SERIES_INFO_INTEGER, ou peut-être ai-je oublié autre chose), les données ne sont pas prêtes immédiatement.

Pour éviter de telles situations, c'est écrit dans l'aide :

Comme le programme mql5 peut accéder aux données de n'importe quel symbole et de n'importe quelle période, il est possible que les données d'une période donnée n'aient pas encore été générées dans le terminal, ou que les données de prix requises ne soient pas synchronisées avec le serveur de négociation. Dans ce cas, le temps d'attente de la préparation des données est difficile à prévoir.

Lesalgorithmes utilisant des cycles d'attente de disponibilité des données ne sont pas la meilleure solution. La seule exception dans ce cas - les scripts, car ils n'ont pas d'autre choix d'algorithme, en raison de l'absence de traitement des événements. Pour les indicateurs personnalisés, de tels algorithmes, ainsi que toute autre boucle d'attente, sont catégoriquement déconseillés, car ils entraînent l'arrêt du calcul de tous les indicateurs et autres traitements de données de prix pour ce symbole.

Pour les conseillers experts et les indicateurs personnalisés, il est préférable d'utiliserle modèle de traitementbasé sur les événements. Si le traitement des événements OnTick() ou OnCalculate() n'a pas réussi à obtenir toutes les données nécessaires de la série chronologique requise, vous devez quitter le gestionnaire d'événements, en espérant avoir accès aux données lors du prochain appel du gestionnaire.

 
MigVRN:

Devrait, ne devrait pas - c'est tout ce dont nous parlons. Vous pouvez voir par vous-même comment cela fonctionne :)

Le seul point sur lequel je peux être d'accord est qu'il n'est pas tout à fait clair quelles données sont prêtes TOUT DE SUITE (disponibles à tout moment) et quelles données le terminal prépare lorsque vous y accédez.

Je( !) comprends que lorsqu'on accède à des données de séries temporelles (temps et prix, nombre de barres, énumérationENUM_SERIES_INFO_INTEGER, ou peut-être ai-je oublié autre chose), les données ne sont pas prêtes immédiatement.

Pour éviter de telles situations, c'est écrit dans l'aide :

Comme le programme mql5 peut accéder aux données de n'importe quel symbole et de n'importe quelle période, il est possible que les données d'une période donnée n'aient pas encore été générées dans le terminal, ou que les données de prix requises ne soient pas synchronisées avec le serveur de négociation. Dans ce cas, le temps d'attente de la préparation des données est difficile à prévoir.

Lesalgorithmes utilisant des cycles d'attente de disponibilité des données ne sont pas la meilleure solution. La seule exception dans ce cas - les scripts, car ils n'ont pas d'autre choix d'algorithme, en raison de l'absence de traitement des événements. Pour les indicateurs personnalisés, de tels algorithmes, ainsi que toute autre boucle d'attente, sont catégoriquement déconseillés, car ils entraînent l'arrêt du calcul de tous les indicateurs et autres traitements de données de prix pour ce symbole.

Pour les conseillers experts et les indicateurs personnalisés, il est préférable d'utiliserle modèle de traitementbasé sur les événements. Si, pendant le traitement des événements OnTick() ou OnCalculate(), vous n'avez pas réussi à obtenir toutes les données nécessaires de la série chronologique requise, vous devez quitter le gestionnaire d'événements, en espérant avoir accès aux données lors du prochain appel du gestionnaire.

Andrew !

Je ne sais pas pour vous, mais je travaille avec la documentation depuis de nombreuses années.

Regardez, d'après la documentation, il suit, comme je( !) l'ai compris.

1. Vérifions s'il existe des données historiques pour le symbole dans le terminal (SeriesInfoInteger avec l'identificateurSERIES_TERMINAL_FIRSTDATE).

Peut-être, je ne discute pas de ça, ça construit et initialise quelque chose.

2. Pas de données (renvoie une date de début d'historique vide) - va chercher les données sur le serveur.

S'il y a une date, nous construisons l'intervalle de temps spécifié en utilisant la fonctionCopyTime(symbol,period,first_date+PeriodSeconds(period),1,times);

4. Nous vérifions le début de la série chronologique avec la date donnée(SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date).

C'est écrit dans la documentation.

Mais lorsque je( !) demande des données historiques par symbole(pas par série temporelle !!!!) dans le terminal, qui sont EXACTEMENT là

renvoie "0".

Pensez-vous que c'est juste ?

 
Mikalas:

MAIS, lorsque je( !) demande des données historiques par symbole(et non par série temporelle !!!!) dans le terminal, ce qui est EXACTEMENT le cas

la fonction renvoie "0".

Pensez-vous que c'est juste ?

Les données (non préparées) sont sur le disque. Les données (préparées) peuvent se trouver sur le chat adjacent. Mais il n'y a pas de données préparées sur le chat qui exécute l'indirection. Il y a donc une erreur. C'est correct. Mais ce n'est pas pratique :)

Bien que je n'aime pas moi-même ce genre de questions, est-il essentiel pour vous de demander les données de l'indicateur pour les caractères adjacents ? (en tenant compte de ce qui est écrit dans l'aide et de mon exemple - comment un indicateur peut ralentir l'exécution du conseiller expert et du chat). Vous pouvez contourner toutes ces difficultés...

 
papaklass:

Vous demandez "FIRSDDATE", pas des données. La date est probablement présente, mais les données peuvent manquer pour des raisons économiques. Pourquoi pomper des données pour tous les personnages s'ils ne sont pas utilisés pour le moment. Les développeurs ont pris la voie rationnelle de ne pomper les données que lorsque l'utilisateur accède à ces données. C'est l'approche normale. Vous, qui travaillez avec le terminal, devez le SAVOIR et agir en conséquence.

Au lieu de perdre votre temps à faire du commerce, vous êtes bloqué sur des trucs élémentaires et vous perdez votre temps. Ménagez votre temps. :)

Les robots tradent pour moi, je ne suis pas à la maison en ce moment...

Et j'ai besoin d'un indicateur juste pour améliorer mon trading :)

 
Mikalas:

Andrei !

Je ne sais pas pour vous, mais je travaille avec la documentation depuis de nombreuses années.

Regardez, d'après la documentation, il suit, comme je( !) le comprends.

1. Voyons s'il existe des données historiques sur le symbole dans le terminal (SeriesInfoInteger avec l'identificateurSERIES_TERMINAL_FIRSTDATE).

Peut-être, je ne discute pas de ça, ça construit et initialise quelque chose.

2. Pas de données (renvoie une date de début d'historique vide) - va chercher les données sur le serveur.

S'il y a une date, nous construisons le cadre temporel spécifié en utilisant la fonctionCopyTime(symbol,period,first_date+PeriodSeconds(period),1,times);

4. Nous vérifions le début de la série chronologique avec la date donnée(SeriesInfoInteger(symbol,period,SERIES_FIRSTDATE,first_date).

C'est écrit dans la documentation.

Mais lorsque je( !) demande des données historiques par symbole(pas par série temporelle !!!!) dans le terminal, qui sont EXACTEMENT là

renvoie "0".

Pensez-vous que c'est juste ?

Lisez la documentation plus attentivement, et non de manière sélective. La présence de données historiques sur le disque ne signifie pas "qu'elles sont bien là" pour le terminal. Dans ce cas (lorsqu'on y accède depuis l'indicateur), les fonctions ne fonctionnent qu'avec le cache des séries temporelles en mémoire. Cela signifie qu'un accès synchrone à la mémoire est effectué et que s'il n'y a pas de série chronologique préparée, la date SERIES_FIRSTDATE (du premier élément du tableau) ne sera pas renvoyée. Mais bien sûr, la demande initie la préparation - le chargement des séries temporelles en mémoire.

La demande SERIES_TERMINAL_FIRSTDATE est liée à l'initialisation de la base de données et à la synchronisation avec le serveur, donc le premier appel ne fonctionnera pas immédiatement de toute façon.

En principe, la possibilité d'obtenir l'historique requis est vérifiée à l'aide de SERIES_SERVER_FIRSTDATE . C'est-à-dire que vous pouvez bien sûr compter sur X itérations de demande d'historique, mais si le terminal confirme la présence d'historique via SERIES_SERVER_FIRSTDATE, alors la disponibilité des données de séries temporelles pertinentes n'est qu'une question de temps (synchronisation de la base de données m1 avec le serveur et génération des séries temporelles).

12345678910111213141516...31
Nouveau commentaire
Raison: