L'apprentissage automatique dans la négociation : théorie, modèles, pratique et algo-trading - page 1850

Nouveau commentaire
 
Aleksey Vyazmikin:

Êtes-vous d'accord qu'au moment de l'ouverture de la barre minute, l'OI doit être pris pour l'entrée précédente ? Par exemple, nous prenons l'ouverture à 10h00 comme 23:49:55.

Je pense qu'il est préférable d'utiliser l'indicateur sur M1 et de prendre toutes les informations nécessaires à partir de la barre zéro et de faire différentes comparaisons dans le Conseiller Expert en considérant la demande d'informations du tampon de l'indicateur avec le décalage requis.

Quelle est la troisième valeur du fichier - la première est la date, la deuxième est OM et la troisième est OI ? Je pensais que c'était un delta mais ça ne marche pas.

J'ai essayé de modifier l'indicateur comme je l'ai écrit ci-dessus, il lit et affiche l'OM, la vitesse de travail est beaucoup plus rapide maintenant, essayez juste de le vérifier.

Oui, et la lecture depuis un fichier devrait fonctionner en cas d'interruption des données et de présence de données dans le fichier, mais le marché est fermé et je ne l'ai pas vérifié.

Cela n'a pas vraiment d'importance. Il est important que les données écrites soient toujours chargées correctement dans l'indicateur. Le problème est que de telles erreurs sont autorisées avant que le fichier de formation n'ait été sauvegardé. Si nous spécifions cette règle, qu'il en soit ainsi, le plus important est que l'indicateur réel exécute cette règle correctement.

Alexey, merci pour l'indicateur, mais j'ai une question sur un conseiller expert en temps réel. Si vous ne savez pas quoi en faire, vous devez le marquer une fois par minute et non pas après chaque changement de MO dans une minute ?

Je n'utilise pas la barre de zéro dans mon travail. De plus, j'effectue tous les calculs 30 secondes après le signal sur la première barre. Par conséquent, aucun calcul n'est effectué entre le signal. Mais le signal sur la première barre dans 30 secondes s'applique à tous les indicateurs qui participent au modèle et en théorie ces indicateurs devraient calculer tout l'historique depuis la dernière référence (signal) jusqu'à l'actuel à condition qu'ils ne soient pas dans le graphique. C'est le trou que l'indicateur doit lire du fichier afin d'obtenir la valeur actuelle avec précision.

Le fait est que j'utilise des données dépendantes des citations (c'est ainsi que je les ai nommées moi-même :-)) qui sont sensibles aux lacunes et aux trous dans l'histoire.

Aidez-moi à apporter le code des indicateurs que j'utilise et je vous remercierai en vous donnant quelques idées clés pour la préparation des kits de formation. + J'ai 37 livres sur mon service, je vous les donnerai sans problème. Mais seulement à condition que la fiabilité totale des données soit assurée dans le fonctionnement réel de l'EA.

Le principal problème que j'ai est que lorsque j'alimente mon EA avec AI sur un graphique et que j'obtiens un nouveau signal, je dois le recompiler et ensuite il demandera les données adéquates aux indicateurs. Mais le problème se situe au niveau des indicateurs. Je les envoie à un graphique, il affiche l'historique correctement et continue à présenter des données. Je le recompile après un certain temps et la queue qui a été dessinée sur le compte réel change de valeur.

Il existe également un indicateur de delta cumulatif qui calcule correctement par rapport aux barres. Cependant, lorsque l'historique de cet indicateur est long, il est de 3 mois sur М5, il n'a pas le temps d'être calculé pour un cycle car il prend les données de copitic, qui lui-même comprend combien de cycles il obtient.

Récemment, la mise à jour a commencé à consommer de la mémoire lors de la création d'un fichier d'entraînement, car elle est demandée pour 14 instruments dans un historique de 3 à 6 mois. Par conséquent, 8 gigs de RAM ne sont tout simplement pas suffisants. Et cet outil écrit zéro barre en temps réel, ce dont je n'ai pas besoin. Il me suffit de ne charger que le premier lorsque la barre de zéro apparaît.

Si vous voulez donner un coup de main, n'hésitez pas à me contacter et à négocier. Merci !!!!

Dossiers :
CumDelta.mq5  55 kb
 
Mihail Marchukajtes:

