Comparaison de la moyenne mobile (et de tout autre indicateur) et de l'erreur - page 2
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
Cela n'a rien à voir avec mql en principe. Prenons un langage de programmation abstrait. Dans cet exemple particulier que j'ai donné, le problème principal est que les valeurs de la différence des muwings dans une même barre ne sont pas égales (2e-16 dans le premier calcul et exactement 0 dans le second). Dans ce cas, cette intersection ne peut être déterminée d'aucune manière. Si nous revenons à mql, la normalisation implique d'arrondir le nombre(ou plutôt de laisser tomber tous les nombres après un certain signe, comme dans la fonction Sish floor, mais à une certaine décimale). Alors comment savoir à quel chiffre normaliser ? Si le mauvais chiffre est choisi, toutes les valeurs peuvent TOUJOURS être arrondies à 0 exactement. La normalisation est donc dangereuse ici et ne résout généralement pas le problème.
Quant à ce qu'Alexey Lebedev a écrit. Oui, je pensais dans ce sens. Mais si nous comparons les deux différences par plus ou égale à 0, il y a une probabilité d'obtenir un faux signal (par exemple, la situation théoriquement possible lorsque les muwings entre des barres voisines ont exactement les mêmes valeurs). Dans ce cas, leur différence ne change pas le signe (il n'y a pas de croisement), mais le signal de croisement sera déterminé de manière programmatique. Vous pourriez ne mettre qu'une seule comparaison sur plus ou égal, comme vous l'avez suggéré. Mais alors le problème est que dans le calcul, dans cette situation, d'abord il ne sera pas égal à 0 (2e-16), et sur la barre suivante il sera exactement 0 mais ce sera une comparaison stricte.
Il est important de comprendre pourquoi la même différence, lorsqu'elle est calculée sur des barres différentes, ne produit PAS le même résultat. Si le résultat était le même, le problème serait toujours résolu en introduisant une comparaison non stricte.
Lors de la normalisation, oui, il y a un arrondi à une décimale donnée. Il ne s'agit pas d'éliminer tous les chiffres après un certain signe, mais d'arrondir.
Si je vous comprends exactement dans ce contexte (je prends à la fois votre premier message avec capture d'écran et votre second), diverses expériences avec cette méthode, y compris la prise en compte de DoubleToString lors de l'impression, je suppose, peuvent encore vous aider. Rosomah l'a mentionné avant moi à vous.
Y compris, aider à déterminer pour vous-même à quel chiffre à normaliser à toutes les tâches, ou si dans certains cas, la normalisation est nécessaire (en cas de doutes, l'application ou non sur l'ensemble des facteurs connexes, y compris que le programme peut alors être appliqué dans différents DC et, par conséquent, les valeurs calculées peuvent être différentes).
De mon point de vue, le danger d'obtenir des signaux qui peuvent être considérés comme faux, en fonction de la tâche à accomplir, peut être juste lorsque la normalisation n'est pas appliquée (ou lorsqu'il n'y a pas de comparaison de la première manière en raison d'une petite valeur) où ce ne serait pas un problème.
En outre, si DoubleToString n'est pas appliqué à l'impression, il se peut que l'on croie à tort que la même différence ou les mêmes valeurs ne constituent pas le même résultat.
/* Juste au cas où, je voudrais mentionner à nouveau que lors de l'impression de nombres de type double, il est nécessaire d'utiliser DoubleToString, car la sortie convertit une valeur numérique en une valeur texte. Par conséquent, si cette fonction n'est pas utilisée, vous risquez de voir apparaître des erreurs qui ne sont pas réellement présentes.
Le nombre de décimales dans cette fonction, bien sûr, n'est pas inférieur au nombre de décimales des valeurs normalisées. Et pour les valeurs non normalisées, le nombre de décimales est plus important.
Le calcul de la fonction iMA est très probablement optimisé. Première valeur = somme(close)/N, deuxième = valeur précédente de la MA+(nouvelle close - ancienne close)/N.
Donc les iMAs en général pour une même barre peuvent donner des valeurs différentes des deux muwings à des moments d'appel différents ?
Lors de la normalisation, oui, il y a un arrondi à la décimale spécifiée. Il s'agit d'arrondir, et non d'éliminer tous les chiffres après une certaine décimale.
Si je vous comprends exactement dans ce contexte, ce que vous voulez dire (je tiens compte à la fois de votre premier message avec capture d'écran et de votre deuxième message), alors diverses expériences avec cette méthode, y compris la prise en compte de DoubleToString lors de l'impression, je crois, peuvent encore vous aider.
Y compris, aider à définir pour vous-même à quel chiffre à normaliser à toutes les tâches, ou si la normalisation est nécessaire dans certains cas (en cas de doute, utiliser ou ne pas utiliser sur l'ensemble des facteurs d'accompagnement, y compris que le programme peut alors être appliqué dans différents DC et, respectivement, les valeurs calculées résultantes peuvent être différentes).
De mon point de vue, le danger d'obtenir des signaux qui pourraient être considérés comme faux, en fonction de la tâche à accomplir, peut être juste lorsque la normalisation n'est pas appliquée (ou lorsque la première méthode n'est pas comparée en raison d'une petite valeur) où cela ne ferait pas de mal.
En outre, si DoubleToString n'est pas appliqué à l'impression, il se peut que l'on croie à tort que la même différence ou les mêmes valeurs ne constituent pas le même résultat.
/* Juste au cas où, je voudrais mentionner à nouveau que lors de l'impression de nombres de type double, il est nécessaire d'utiliser DoubleToString, car la sortie convertit une valeur numérique en une valeur texte. Par conséquent, si cette fonction n'est pas utilisée, les erreurs suivantes peuvent se produire
Le nombre de décimales dans cette fonction, bien sûr, n'est pas inférieur au nombre de décimales des valeurs normalisées. Et pour les valeurs non normalisées, le nombre de décimales est plus important.
Il est clair que le dernier chiffre significatif est arrondi. Mais si, par exemple, vous mettez 5 chiffres significatifs pour le nombre 0,000016, il sera 0,00002, et s'il y a moins de chiffres significatifs, il sera toujours 0. Par conséquent, il est toujours impossible d'arrondir à un chiffre précis. Les valeurs de la MA ne dépendent pas seulement de la période, mais aussi des barres elles-mêmes. Par conséquent, il n'est pas clair comment définir le nombre de chiffres significatifs pendant la normalisation dans le cas général.
Ce que je ne comprends pas dans la valeur infinitésimale, c'est comment l'appliquer. Infinitésimal (erreur) est utilisé pour comparer un nombre réel à 0. Moi, par contre, j'ai besoin de comparer la différence. La situation ici pourrait être encore pire. Par exemple, j'ai fixé un certain epsilon. Lorsque la différence est supérieure à epsilon, je la considère comme positive. Quand il est inférieur à moins l'epsilon, il est négatif. Lorsqu'il se trouve à l'intérieur des limites, il est égal à 0. Mais alors comment déterminer le changement du signe de la différence ? Par exemple, la différence de muvings sur deux barres est à epsilon près. Mais dans le premier cas, il est positif, dans le second, il est négatif (c'est-à-dire que le croisement s'est DÉJÀ produit). Et moi, en tenant compte de l'introduction de l'erreur, je considérerai que la différence est de 0. Il faut alors changer la condition de changement de signe. Conditionnellement, le signal de deux MA se croisant de haut en bas dans ce cas sera à la fois une simple comparaison de <0 (était) et >0 (est devenu), et =0 (était) et >0 (est devenu). Et surtout, dans le cas décrit (lorsque les valeurs au même point sont différentes pour différents appels), l'introduction de cette erreur n'aide pas. Cette différence peut toujours être telle que, quel que soit l'epsilon choisi, vous n'obtiendrez pas de signal.
Il est clair que le dernier chiffre significatif est arrondi. Mais si, par exemple, pour un nombre 0.000016 vous mettez une normalisation avec 5 chiffres, ce sera le nombre 0.00002, et si moins de chiffres, ce sera toujours 0. Par conséquent, il est toujours impossible d'arrondir à un chiffre précis. Les valeurs de la MA ne dépendent pas seulement de la période, mais aussi des barres elles-mêmes. Par conséquent, il n'est pas clair comment définir le nombre de chiffres significatifs pendant la normalisation dans le cas général.
Ce que je ne comprends pas dans la valeur infinitésimale, c'est comment l'appliquer. Infinitésimal (erreur) est utilisé pour comparer un nombre réel à 0. Moi, par contre, j'ai besoin de comparer la différence. La situation ici pourrait être encore pire. Par exemple, j'ai fixé un certain epsilon. Lorsque la différence est supérieure à epsilon, je la considère comme positive. Quand il est inférieur à moins l'epsilon, il est négatif. Lorsqu'il se trouve à l'intérieur des limites, il est égal à 0. Mais alors comment déterminer le changement du signe de la différence ? Par exemple, la différence de muvings sur deux barres est à epsilon près. Mais dans le premier cas, il est positif, dans le second, il est négatif (c'est-à-dire que le croisement s'est DÉJÀ produit). Et moi, en tenant compte de l'introduction de l'erreur, je considérerai que la différence est de 0. Il faut alors changer la condition de changement de signe. Conditionnellement, le signal de deux MA se croisant de haut en bas dans ce cas sera à la fois une simple comparaison de <0 (était) et >0 (est devenu), et =0 (était) et >0 (est devenu). Et surtout, dans le cas décrit (lorsque les valeurs au même point sont différentes lors de différents appels), l'introduction de cette erreur ne sert à rien. Cette différence peut toujours être telle, que quel que soit l'epsilon choisi, vous n'obtiendrez pas de signal.
Je pense que lorsque vous résolvez un problème particulier, vous pouvez également compter sur la précision des chiffres significatifs des décimales. Au double, il s'agit de 15 chiffres significatifs, selon la Documentation. Le format de la précision de normalisation, de 0 à 8, selon la Documentation. DoubleToString a ses propres particularités de formats de précision.
En outre, iMA est, de mon point de vue, une fonction qui tient compte du fait que les valeurs qui en découlent seront appliquées dans différentes situations et pour résoudre différents problèmes. Par conséquent, les valeurs qu'il produit peuvent être traitées différemment, y compris pour des tâches spécifiques.
En outre, le calcul des moyennes est un calcul mathématique. Par exemple : (1.20525 + 1.20598 + 1.2081)/3 = 1.2064433333... De même, les valeurs calculées avec des arrondis faibles ou étendus augmentent les possibilités d'application des calculs.
Juste au cas où, je veux mentionner qu'au lieu de iMA, vous pouvez utiliser les fonctions de la bibliothèque MovingAverages, qui est incluse dans le paquetage standard du terminal. Vous pouvez également utiliser vos propres fonctions basées sur celles de cette bibliothèque.
/* Dans les calculs mathématiques, il peut y avoir desparticularités à travailler avec des nombres de type double */.
Pour les epsilons, par contre, je passe mon tour.
P./S. : Donc, je pense que les expériences peuvent vous aider. Un raisonnement théorique sans expériences pratiques (sur une grande quantité de données) pour des tâches spécifiques, notamment, peut prêter à confusion et éloigner des solutions acceptables.
Dina Paches:
...
Quel gâchis. Nous comparons les mascottes depuis 300 jours... Normaliser aux chiffres et ne pas s'embêter...
Vous pouvez normaliser les valeurs directement (la différence - pas moyen). Mais là encore, le code de référence ala donné pour la comparaison des MA doit être modifié et il faut de toute façon entrer une inégalité non stricte. Par ailleurs, la question des différentes valeurs de MA sur une même barre lorsqu'elles sont calculées à des moments différents reste ouverte. Si le problème se répète, il n'est pas certain que même la normalisation et l'introduction d'une inégalité non stricte le résolvent complètement. De plus, le cas où les muwings d'une même barre se croisent deux fois, vous ne pouvez pas l'attraper, si vous analysez non pas par ticks, mais par l'ouverture d'une nouvelle barre. Peut-être pouvez-vous partager votre expérience, comment agissez-vous dans cette situation ?
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, alors le conseiller expert doit clairement surveiller l'ouverture d'une nouvelle barre, et après coup, vérifier les croisements.
Décidez d'abord vous-même - trader à l'ouverture des barres ou à chaque tick, puis écrivez votre code. Et, par conséquent, le tester de la même manière.
Dina, je suis stupéfait de ta patience angélique...
Merci, Artem, mais il s'avère malheureusement qu'elle peut aussi avoir des limites.