Nouveau MetaTrader 4 Client Terminal 387 et MetaTrader 4 Data Center build 387 - page 15
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
Chacun a le droit d'avoir une opinion personnelle, mais personne n'a le droit d'insulter les autres.
Dans ce cas, tout est parfaitement transparent - deux membres du forum ont exprimé leur opinion très négative sur le message de nen, ce qui a été suivi d'un bannissement, et Renat a clairement expliqué la raison de ce bannissement.
.... L'interdiction a suivi, et Renat a clairement expliqué la raison de cette interdiction.
Je t'ai seulement demandé de faire deux choses :
1) pour informer le visiteur du profil d'un membre du forum que ce même membre du forum est banni.
2) lorsque l'interdiction est prononcée - pour en préciser la raison (non pas après l'explication intelligible, mais au moment de l'annonce de l'interdiction).
Ce ne sont que des questions techniques, qui n'ont rien à voir avec la moralité, l'éducation ou quoi que ce soit d'autre.
J'ose encore suggérer la manière correcte de bannir un utilisateur : un utilisateur ne devrait pas être banni du forum, mais seulement pour créer de nouveaux fils et messages. Ainsi, le banni pourrait au moins poser une question (en privé) et ne pas encombrer la liste des utilisateurs avec de nouveaux surnoms.
C'est une demande/suggestion purement technique pour améliorer le moteur du forum.
Je t'ai seulement demandé de faire deux choses :
1) pour informer le visiteur du profil d'un membre du forum que ce même membre du forum est banni.
2) lorsque l'interdiction est prononcée - pour en préciser la raison (non pas après l'explication intelligible, mais au moment de l'annonce de l'interdiction).
Ce ne sont que des questions techniques, qui n'ont rien à voir avec la moralité, l'éducation ou quoi que ce soit d'autre.
Je vais aussi oser suggérer la manière correcte de bannir un utilisateur : un utilisateur ne devrait pas être banni du forum, mais seulement de la création de nouveaux fils de discussion et de messages. Ce banni pouvait au moins poser une question (en privé) et ne pas encombrer la liste des utilisateurs de nouveaux surnoms.
il s'agit d'une demande/proposition purement technique/technologique visant à améliorer le moteur du forum.
OK, je vais regarder l'article auquel vous faites référence.
A propos des données sous-chargées... Maintenant, en raison du passage du temps, je ne peux pas citer les journaux. Mais ça ressemblait à quelque chose comme ça.
Sur l'ATC d'American broker, l'EA est restée allumée et le terminal était fermé. Le lendemain, le terminal a été ouvert et après l'ouverture et la connexion automatique, il y a eu une pause sans aucune cotation. Le conseiller expert a envoyé une demande supplémentaire pour ouvrir une position et l'historique a commencé à être échangé et la position a été ouverte selon les calculs du jour précédent dans la zone où elle aurait dû être fermée, mais elle a juste été ouverte et perdue instantanément contre le marché qui se déplaçait dans la direction opposée. La position a fini par être fermée avec une perte importante, je ne me souviens pas combien elle a perdu mais beaucoup.
Un autre cas. J'ai laissé un Expert Advisor avec un calcul de canal dans son algorithme, quelque chose de similaire à Bollinger, mais nécessitant de nombreuses barres car il avait un algorithme d'adaptation. Je n'ai pas vu le moment où l'échange a commencé, mais je l'ai vu environ 20 minutes plus tard. Il s'est avéré que les écarts par rapport à la moyenne adaptée n'ont pas été pris en compte et que le canal s'est brisé en ligne, comme s'il se trouvait sur la moyenne. Mon conseiller expert ouvrait et fermait une position après l'autre et il a perdu environ 4 500 $ en 20 minutes par 0,2-0,3 lots. 4,500$ dans un marché totalement gagnant. Cela pourrait se produire s'il y avait très peu de données ou si quelque chose manquait pour le modèle que j'ai cité plus haut.
Maintenant, j'éteins toujours les EA après avoir négocié. Maintenant je désactive toujours les Expert Advisors après la première fois, j'ouvre à nouveau le terminal et j'attends que les données soient pompées et seulement ensuite je les active.
De mon point de vue
une EE exige que des données soient disponibles (généralement n'importe quelles données)
Car toutes les erreurs se divisent en erreurs dans le code et en erreurs dans les données !
Le problème est résolu en analysant la disponibilité des données. Le problème est résolu en analysant la disponibilité des données requises.
et leur exactitude avant de les utiliser !
Par exemple : avant de diviser, il est élémentaire de vérifier si l'on essaie de diviser par zéro.
ce sera le ton correct dans presque toutes les situations, même si vous êtes sûr ... qu'une variable ... ne peut pas être = 0
La vérification donnera la certitude à 100% que le programme ne plantera pas lors de la division ! ALORS VÉRIFIEZ VOS DONNÉES !
pour éviter ce genre de choses !
le conseiller expert doit savoir exactement de combien de barres il a besoin !
à la suite d'un algorithme simple mais efficace
vous devez commencer à partir de la bougie en cours sur la ou les périodes nécessaires.
pour courir à la bonne profondeur ! s et voir s'il y a des barres manquées - ce n'est pas très difficile
je ne donnerai pas le code ... il y a des gens ici qui peuvent facilement écrire un tel code !
Ensuite, le conseiller expert ne se déchire pas ou ne se ferme pas, mais se brise !!! qu'il n'y a pas d'HISTORIQUE COMPLET !
vous ! !! tenez-en compte - prenez des mesures pour combler les barres manquantes !
et seulement après cela, vous l'autorisez à commercer !
--
votre problème est que votre algorithme n'a pas ce contrôle !
ajouter ! parce que c'est plus facile que de perdre 4 500 $ ...
--
Pour ceux qui ne peuvent pas écrire un tel code, ils l'écriront ici pour 100-200 $.
c'est moins de 4 500 $ !
à partir de la bougie de travail actuelle sur la ou les périodes souhaitées.
courir à la bonne profondeur ! s et voir s'il y a des barres manquées - ce n'est pas trop difficile
Merci Yura pour le tuyau.
Mais que dois-je faire, si je viens d'ouvrir le terminal et que la barre zéro est encore ancienne, par exemple du jour précédent. Bien sûr, nous pouvons courir jusqu'à une certaine profondeur en comptant les barres manquées, mais ce sera une erreur. Comment l'EA sait-il si c'est la dernière barre ou pas ? J'ai dit précédemment qu'en principe on peut comparer TimeLocal() et TimeCurrent() en tenant compte de la différence de temps et en ajoutant un petit delta, parce que parfois il n'y a pas de cotation pendant 3-5 minutes, surtout pour les paires CAD, et probablement cela peut être considéré comme une erreur. Peut-être suffit-il de le faire pendant l'initialisation et de corriger les barres manquées par la suite, par exemple lorsque la communication est interrompue pendant plusieurs minutes, et il n'est probablement pas nécessaire de recalculer à chaque barre car cela prendrait trop de temps. Le conseiller expert dont j'ai parlé à propos des pertes nécessite jusqu'à 20 000 barres pour une adaptation initiale statistique. Pour un tel nombre, il serait pénible d'exécuter des cycles sur chaque barre et ce n'est probablement pas nécessaire. Bien sûr, ce n'est pas le meilleur moyen et cela dépend en plus de l'horloge de l'ordinateur. Peut-être pouvez-vous penser à quelque chose de mieux ? Cependant, comme je l'ai observé dernièrement, si la fonction IsConected() est déclenchée, la barre zéro apparaît généralement presque immédiatement.
Merci, Yura, pour le tuyau.
Mais que dois-je faire, si le terminal vient d'être ouvert et que la barre de zéro est encore ancienne - disons du jour précédent. Bien sûr, nous pouvons courir jusqu'à une certaine profondeur en comptant les barres manquées, mais ce sera une erreur. Comment l'EA sait-il si c'est la dernière barre ou pas ? J'ai dit précédemment qu'en principe on peut comparer TimeLocal() et TimeCurrent() en tenant compte de la différence de temps et en ajoutant un petit delta, parce que parfois il n'y a pas de cotation pendant 3-5 minutes, surtout pour les paires CAD, et probablement cela peut être considéré comme une erreur. Peut-être suffit-il de le faire pendant l'initialisation et de corriger les barres manquées par la suite, par exemple lorsque la communication est interrompue pendant plusieurs minutes, et il n'est probablement pas nécessaire de recalculer à chaque barre car cela prendrait trop de temps à compter. Le conseiller expert dont j'ai parlé à propos des pertes nécessite jusqu'à 20 000 barres pour une adaptation initiale statistique. Pour un tel nombre, il serait pénible de chercher des cycles sur chaque barre et ce n'est probablement pas nécessaire. Bien sûr, ce n'est pas le meilleur moyen et cela dépend en plus de l'horloge de l'ordinateur. Peut-être pouvez-vous penser à quelque chose de mieux ? Cependant, comme je l'observais dernièrement, si la fonction IsConected() se déclenche, la barre de zéro apparaît généralement presque immédiatement.
Eh bien, tout me semble simple... La procédure int start() n'est appelée qu'à un nouveau tick, et cela signifie à 100% que la fonction TimeCurrent() (renvoie la dernière heure connue du serveur (heure d'arrivée de la dernière cotation)) sera déjà effective indépendamment de la disponibilité des barres...
Je pense que tout est clair après ça...
Malheureusement, vous n'avez pas spécifié de données initiales, de paramètres de test ou de journaux.
De plus, vous faites référence aux bibliothèques (DLL), qui non seulement nécessitent beaucoup d'installations, mais aussi ne fonctionnent pas par manque de bibliothèques supplémentaires (ceci est à l'auteur des bibliothèques, qui a oublié les fichiers DLL supplémentaires).
Contactez l'auteur de ces bibliothèques pour obtenir des informations.
Si vous suivez le lien que je vous ai fourni, vous verrez qu'un seul paramètre d'entrée a une valeur et qu'il est défini comme décrit : StopLoss=100...1 000 step 10 ; x=1...1 000 000 step 1. De plus, j'ai dit que le build précédent n'a pas généré cette erreur, donc l'erreur est la vôtre. Tout fonctionne réellement. Il ne donne que ce message étrange. Il se peut donc que ce message ne concerne que moi et qu'il ne fonctionne pas pour quelqu'un d'autre en raison des conséquences de cette erreur.
Merci, Yura, pour le tuyau.
Mais que dois-je faire, si le terminal vient d'être ouvert et que la barre de zéro est encore ancienne - disons du jour précédent. Bien sûr, nous pouvons courir jusqu'à une certaine profondeur en comptant les barres manquées, mais ce sera une erreur. Comment l'EA sait-il si c'est la dernière barre ou pas ? J'ai dit précédemment qu'en principe on peut comparer TimeLocal() et TimeCurrent() en tenant compte de la différence de temps et en ajoutant un petit delta, parce que parfois il n'y a pas de cotation pendant 3-5 minutes, surtout pour les paires CAD, et probablement cela peut être considéré comme une erreur. Peut-être suffit-il de le faire pendant l'initialisation et de corriger les barres manquées par la suite, par exemple lorsque la communication est interrompue pendant plusieurs minutes, et il n'est probablement pas nécessaire de recalculer à chaque barre car cela prendrait trop de temps à compter. Le conseiller expert dont j'ai parlé à propos des pertes nécessite jusqu'à 20 000 barres pour une adaptation initiale statistique. Pour un tel nombre, il serait pénible d'exécuter des cycles sur chaque barre et ce n'est probablement pas nécessaire. Bien sûr, ce n'est pas le meilleur moyen et cela dépend en plus de l'horloge de l'ordinateur. Peut-être pouvez-vous penser à quelque chose de mieux ? Cependant, comme je l'ai observé dernièrement, si la fonction IsConected() se déclenche, la barre de zéro apparaît généralement presque immédiatement.
Salut !
cela peut être vérifié logiquement aussi !
Tout d'abord, vous obtenez quelques ticks et chronométrez la TimeCurrent() et si elle est éloignée des barres, vous la chargez - mais vous devez également tenir compte du week-end.
le lundi vous devez connaître l'heure de début chez votre courtier, et le vendredi l'heure de fin ( à cela, sur les petits ff avoir une petite erreur de quelques barres
(l'heure de début le lundi et l'heure de fin le vendredi peuvent être calculées automatiquement par la méthode de la moyenne pour une période plus longue).
exemple de logique
Si vous suivez le lien que je vous ai fourni, vous verrez qu'un seul paramètre d'entrée a une valeur et a été défini, comme il est dit dans la description : StopLoss=100..1 000 step 10 ; x=1..1 000 000 step 1. De plus, j'ai dit que la construction précédente n'a pas généré cette erreur, donc l'erreur est la vôtre. Tout fonctionne réellement. Il ne donne que ce message étrange. Il se peut donc que ce message ne concerne que moi, alors que quelqu'un d'autre peut ne pas travailler du tout à cause des conséquences de cette erreur.
J'ai fait diligence, j'ai tout lu, j'ai compris la logique, mais je me suis heurté exactement à ce qu'il a dit - pas assez de bibliothèque dll tierce, que l'auteur du jeu de bibliothèques n'a pas mis en place (bien qu'il ait même fait l'installateur).
Apparemment, un oubli banal. Mais je ne peux pas parcourir l'internet à la recherche de quelques fichiers dll.