Cela n'a pas vraiment d'importance. L'important est que les données enregistrées soient toujours chargées correctement dans l'indicateur. Le fait est que de telles erreurs sont acceptables avant que le fichier de formation ne soit sauvegardé. Si nous spécifions cette règle, qu'il en soit ainsi, le plus important est que l'indicateur réel exécute cette règle correctement.

Alexey, merci pour l'indicateur, mais j'ai une question sur un conseiller expert en temps réel. S'il n'est pas utilisé, il enregistrera chaque minute et non chaque changement d'OM dans la minute.

Je n'utilise pas la barre de zéro dans mon travail. De plus, j'effectue tous les calculs 30 secondes après le signal sur la première barre. Par conséquent, il n'y a aucun calcul entre le signal. Mais le signal sur la première barre dans 30 secondes s'applique à tous les indicateurs qui participent au modèle et en théorie ces indicateurs devraient calculer tout l'historique depuis la dernière référence (signal) jusqu'à l'actuel à condition qu'ils ne soient pas dans le graphique. C'est le trou que l'indicateur doit lire du fichier afin d'obtenir correctement la valeur actuelle.

Le fait est que nous ne pouvons pas reproduire parfaitement la formation et l'application, surtout sur un marché rapide. Il s'avère maintenant que le retard est de 10 secondes par rapport aux nouvelles données (si nous parlons de l'historique) et si nous analysons uniquement l'ouverture de la barre, le retard sera de 60 secondes ou plus. Si nous travaillons avec des données obtenues à l'ouverture de la barre (non décalée), il y aura une erreur dans l'indicateur, c'est-à-dire que nous pourrons avoir un aperçu du futur. En général, nous devons réfléchir à nouveau à l'idéologie, maintenant les données sont plus récentes, mais tout cela reste de la théorie. Il peut suffire de prendre les données enregistrées lorsqu'une nouvelle barre apparaît et de s'entraîner sur cette base.

Eh bien, nous pouvons créer un script qui supprimera simplement les lignes inutiles en une minute et la taille du fichier sera 10 fois inférieure.

Mihail Marchukajtes:

Le problème principal est que lorsque j'envoie l'EA avec l'AI sur un graphique et que j'obtiens un nouveau signal, je dois le recompiler et ensuite il demandera les données adéquates aux indicateurs. Mais le problème se situe au niveau des indicateurs. Je les envoie à un graphique, il affiche l'historique correctement et continue à présenter des données. Je le recompile après un certain temps et la queue qui a été dessinée sur le compte réel change ses valeurs.

Essayez la version de l'indicateur que j'ai donnée. Si le problème persiste, il se situe probablement dans l'EA, et non dans les indicateurs. Veuillez montrer le code pour obtenir les données de l'indicateur.

 
Mihail Marchukajtes:
Si la rupture est globale depuis le courtier, nous ne pouvons rien y faire. Le conseiller pour la sauvegarde des données se trouve sur le serveur de l'UPU et les données ont été écrites sans aucune perte.

Maintenant, il est prévu que le conseiller enregistre les données en parallèle avec le travail de l'indicateur et du conseiller de trading, ainsi lorsque la connexion est perdue ou que le terminal est fermé, les nouvelles données historiques seront prises dans le fichier, cela permettra de continuer à travailler en urgence et ensuite de remplacer le fichier par le VPS et de redémarrer le conseiller.

 
Mihail Marchukajtes:

\Alexey, merci pour l'indicateur, mais j'ai une question concernant le conseiller expert. Est-il possible de le faire écrire à la minute, mais pas à chaque changement d'OM dans la minute ?

Si vous ne pensez pas trop, vérifiez cette variante

   MqlTick last_tick;
   if(SymbolInfoTick(Name_instrFS,last_tick))
      StartDate=last_tick.time;
   else StartDate=TimeCurrent();
   if(isNewBar(Name_instrFS,0,PERIOD_M1))
   {
      for (int i=0; i<100 && !IsStopped(); i++)
      {
         h=FileOpen("OpenI\\"+Name_instr+"_OI.csv",FILE_WRITE|FILE_READ|FILE_ANSI|FILE_CSV|FILE_COMMON|FILE_SHARE_READ,",");
         if(h!=INVALID_HANDLE)
         {

            FileSeek(h,0,SEEK_END);
            FileWrite(h,StartDate,DoubleToString(interest,0));
            FileClose(h);
            Sleep(100);
            break;
         }
      }
      //inter=interest;
      // byOR=byORD;
      // sellOR=sellORD;
   }
 
Aleksey Vyazmikin:

Si ça ne vous dérange pas trop, vérifiez.

Alexey, merci beaucoup. Je vais sûrement le vérifier et vous informer des résultats. Pour ce qui est de se projeter dans l'avenir, cela n'a pas d'importance et ne se produira pas si l'EA s'écrit de la même manière que l'indicateur. S'il n'y a pas de différence entre eux, cela n'aura aucune importance. Alternativement, lorsqu'une nouvelle barre apparaît, nous attendons le premier changement d'OI et enregistrons la nouvelle valeur pour la première barre précédente. Nous pouvons même enregistrer non pas une nouvelle valeur, mais l'ancienne qui était la dernière pour la première barre. C'est-à-dire qu'en fait, nous commencerons à l'écrire à la fin de la mesure précédente.

L'important n'est pas l'OI que nous attribuons à la barre minute, mais la façon dont l'indicateur est lu dans le fichier.

 
Mihail Marchukajtes:

Alexei, merci beaucoup. Je vais certainement tout vérifier et vous faire part du résultat. Quant à l'anticipation, elle est absolument sans importance et ne se produira pas si l'EA écrit comme l'indicateur le lit. S'il n'y a pas de différence entre eux, cela n'aura aucune importance. Alternativement, lorsqu'une nouvelle barre apparaît, nous attendons le premier changement d'OI et enregistrons la nouvelle valeur pour la première barre précédente. Nous pouvons même enregistrer non pas une nouvelle valeur, mais l'ancienne qui était la dernière pour la première barre. C'est-à-dire qu'en fait, nous commencerons à l'écrire à la fin de la mesure précédente.

L'important n'est pas l'OI que nous allons attribuer à la barre minute, mais la façon dont l'indicateur sera lu dans le fichier.

Veuillez regarder le code complet et demander

interest=SymbolInfoDouble(Name_instrFS,SYMBOL_SESSION_INTEREST); 


  if ((interest!=inter))
  {

   MqlTick last_tick;
   /*if(SymbolInfoTick(Name_instrFS,last_tick)) 
    StartDate=last_tick.time;
    else StartDate=TimeCurrent();*/
    StartDate=iTime(Name_instrFS,PERIOD_M1,1);
  if(isNewBar(Name_instrFS,0,PERIOD_M1))
   {  
    for (int i=0;i<100 && !IsStopped();i++)
    { 
      h=FileOpen("OpenI\\"+Name_instr+"_OI.csv",FILE_WRITE|FILE_READ|FILE_ANSI|FILE_CSV|FILE_COMMON|FILE_SHARE_READ,",");
       if(h!=INVALID_HANDLE)                                                         
       {  
         
         FileSeek(h,0,SEEK_END);
         FileWrite(h,StartDate,DoubleToString(inter,0)); 
         FileClose(h); 
         Sleep(100);
         break; 
       }
    }   
    inter=interest;
   // byOR=byORD;
   // sellOR=sellORD;
  }
}


Si une nouvelle barre s'ouvre et qu'il n'y a pas de changement d'OI dans les 5 ticks, entrera-t-elle dans la condition de nouvelle barre ?

Je pense que cela devrait être le cas car ce sera le premier appel de la nouvelle fonction bar et ce n'est qu'après que le résultat sera transformé en falsh ? N'est-ce pas ?

 
J'ai simulé le travail du code dans ma tête et j'ai trouvé un goulot d'étranglement. La dernière barre de la session d'hier sera écrite au premier changement à l'ouverture de la barre minute de la session d'aujourd'hui, en cas de réinitialisation de l'EA, la valeur OI sera perdue, ce qui conduira à une entrée zéro désagréable dans la dernière barre de la session d'hier. Je pense que la solution n'est toujours pas d'écrire la valeur précédente de l'OM dans la première barre, mais exactement l'OM actuel, c'est-à-dire celui qui sera le premier dans la nouvelle barre. Ok, je voulais les synchroniser parfaitement, mais je pense que ça ira comme ça... Alors... je pense tout haut...
 
Aleksey Vyazmikin:

C'est le problème, on ne peut pas reproduire parfaitement la formation et l'application, surtout dans un marché rapide. Or, il s'avère que le délai peut atteindre 10 secondes par rapport aux nouvelles données (si nous parlons de l'historique), et si nous utilisons uniquement l'ouverture de la barre, le délai sera de 60 secondes ou plus. Si nous travaillons avec des données obtenues à l'ouverture de la barre (non décalée), il y aura une erreur dans l'indicateur, c'est-à-dire que nous pourrons avoir un aperçu du futur. En général, il est nécessaire de réfléchir à nouveau à l'idéologie, maintenant les données sont plus récentes, mais tout cela reste de la théorie. Il peut suffire de prendre les données enregistrées lorsqu'une nouvelle barre apparaît et de s'entraîner sur cette base.

