La décélération linéaire est-elle une erreur de programmation ou une caractéristique de MT4 ? - page 9
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Je n'ai pas à me plaindre de vous.
Le papaklass non plus.
Vous êtes son avocat ?
Vous êtes son procureur ? Je n'ai pas aimé le fait que vous pensiez que vous pouviez le dire pour lui, mais pas pour vous, et que vous ne pouvez pas le dire ici, mais que vous pouvez le dire pour cet homme.
Je n'aimais pas ça, alors j'ai parlé. Pas de revendications personnelles, juste par rapport à la situation.
-Aleks-:
Le taux de traitement approximatif est donc de 23 passages de 2000 à 2013 sur le calendrier horaire aux prix d'ouverture :
1. Kamikadze_MA_V_01 - 5 minutes
2. Kamikadze_MA_V_02 - 15 minutes.
3. Kamikadze_MA_V_03 - plus de 30 minutes
Une telle opération tue tout simplement la possibilité d'un réglage fin de l'EA en temps réel.
Donc 23 passages en 30 minutes, c'est long ? C'est intéressant.
Mon conseiller expert sur M15 de juin à septembre prend 24 heures pour un passage dans le testeur. C'est une longue période. Je ne vais même pas parler d'optimisation. Et il n'est pas nécessaire...
Mon EA sur M15 de juin à septembre sur tous les ticks du testeur passe une journée sur une seule passe. C'est une longue période. Je ne parle même pas de l'optimisation. Et il n'y en a pas besoin.
Donc 23 passages en 30 minutes, c'est long... ? Intéressant.
Mon EA sur M15 de juin à septembre sur tous les ticks dans le testeur passe une journée pour une passe. C'est une longue période. Je ne vais même pas parler de l'optimisation. Et il n'y en a pas besoin.
Le plus important est que j'ai montré comment la vitesse a régressé au cours de l'évolution du conseiller expert. En général, je doute d'un EA qui utilise des ticks car les ticks sont générés et n'ont rien à voir avec l'historique.
Et j'ai un EA multidevises sur M5 sur les prix d'ouverture sur un historique de 9 mois passe 20 minutes sur 15000 passes génétiques. Mais ce n'est pas non plus un indicateur. Cela dépend beaucoup du nombre d'indicateurs utilisés...
Mais est-il possible d'accélérer significativement les performances de l'EA sur l'historique en préparant les données calculées des indicateurs et en les enregistrant dans un fichier ?
Plus important encore, j'ai montré comment la vitesse a régressé au fur et à mesure de l'évolution de l'EA. Un EA qui fonctionne sur les ticks - Je doute totalement de ce genre d'EA, car les ticks sont générés et n'ont rien à voir avec l'historique.
Est-il possible d'accélérer significativement le travail de l'EA sur l'historique, en préparant les données calculées des indicateurs et en les sauvegardant dans un fichier ?
Il est probable que la vitesse de lecture du disque soit plus lente que la vitesse de calcul de l'indicateur optimisé. Et qu'en est-il des calculs des agents à distance ? Voulez-vous leur envoyer les indicateurs calculés ? Dans votre cas, il existe de nombreux moyens d'optimiser la vitesse d'exécution. Vous devez éviter les boucles inutiles. + de réfléchir s'il est si critique d'effectuer toutes les actions à chaque tick, peut-être sera-t-il suffisant de le limiter à "l'événement nouvelle barre".
Il est possible que la vitesse de lecture du disque soit inférieure à la vitesse de calcul de l'indicateur optimisé. Et qu'en est-il des calculs sur les agents à distance ? Voulez-vous leur envoyer les indicateurs calculés ? Dans votre cas, il existe de nombreux moyens d'optimiser la vitesse d'exécution. Vous devez éviter les boucles inutiles. + de réfléchir s'il est si critique de tout faire à chaque tick, peut-être sera-t-il suffisant de limiter avec "new bar event".
Ne pouvons-nous pas lire les données une fois et créer un tableau à partir de celles-ci, et seulement ensuite les appliquer ?
Quant à mon EA spécifique, je rappelle que je l'ai optimisé par les prix d'ouverture - c'est-à-dire sans ticks, apparemment. Et pour ce qui est de la réflexion, je paie finalement à l'Applicant/Développeur pour l'optimisation de mon propre code, mais sans vérifier les événements qui se sont produits dans l'action de l'EA, ce qui promet une augmentation significative de la vitesse dans l'optimiseur, j'espère que c'est le cas.
Je l'espère ! Merci pour ces sages conseils !
Je voudrais opportunément poser une question, si 20 EAs travaillent simultanément au moment de l'ouverture de la barre, cela ne va-t-il pas provoquer un pic de ralentissement et des erreurs dans l'ouverture des ordres car le prix change drastiquement pendant l'estimation des données ?
Ne pouvons-nous pas lire les données une fois, créer un tableau de celles-ci et y accéder ensuite ?
Pendant le test, nous le faisons passer par l'historique. Emulation du trading. Lorsque le conseiller expert ne reçoit que les données qui ont déjà été reçues à chaque prochain comptage (appel du conseiller expert). Dans le cas du fichier, il aura à sa disposition tout l'historique de l'indicateur, y compris l'avenir qui l'attend lors des prochains appels. D'ailleurs, le tableau occupera beaucoup d'espace mémoire dans ce cas. Je vous assure que ce n'est pas la direction que nous devrions prendre pour l'optimisation. Du moins, pas dans ce cas.
J'ai une question pertinente : si 20 EAs travaillent simultanément au moment de l'ouverture de la barre, cela ne va-t-il pas provoquer un pic de ralentissement et des erreurs dans l'ouverture des ordres, car le prix va fortement changer pendant le calcul des données ?
Si les 20 EAs travaillent sur le même symbole, oui. Ils commenceront les calculs presque simultanément. Mais nous devons en tenir compte :
- Chacun d'entre eux sera exécuté dans un thread séparé. Dans le cas d'une configuration d'ordinateur à 4 cœurs, 4 d'entre eux peuvent être exécutés simultanément et n'ont pratiquement aucune influence mutuelle.
- le temps nécessaire à un seul calcul sera très probablement incomparablement court par rapport au temps d'envoi d'un ordre de transaction. C'est pour cette raison qu'il serait préférable d'envoyer de manière asynchrone des ordres de transaction pour les prix actuels (si plusieurs ordres peuvent être générés en une seule passe). Ainsi, vous n'aurez pas à attendre le résultat de la première commande avant d'envoyer la seconde. Mais il peut y avoir différentes options ici aussi. Tout dépend de la stratégie de trading.
Dans le cas d'Expert Advisors fonctionnant sur différents symboles, les ticks et la nouvelle barre ne se produiront le plus souvent pas simultanément.
Lors des tests, un parcours de l'historique est effectué. Emulation du trading. A chaque décompte suivant (appel de l'Expert Advisor), il ne reçoit que les données qui auraient déjà été reçues. Dans le cas du fichier, il aura à sa disposition tout l'historique de l'indicateur, y compris l'avenir qui l'attend lors des prochains appels. À propos, le tableau occupera beaucoup d'espace mémoire dans ce cas. Je vous assure que ce n'est pas la direction que nous devrions prendre pour l'optimisation. Du moins, pas dans ce cas.
Si les 20 conseillers-experts fonctionnent sur un seul et même outil, oui. Ils commenceront les calculs presque simultanément. Mais nous devons en tenir compte :
- Chacun d'entre eux sera exécuté dans un thread séparé. Dans le cas d'une configuration d'ordinateur à 4 cœurs, 4 peuvent être exécutés simultanément sans pratiquement aucune influence mutuelle.
- Le temps d'un seul calcul sera très probablement incomparablement court avec le temps d'envoi d 'un ordre de transaction. C'est pour cette raison qu'il serait préférable d'envoyer des ordres de transaction pour les prix actuels (si plusieurs d'entre eux peuvent être générés en une seule passe) de manière asynchrone. Ainsi, vous n'aurez pas à attendre le résultat de la première commande avant d'envoyer la seconde. Mais il peut y avoir différentes options ici aussi. Tout dépend de la stratégie de trading.
Dans le cas de conseillers experts opérant dans différents symboles, les ticks et une nouvelle barre ne se produisent généralement pas simultanément.
Ai-je bien compris que nous devrions retarder artificiellement l'envoi d'ordres à des ordres ouverts sans attendre la confirmation de leur ouverture ?
Ai-je raison de supposer qu'il devrait y avoir un délai artificiel lorsque des ordres sont envoyés à des ordres ouverts, mais sans attendre la confirmation de leur ouverture ?
micle:
никаких искусственных задержек делать не нужно. Это за вас сделает интернет и брокер...
Je parle de la situation qui se produit dans le trading manuel - vous envoyez une demande d'ouverture d'un ordre et attendez qu'il soit traité, parfois vous attendez une minute et quand vous essayez d'envoyer un autre ordre vous obtenez "le canal est occupé", en conséquence, le premier ordre n'est pas ouvert en raison des changements de prix et le second n'a pas été envoyé par le terminal (ou le courtier ne l'a pas accepté ?).Comment l'EA se comportera-t-il dans ce cas ? Est-il nécessaire de prescrire de manière particulière ou pourra-t-il envoyer des ordres sans attendre leur exécution ?