Comparaison de la moyenne mobile (et de tout autre indicateur) et de l'erreur - page 4
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
Merci pour les conseils bien sûr, mais je peux lire l'aide moi-même. Et je répète que les mathématiques computationnelles ne sont pas liées à un langage de programmation particulier. C'est juste les erreurs de calcul que je dois gérer, avec lesquelles vous passerez.
Si vous pouvez non seulement lire l'aide, mais aussi la comprendre, alors vous faites preuve d'une démagogie délibérée, en vous obstinant à continuer de parler de la normalisation et de ses applications potentielles dans un esprit dépréciatif. Y compris la démagogie délibérée sur les dangers de son application.
Et je ne suis pas en train de faire le malin, mais de donner des contre-exemples (y compris pour votre chère normalisation).
La démagogie était là. Il n'y a pas eu de contre-exemples sur la normalisation.
En dehors du fait que quelqu'un peut mal l'appliquer.
Les epsilons peuvent donc être appliqués de manière incorrecte. Oui et la démagogie a déjà été mentionnée.
P./S. : Le billet porte sur la normalisation, je ne mentionne donc pas les moyennes mobiles.
Et je pense qu'Artem peut mieux vous aider avec les EAs utilisant des MAs que je ne peux le faire avec ces EAs difficiles.
Recherchez les croisements à chaque tick. Quel est le problème ?
Il n'est jamais nécessaire de normaliser quoi que ce soit lors de la comparaison de deux nombres réels.
Si les nombres sont vraiment égaux, ils sont stockés en mémoire de manière égale. En fait, c'est précisément grâce à cette propriété que les machines à calculer peuvent exister.
Par conséquent, les comparaisons de la forme if(a<b) ou if(a==b) sont correctes dans tous les cas et aucune normalisation n'est nécessaire.
Si l'esprit inquisiteur d'un chercheur trouve une contradiction à cette règle, cela signifie que soit sa machine est en panne, soit son esprit. L'un des deux.
L'aide et la documentation doivent bien sûr être lues au moins de temps en temps (elles ont également été écrites par des humanoïdes comme nous), mais il est nécessaire d'avoir son propre raisonnement raisonnable.
Si vous pouvez non seulement lire l'aide, mais aussi la comprendre, alors vous faites preuve d'une démagogie délibérée, en vous obstinant à continuer de parler de la normalisation et de ses applications potentielles dans un esprit dépréciatif. Y compris la démagogie délibérée sur les dangers de son application.
La démagogie était là. Il n'y a pas eu de contre-exemples sur la normalisation.
Sans compter le fait que quelqu'un peut ne pas l'utiliser correctement.
Les epsilons peuvent donc être appliqués de manière incorrecte. Et la démagogie a déjà été mentionnée.
Il y a eu des contre-exemples (au moins en termes de normalisation également de la différence, comme cela a été dit ici). Je le répète : la normalisation est le moyen le plus simple pour ceux qui ne veulent pas se plonger dans les méandres. Il a lu la documentation et croit pieusement à tout cela. Encore une fois, je répète que le langage de programmation des mathématiques informatiques n'est pas pertinent. Si c'est écrit ainsi dans l'aide, cela ne veut pas dire que c'est vrai (sinon il n'y aurait pas de problèmes de calcul et d'epsilon que vous détestez tant). Il y a beaucoup d'écrits sur la clôture aussi, mais cela ne veut pas dire que c'est la vérité en dernier ressort. Vous êtes satisfait de l'option Halp, vous avez tous les droits de l'être. Mais c'est votre choix personnel. Et cela ne signifie pas qu'il résout tous les problèmes que j'ai essayé de clarifier ici. Et considérer comme de la démagogie quelque chose que vous ne voulez tout simplement pas comprendre (encore une fois, c'est votre droit), ne signifie pas que c'est la démagogie elle-même. Je ne pose pas de questions rhétoriques sur le sens de la vie (dont les réponses ne sont que démagogie), j'essaie simplement de comprendre quelque chose que je n'ai pas encore rencontré. Encore une fois, disons que les valeurs sont toujours les mêmes à chaque fois que vous les calculez. Là, vous pourriez obtenir quelque chose des mêmes mathématiques computationnelles. Mais lorsque les valeurs sont également différentes, vous ne serez pas en mesure de proposer un algorithme universel, même si vous êtes un méga gourou.
Par ailleurs, je veux juste m'assurer que j'ai bien compris que si un robot ne fonctionne pas par ticks, obtenir des intersections multiples dans une barre est fondamentalement impossible. On peut déjà l'attribuer purement aux subtilités de mql.
P.S. Je n'essaie pas d'argumenter avec quelqu'un sans fondement, je ne pense pas être un bon génie tout le temps. Je n'aime pas quand les gens essaient d'être intelligents et d'écrire quelque chose sans le lire. Cela n'a rien à voir avec vous personnellement. Merci pour votre aide et vos réflexions sur le sujet. Mais, à mon avis, il n'est pas correct d'écrire quelque chose sur la patience lorsque vous insistez sur un seul point de vue dans la documentation (auquel vous croyez de tout cœur et n'acceptez pas d'autres points de vue et exemples), et que les epsilons ne sont pas à votre goût. J'espère qu'Artyom comprendra aussi ce que j'ai écrit dans le post-scriptum qui précède. Je vous remercie tous pour vos réponses et je vous prie de m'excuser si je me suis emporté quelque part.
P.P.S. La normalisation à une certaine décimale est en fait analogue à l'introduction d'epsilon juste par l'ordre du même signe.
P.P.P.S. Si nous avons une discussion aussi animée, je serais très reconnaissant si vous partagez vos expériences dans ce sujet, parce que les réponses appropriées (en particulier sur les 2 et 3 points qui me dérangent), en fait, n'a pas obtenu. Après avoir parcouru de nombreux forums, j'en suis presque arrivé à la conclusion que, oui, 2 points est impossible. Les développeurs de mql pourraient penser à cela, et fournir plus de flexibilité, parce qu'il est très inconfortable (dans tout autre langage de programmation a la capacité de changer dynamiquement l'interface du programme, et ici il s'avère qu'il n'y en a pas ((()))
Il y a eu des contre-exemples (au moins en termes de normalisation également de la différence, comme cela a été dit ici). Je le répète : la normalisation est le moyen le plus simple pour ceux qui ne veulent pas se plonger dans les méandres. Il a lu la documentation et croit pieusement à tout cela. Je répète que le langage de programmation utilisé dans le cadre des mathématiques computationnelles n'est pas pertinent. Si c'est écrit ainsi dans l'aide, cela ne veut pas dire que c'est vrai (sinon il n'y aurait pas de problèmes de calcul et d'epsilon que vous détestez tant). Il y a beaucoup d'écrits sur la clôture aussi, mais cela ne veut pas dire que c'est la vérité en dernier ressort. Vous êtes satisfait de l'option Halp, vous avez tous les droits de l'être. Mais c'est votre choix personnel. Et cela ne signifie pas qu'il résout tous les problèmes que j'ai essayé de clarifier ici. Et considérer comme de la démagogie quelque chose que vous ne voulez tout simplement pas comprendre (encore une fois, c'est votre droit), ne signifie pas que c'est la démagogie elle-même. Je ne pose pas de questions rhétoriques sur le sens de la vie (dont les réponses ne sont que démagogie), j'essaie simplement de comprendre quelque chose que je n'ai pas encore rencontré. Encore une fois, disons que les valeurs sont toujours les mêmes à chaque fois que vous les calculez. Là, vous pourriez obtenir quelque chose des mêmes mathématiques computationnelles. Mais lorsque les valeurs sont également différentes, vous ne serez pas en mesure de proposer un algorithme universel, même si vous êtes un méga gourou.
Par ailleurs, je veux juste m'assurer que j'ai bien compris que si un robot ne fonctionne pas par ticks, obtenir des intersections multiples dans une barre est fondamentalement impossible. On peut déjà l'attribuer purement aux subtilités de mql.
P.S. Je n'essaie pas d'argumenter avec quelqu'un sans fondement, je ne pense pas être un bon génie tout le temps. Je n'aime pas quand les gens essaient d'être intelligents et écrivent quelque chose sans même le lire. Cela n'a rien à voir avec vous personnellement. Merci pour votre aide et vos réflexions sur le sujet. Mais, à mon avis, il n'est pas correct d'écrire quelque chose sur la patience quand vous insistez sur un seul point de vue dans la documentation (auquel vous croyez de tout cœur et n'acceptez pas d'autres points de vue et exemples), et que les epsilons ne sont pas à votre goût. J'espère qu'Artyom comprendra aussi ce que j'ai écrit dans le post-scriptum qui précède. Je vous remercie tous pour vos réponses et je vous prie de m'excuser si je me suis emporté quelque part.
P.P.S. La normalisation à une certaine décimale est en fait analogue à l'introduction d'epsilon juste par l'ordre du même signe.
P.P.P.S. Si nous avons une discussion aussi animée, je vous serais très reconnaissant de partager vos expériences dans ce domaine, parce que les réponses appropriées (en particulier sur les points 2 et 3 qui me dérangent), en fait, n'ont pas obtenu. Après avoir parcouru de nombreux forums, j'en suis presque arrivé à la conclusion que, oui, 2 points est impossible. Les développeurs de mql auraient pu penser à cela, et fournir plus de flexibilité, parce que c'est très inconfortable (dans tout autre langage de programmation a la capacité de changer dynamiquement l'interface du programme, et ici il s'avère qu'il n'y en a pas ((()))
Pour moi, la conversion des données à l'aide de la fonction NormalizeDouble lors de la comparaison de doubles est l'une des deux façons, stipulées dans la documentation, d'obtenir que les conditions du programme fonctionnent exactement à l'endroit et de la manière prévus lors de l'écriture de conditions spécifiques dans le code. C'est ce dont je parlais tout à l'heure. Par conséquent, il ne s'agit pas seulement de l'élimination de toute erreur. Il s'agit également de diverses manières réfléchies de transformer les données pour remplir toutes les conditions.
Je vous l'ai dit et je vous en parle, sur la base de mon expérience pratique personnelle dans le langage de programmation que vous commencez à apprendre. Pour cette raison, et suggéré à plusieurs reprises dans ce fil, d'utiliser un tel moyen pratique.
En passant, je dirai, en partie, en étant d'accord avec vous que je ne contesterai pas que la normalisation en utilisant cette fonction, peut être le moyen le plus facile pour toutes les tâches en termes de transformation de données de type réel.
Mais c'est à chacun de décider laquelle des deux méthodes recommandées dans la Documentation utiliser pour convertir des données de types réels.
Et le fait de choisir l'une ou l'autre de ces voies ne détermine pas si l'on est le genre de personne à essayer de comprendre les subtilités nécessaires ou non.
Que je n'aime pas les epsilons n'était pas un mot de ma part. Ne pas appliquer une méthode n'est pas nécessairement de l'amour ou du dégoût. Je n'ai pas non plus insisté pour n'appliquer que la deuxième voie des deux.
Mes paroles littérales en termes d'application pratique des particularités du travail avec des nombres de type double, que:
P./S. : Il se trouve que la première méthode de la documentation s'est avérée moins pratique pour moi, y compris pour les tâches que je résous généralement moi-même. Par conséquent, je n'ai pas beaucoup d'expérience avec la première méthode.
Mais lors de l'application de la deuxième méthode (c'est-à-dire la comparaison de la différence normalisée de deux nombres réels avec la valeur zéro dans l'expression de l'opérateur conditionnel), aucun problème ne s'est posé sans ambiguïté.
Mais si j'ai fait une comparaison de nombres non normalisés (je veux dire ici, sans utiliser la première façon aussi), alors oui, c'est que j'ai trouvé un fonctionnement incorrect des conditions sur la base de comparaisons de nombres de type double.
D'ailleurs, j'ai aussi donné une telle précision:
P./S. : Cela dit, juste au cas où, je vais clarifier une fois de plus, que la comparaison des nombres réels par la première méthode des deux énumérés ici , encomparant la différence des nombres avec une certaine petite valeur, je ne peux pas appeler pire que l'utilisation de la normalisation, lorsque vous avez besoin d'ajuster le niveau de comparaison (incl., puisque pour moi la deuxième méthode était plus pratique, je n'ai pas considéré pour moi-même plus détaillée pour l'application pratique).
C'est-à-dire qu'en termes de normalisation lors de la conversion de données doubles, je n'avais tout simplement pas besoin de la première façon. En particulier, en raison de la commodité d'utilisation de la fonction NormalizeDouble dans la résolution de divers problèmes (et pas seulement dans les comparaisons).
Ce site dispose d'une énorme base de connaissances accumulées.
Les gens ont résolu toutes sortes de problèmes de complexité différente en utilisant MQL4.
Après le rapprochement de MQL4 et de MQL5, les possibilités du premier ont encore augmenté.
Je pense que vous devriez vous familiariser davantage avec ce langage de programmation et ne pas ignorer la base de connaissances accumulée sur les sites ici. Acquérir une expérience pratique de son utilisation. Ce n'est qu'à ce moment-là que vous pourrez vous prononcer en toute confiance sur les applications de ce langage de programmation et ses capacités.
J'ai un TdR différent) Et encore, j'ai déjà écrit sur les problèmes avec les tiques. Il est impossible d'expliquer au client pourquoi le robot est entré dans la transaction s'il ne voit pas le croisement sur le graphique.
Prenez les valeurs MA sur la barre zéro et la première barre sur chaque tick - alors et seulement alors vous pouvez trouver des croisements de MAs sur la barre zéro. Vous les prenez à partir de la première barre au moment de l'ouverture de la barre zéro - et là, les valeurs MA sont celles qui étaient présentes lorsque la première barre a été fermée, et non lorsqu'elle a été formée. Vous lisez simplement les valeurs de МАšek sur le tard et ne les voyez donc pas se croiser. La normalisation n'a rien à voir avec cela. Et d'ailleurs, si les MAs montrent des valeurs de prix, alors les valeurs devraient être normalisées en _Digits, au lieu de deviner à quelle valeur la normalisation est nécessaire...
Chers participants au forum. Veuillez ne pas créer de querelles sur le forum. Seulement sur le sujet du fil.
Je pense que le sujet peut être clos. Les auteurs (et non le sujet) des déclarations ne sont pas parvenus à un consensus. Il y a eu des moments isolés de chauvinisme, ce qui n'est pas bienvenu.
Mais ni l'un ni l'autre n'ont été en mesure de prouver leurs dires. C'est pourquoi je ferme le fil. Toute discussion supplémentaire peut être sanctionnée (interdiction quotidienne maximum).
Bien que s'il y aura des preuves normales, elles seront les bienvenues.
Les juges seront moi et Volodya.
Ce n'est pas une discussion.
Je n'ai pas vu tout cela ici, donc je ne sais pas quels arguments ont été avancés dans le cadre du sujet. Mais puisque je suppose qu'il s'agit de prouver ma position, qui est similaire à celle d'Artem dans ce message (et plus tôt dans le fil), je vais donner l'un des exemples ci-dessous, en rapport avec la question de savoir si la normalisation doit être appliquée d'une manière ou d'une autre lorsqu'on travaille avec des nombres de type réel.
Avec des captures d'écran et une variante du code de test.
Artyom a écrit dans le post ci-dessus :
И, кстати, раз МА показывают значения цены, то и нормализовать значения нужно до _Digits, а не гадать до какого же значения нормализация нужна...
Et puisque je crois aussi (comme beaucoup d'autres, je pense) qu'il s'agit d'un moyen simple et efficace dans les directions les plus courantes des problèmes, je ne ferai que ce petit ajout de mon cru :
avec combien de décimales il est conçu pour afficher la ligne MA, ou simplement effectuer des calculs basés sur n'importe quel nombre de décimales (même comparaison), avec autant de décimales et normalisation (arrondi à une certaine décimale).
/*Pour certaines tâches individuelles, il peut y avoir des "exceptions", et vous pouvez varier pour obtenir le résultat souhaité, par exemple, en comparant une valeur avec une décimale inférieure, avec une valeur avec une décimale supérieure. Mais si cela est nécessaire pour la tâche à accomplir, il est à mon avis judicieux, comme pour la méthode ci-dessus, d'imprimer les valeurs obtenues et de les comparer avec le rendu visuel sur le graphique, si nécessaire.
Si nous avons besoin de sortir des valeurs de type double sous forme de texte (via Print, Comment, OBJ_LABEL, etc.), nous devons utiliser DoubleToString puisque nous voulons convertir un nombre en texte.
Passons maintenant de l'explication introductive à la clarté :
Dans les captures d'écran :
Les données du script de test sont des valeurs MA obtenues à l'aide de la fonction iMA (avec et sans transformations à l'aide des fonctions décrites pour travailler avec des types réels dans la documentation).
Vous pouvez voir dans la fenêtre de données et sur le graphique que les lignes avec une décimale inférieure ont égalisé leurs valeurs sur la troisième barre du graphique, sans compter la barre actuelle. Vous pouvez également voir que les valeurs MA de l'ensemble standard au terminal, dessinées sur les décimales du graphique, ne sont pas égales et visuellement elles se sont égalisées sur le graphique un peu plus tôt.
C'est-à-dire que si vous agrandissez les captures d'écran ou si vous faites vos propres expériences en utilisant le script de test ci-joint ou vos propres codes, vous verrez que les lignes MA, avec le nombre de décimales comme dans le graphique, se croisent un peu plus tôt.
Et c'est compréhensible. Par analogie, les lignes avec des décimales sont inférieures d'une unité aux lignes tracées avec des chiffres à deux chiffres sur un tableau à trois chiffres. Il permet de les voir dans les "anciens" points de l'époque où les cotations à trois ou cinq chiffres dans les terminaux ne sont pas très répandues et, en même temps, présentent les avantages des cotations décimales étendues pour le trading (y compris des spreads plus étroits).
Autrement dit, les lignes basées sur des valeurs comportant moins de décimales présentent moins de "bruit".
Mais si l'arrondi n'était pas appliqué (dans ce cas, en utilisant la fonction de normalisation), un nombre clairement limité à une décimale spécifique serait plus problématique.
Ou, si seulement en chiffres :
123.4561 et 123.4556 ne sont pas égaux. Et leur différence n'est pas nulle.
Cependant, si vous les arrondissez, le premier et le second nombre seront identiques et égaux à 123,456. Par conséquent, la différence entre eux sera de 0.
C'est à lui d'arrondir les valeurs obtenues, en fonction des tâches à effectuer.
Dans les captures d'écran du journal "Experts", vous pouvez voir les valeurs MA sorties en utilisant iMA avec les conversions décrites dans la Documentation, et sans conversion des valeurs résultantes. Les paramètres MA dans le script de test sont égaux à ceux des indicateurs sur le graphique.
Dans la deuxième capture d'écran, vous pouvez voir les deltas entre deux valeurs MA avec et sans transformations.Ci-dessous, comme je l'ai mentionné, un petit code de test. Il n'est pas optimisé mais permet de faire diverses expériences avec les valeurs MA, y compris la modification de certains paramètres.
Le nombre de barres qu'il contient est défini dans cette ligne :
P./S. : J'ai remplacé le script de test ci-joint. J'ai pris la mauvaise variante dans mon message. Faux. Désolé.
Les captures d'écran précédemment jointes ne sont pas nécessaires, je les laisse donc telles quelles.