Eh bien, nous pouvons créer un script qui supprime simplement les lignes inutiles en une minute et la taille du fichier sera 10 fois moindre.

Essayez la version de l'indicateur que j'ai donnée. Si le problème persiste, il se situe probablement dans l'EA et non dans les indicateurs. Veuillez montrer le code pour obtenir les données de l'indicateur.

J'ai vérifié l'indicateur sur l'historique et j'ai obtenu une erreur. Le problème est que le premier chandelier d'une minute affiche l'heure 10:00 dans la fenêtre de cotation, mais la valeur de ce chandelier est tirée du chandelier précédent. C'est-à-dire que la bougie s'est ouverte à 10:00:00 et s'est fermée à 10:00:59. C'est la valeur qui doit être écrite, n'est-ce pas ? Et l'indicateur pendant la construction prend la valeur de la barre de 23:59:59.
 
Mihail Marchukajtes:
J'ai vérifié l'indicateur sur l'historique et l'erreur est évidente. Le problème est que le premier chandelier d'une minute affiche l'heure 10:00 dans la fenêtre de cotation, mais la valeur de ce chandelier est tirée du chandelier précédent. Cela signifie que la bougie s'est ouverte à 10:00:00 et s'est fermée à 10:00:59. C'est la valeur que nous devons écrire, n'est-ce pas ? Et l'indicateur prend la valeur de 23:59:59 lors du tracé de la barre.
Je l'ai fait. Maintenant, peu importe que le fichier soit écrit par minute ou par tick, il écrira les valeurs correctes pour la bougie. C'est-à-dire que si un chandelier a un temps ouvert, nous y inscrivons la valeur à la clôture de ce chandelier...
 
