Comparaison de la moyenne mobile (et de tout autre indicateur) et de l'erreur - page 3
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, Artyom, mais malheureusement il s'avère que cela peut avoir des limites aussi.
J'espère que vous n'avez tué personne.
Nah. Cela n'a rien à voir avec mon environnement).
Je ne le fais pas. Cela n'a rien à voir avec mon environnement).
Tout d'abord, la différence de deux valeurs normalisées donnera éventuellement une valeur non normalisée. Vous devez vérifier la différence normalisée.
Deuxièmement, si vous voulez attraper des croisements à l'intérieur d'une barre, prenez les valeurs de tous les ticks sur la barre zéro et la première barre - vous attraperez beaucoup ... ...vous allez avoir un vrai plaisir...
Si vous testez par l'ouverture d'une barre, le conseiller-expert doit évidemment tracer l'ouverture d'une nouvelle barre et, après coup, vérifier les croisements.
Tout d'abord, décidez vous-même si vous traitez à l'ouverture des barres ou à chaque tick, puis écrivez votre code. Et, par conséquent, le tester de la même manière.
Tout d'abord, j'ai écrit dans le premier post que je ne négocie qu'à l'ouverture des barres. Il y a une subtilité dans le trading de ticks. Vous pouvez obtenir un signal, mais visuellement il n'y aura pas de croisement sur le graphique, car il n'est dessiné qu'à certains prix (ouverture, fermeture, etc.). Il n'est pas dessiné par les tiques. Dans ce cas, expliquez au profane que oui, il n'y a pas de croisement sur le graphique, mais parce qu'il est spécifique au dessin des muwings lorsqu'on ne visualise que des valeurs très éloignées les unes des autres (à nouveau, les prix d'ouverture, de clôture, etc. - approximation, si vous avez déjà entendu ce mot) plutôt que par tics. Deuxièmement, la normalisation des différences est un non-sens. Vous ne saurez JAMAIS à l'avance à quel signe vous devez normaliser pour éviter d'obtenir exactement 0 (en ne coupant pas stupidement tous les chiffres significatifs). Je m'adonne à la programmation depuis un certain temps et, dans ce contexte, je comprends assez bien les mathématiques computationnelles (dans le cadre de mon activité principale - la modélisation de la physique, où je dois constamment me battre avec la précision des calculs). En fait, en général, la normalisation est une grande simplification, si vous ne voulez pas vous plonger dans les subtilités des mathématiques de calcul, des erreurs, etc. Si vous vous considérez comme un gourou et que vous n'êtes pas prêt à vous abaisser à lire attentivement l'ensemble du sujet pour en tirer des conclusions, c'est une chose. Si ce n'est pas le cas et que vous traitez également sur l'ouverture d'une nouvelle barre, alors essayez de tester votre robot sur la barre du 29.07.2015 à 3:20 avec les paramètres de deux SMA 5 et 34 appliqués au prix de clôture, sur une échelle de temps d'une minute. C'est exactement la situation où les mouvements dans une même barre se croisent deux fois. Et cette situation est irréaliste lorsque le trading n'est pas basé sur les ticks. Votre robot de trading recevra-t-il les deux signaux ? Et surtout, la réponse à la question de savoir pourquoi, sur une même barre, la différence des muwings (ou plutôt de leurs valeurs brutes) à différents moments n'est pas égale, n'a pas encore été donnée (seul Alexey Lebedev a essayé, merci pour cela, mais ce ne sont que des suppositions...). Et il est impossible de répondre sans connaître les principes de fonctionnement de l'iMA.
P.S. Juste pour discuter, je pense qu'il existe des fils spéciaux sur le forum, si vous ne voulez pas entrer dans le cœur du problème.
Merci, Artyom, mais malheureusement il s'avère que cela peut avoir des limites aussi.
...
Continuez à réinventer l'hyperboloïde. Cela fonctionne toujours pour moi et compte correctement. Oh, oui, désolé, je ne suis pas un gourou dans vos mathématiques computationnelles, je n'invente pas de conneries - je fais des programmes pour MT4 et MT5. Et vous continuez à faire le malin, si vous ne voulez pas entendre ce qu'on vous dit (et il ne s'agit pas d'un manuel scolaire).
Je le répète : si vous négociez à l'ouverture d'une nouvelle barre, la question est de savoir pourquoi vous avez besoin d'un croisement à l'intérieur de la barre (est-ce important pour vous ? Si oui, je vous conseillerai comment faire, sinon, oubliez-le).
Je ne vais pas utiliser mon robot sur vos séries chronologiques - j'ai abandonné le trading sur les MAHs il y a longtemps. Et le fait que les MAEs dépassent la barre de zéro lorsqu'elles sont calculées en utilisant tous les prix sauf le prix d'ouverture est connu même d'un écolier. Pourquoi expliquer à quelqu'un qu'il était là et qu'il a disparu, si vous négociez à l'ouverture d'une bougie ? Donc à l'ouverture et prendre les données du MAA.
Où avez-vous trouvé le problème ? Voici votre croix :
Pouvez-vous me donner un code qui identifiera correctement ce croisement ?
Continuez à réinventer l'hyperboloïde. Cela fonctionne toujours pour moi et compte correctement. Oh, oui, désolé, je ne suis pas un gourou dans vos mathématiques computationnelles, je n'invente pas de conneries - je fais des programmes pour MT4 et MT5. Et vous continuez à faire le malin, si vous ne voulez pas entendre ce qu'on vous dit (et il ne s'agit pas d'un manuel scolaire).
Je le répète : si vous négociez à l'ouverture d'une nouvelle barre, la question est de savoir pourquoi vous avez besoin d'un croisement à l'intérieur de la barre (est-ce important pour vous ? Si oui, je vous conseillerai comment faire, sinon, oubliez-le).
Je ne vais pas utiliser mon robot sur vos séries chronologiques - j'ai abandonné le trading sur les MAHs il y a longtemps. Et le fait que les MAEs dépassent la barre de zéro lorsqu'elles sont calculées en utilisant tous les prix sauf le prix ouvert est connu même d'un écolier. Pourquoi expliquer à quelqu'un qu'il était là et qu'il a disparu, si vous tradez à l'ouverture d'une bougie ? Donc à l'ouverture et prendre les données du MAA.
Où avez-vous trouvé le problème ? Voici votre croisement :
Pouvez-vous suggérer un code qui identifiera correctement ce croisement ?
Je n'invente pas l'hyperdoloïde. Si je voulais l'inventer, je ne vous aurais rien demandé. Et je ne fais pas le malin, je donne des contre-exemples (y compris votre normalisation préférée). En ce qui concerne les croisements à l'intérieur d'une barre. Les TS sur MA les plus primitifs ouvrent des transactions à leur intersection. Au prochain croisement dans la direction opposée, la première chose à faire est de fermer la transaction ouverte à l'ancien croisement, et d'en ouvrir une nouvelle à l'opposé. Si je manque un croisement (et dans le cas d'un croisement à l'intérieur de la barre deux fois, pour ainsi dire, ce sera le cas), alors je manque un signal. Et par conséquent, je ne ferme pas la transaction actuelle. Et mon robot a deux transactions actives, alors qu'il devrait toujours y avoir une seule transaction dans ce TS. C'est pourquoi tout croisement est important. En outre, concernant le prix à l'ouverture d'une bougie. Dans ce cas, la part du lion des signaux de croisement sera manquée si nous prenons par exemple les valeurs MA aux prix de clôture. Un exemple simple - nous prenons le prix de clôture de la MA (peu importe celui à prendre pour une nouvelle barre puisqu'elle vient d'apparaître ; toutes les valeurs МА seront égales). Imaginez la situation où les MA sont croisées quelque part au milieu de la barre qui vient d'apparaître, mais où elles ne le sont pas au prix d'ouverture. Sur la nouvelle barre suivante, cette intersection est complètement perdue car nous prenons le prix de clôture de la barre précédente (et ils se sont croisés quelque part entre le prix d'ouverture et de clôture). Les signaux ne se produiront que dans le rare cas que j'ai décrit à l'origine, lorsque la MA croise précisément le prix de clôture de la barre. Cela signifie que si la barre actuelle est ouverte, il existe déjà une limitation selon laquelle МА doit être appliqué aux prix ouverts.
J'ai traité l'exemple que j'ai donné en introduisant une inégalité non stricte. Essayez de tester la barre dans mon post précédent (où il y a deux croisements MA dans une barre) et voyez si votre robot détecte ces croisements ? Si ça ne fonctionne que lorsqu'une barre apparaît, c'est impossible. Seulement si ça fonctionne par tics. Et j'ai déjà décrit les pièges qui s'y trouvent.
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 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 aussi été écrites par des humanoïdes comme nous), mais il est nécessaire d'avoir son propre raisonnement raisonnable.
Je n'invente pas l'hyperdoloïde. Si je voulais inventer, je ne demanderais rien ici. Et je ne suis pas en train de faire le malin, mais de donner des contre-exemples (y compris pour votre normalisation préférée). En ce qui concerne les croisements à l'intérieur d'une barre. Les TS sur MA les plus primitifs ouvrent des transactions à leur intersection. Au prochain croisement dans la direction opposée, la première chose à faire est de fermer la transaction ouverte à l'ancien croisement et d'en ouvrir une nouvelle à l'opposé. Si je manque un croisement (et dans le cas d'un croisement à l'intérieur de la barre deux fois, pour ainsi dire, ce sera le cas), alors je manque un signal. Et par conséquent, je ne ferme pas la transaction actuelle. Et mon robot a deux transactions actives, alors qu'il devrait toujours y avoir une seule transaction dans ce TS. C'est pourquoi tout croisement est important. En outre, concernant le prix à l'ouverture d'une bougie. Dans ce cas, la part du lion des signaux de croisement sera manquée si nous prenons par exemple les valeurs MA aux prix de clôture. Un exemple simple - nous prenons le prix de clôture de la MA (peu importe celui à prendre pour une nouvelle barre puisqu'elle vient d'apparaître ; toutes les valeurs МА seront égales). Imaginez la situation où les MA sont croisées quelque part au milieu de la barre qui vient d'apparaître, mais où elles ne le sont pas au prix d'ouverture. Sur la nouvelle barre suivante, cette intersection est complètement perdue car nous prenons le prix de clôture de la barre précédente (et ils se sont croisés quelque part entre le prix d'ouverture et de clôture). Les signaux ne se produiront que dans le rare cas que j'ai décrit à l'origine, lorsque la MA croise précisément le prix de clôture de la barre. Cela signifie que si la barre actuelle est ouverte, il existe déjà une limitation selon laquelle МА doit être appliqué aux prix ouverts.
J'ai traité l'exemple que j'ai donné en introduisant une inégalité non stricte. Essayez de tester la barre dans mon post précédent (où il y a deux croisements MA dans une barre) et voyez si votre robot détecte ces croisements ? Si ça ne fonctionne que lorsqu'une barre apparaît, c'est impossible. Seulement si ça fonctionne par tics. Et là, j'ai déjà décrit les pièges
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 la même manière. En fait, c'est précisément cette propriété qui rend l'existence des machines à calculer possible.
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 certainement être lues au moins parfois (elles ont aussi été écrites par l'homme comme nous), mais il faut avoir ses propres considérations raisonnables.
Si la normalisation n'était pas nécessaire lors de la comparaison de nombres de type double à l'aide de l'une des méthodes proposées dans la documentation, ces questions ne se poseraient pas non plus.
Et je n'ai pas besoin d'utiliser la normalisation pour obtenir la précision nécessaire au déclenchement de toute condition dans mes codes. Sans compter que l'utilisation de la normalisation des valeurs à différentes décimales dans la comparaison, peut simplement être en soi pratique et nécessaire lors de la définition des conditions de comparaison, en fonction des tâches à résoudre.
P./S. : Mais, en général, je l'ai mentionné dans ce fil et avant:
À propos de la possibilité, à l'aide de la normalisation, d'ajuster le niveau de précision requis des comparaisons (et/ou des valeurs de sortie) et/ou des erreurs tolérables pour certaines tâches et certains objectifs, ce qui, entre autres, permet aux conditions du programme de fonctionner exactement à l'endroit et de la manière prévus lors de la prescription de conditions spécifiques dans le code.