Mihail Marchukajtes:
J'ai vérifié l'indicateur sur l'historique et l'erreur est évidente. Le problème est que le premier chandelier d'une minute affiche l'heure 10:00 dans la fenêtre de cotation, mais la valeur de ce chandelier est tirée du chandelier précédent. C'est-à-dire que la bougie s'est ouverte à 10:00:00 et s'est fermée à 10:00:59. C'est la valeur qui doit être écrite, n'est-ce pas ? Et l'indicateur prend la valeur de 23:59:59 lors de la construction de la barre.

Si l'EA travaille sur l'ouverture de la barre, même si c'est avec un retard, est-il correct de l'alimenter avec les données de la fermeture de la bougie, c'est-à-dire de regarder dans le futur ? C'est pourquoi on utilise les données les plus récentes avant ce chandelier, c'est-à-dire un petit délai, au lieu de prendre de l'avance.


Mihail Marchukajtes:

Veuillez examiner le code complet et demander


Si une nouvelle barre s'ouvre et qu'il n'y a pas de changement d'OI dans les 5 ticks, entre-t-elle dans la condition d'une nouvelle barre ?

Je pense qu'il devrait car ce sera le premier appel de la fonction de la nouvelle barre et seulement après cela le résultat se transformera en falsh ? N'est-ce pas ?

Où est le comptage des 5 ticks ici ? Il arrive qu'au cours d'une minute entière il n'y ait pas de transaction, et alors vous manquez la barre, et c'est pourquoi j'ai supprimé la comparaison pour les changements d'OI, de sorte que les données sont écrites immédiatement à l'ouverture d'une nouvelle bougie. J'ai peut-être raté quelque chose, j'aurais dû le tester avec des données mais je ne les avais pas hier et c'est en semaine :(

1...184318441845184618471848184918501851185218531854185518561857...3399
Nouveau commentaire
Raison: