Ce que rapportent les fonctions Lowest et Highest - page 3

 
Candidat, je vais essayer de décrire l'instabilité de l'opération .

Une option. Il y en a d'autres.
Nous avons le premier rayon. Pour plus de simplicité - à partir de la barre de zéro. La barre de zéro a un maximum et un minimum. Le prix se déplace à l'intérieur de la barre sans changer son extrema. Puisque les extrema ne changent pas, le premier rayon devrait rester immobile et ne pas bouger. Mais ce n'est pas le cas. Le premier rayon saute. Change sa position. Il s'agit simplement d'une description de la manifestation externe de l'instabilité. Si l'algorithme fonctionne de manière stable et que les paramètres du marché (maximum et minimum de la dernière barre), dont dépend l'opération de zigzag, ne changent pas, le premier rayon ne devrait pas faiblir. J'ai moi-même lutté contre ce problème. Mais les particularités remarquées des fonctions de recherche m'ont obligé à aller sur le forum.
========================
Lorsque nous déplaçons la fenêtre (shift,shift+ExtDepth) pendant le calcul de l'indicateur, l'apparition d'un nouvel extremum peut être liée soit à un nouveau prix, soit au fait que l'ancien extremum a quitté la fenêtre. - Il serait préférable de le spécifier explicitement. Pour que ce soit clair. Dans la description de la langue. Pour ne pas explorer les possibilités cachées de la langue.

À cette fin, la ligne if(highpos!=shift) val=0.0 ; . Je ne comprends pas comment cela est fait dans le code standard. Si l'on en juge par le fait que les extrema pendants disparaissent dans ma variante, cela est soit mal fait, soit pas fait du tout. - Ma solution à ce problème est différente : si (High[shift]=val) ZigZagBuffer[shift]=val ; et si (Low[shift]=val) ZigZagBuffer[shift]=val ;
. Mais en fait, c'est la même chose. Mais cela ne résout pas tous les problèmes. C'est la façon dont nous combattons la conséquence et non la cause. J'ai essayé de combattre la conséquence de la même manière. Mais sur le premier rayon, cela ne fonctionne pas. Le fait est que l'algorithme zigzag, disons, ne dissèque pas. Laissez-moi vous expliquer. Le calcul est effectué sur l'ensemble de l'historique. Et si nous en corrigeons une partie, le traitement reste encore incomplet près de la barre du zéro, pour ainsi dire. Je ne trouve pas les mots justes. Cette incomplétude près de la barre du zéro fait donc ressortir le problème de l'identification correcte des extrema.

J'ai essayé d'ajuster les paramètres de la fenêtre (shift,shift+ExtDepth) il n'y a pas si longtemps. J'ai fait des expériences avec la fenêtre l'autre jour aussi. Mais jusqu'à présent sans résultat.
 
Le fait est que l'algorithme zig-zag, disons, ne dissèque pas. Laissez-moi vous expliquer. Le calcul est effectué sur l'ensemble de l'historique. Et si nous en corrigeons une partie, le traitement reste encore incomplet près de la barre du zéro, pour ainsi dire. Je ne trouve pas les mots justes. Cette incomplétude près de la barre du zéro fait donc ressortir le problème de l'identification correcte des extrema. <br/ translate="no">.


Ce problème est connu et est résolu théoriquement (j'ai l'algorithme dans ma tête depuis longtemps). Quoi qu'il en soit, si aucune autre solution n'apparaît, je vais optimiser l'algorithme Zigzag. La procédure est la suivante :
1) le premier passage est effectué sur l'ensemble de l'historique comme dans l'algorithme actuel
2) à chaque tick de la barre zéro jusqu'à la fin de l'historique, deux extrema du zigzag sont recherchés, le dernier extremum est tué de force.
3) à partir de l'avant-dernier (maintenant le dernier), la procédure standard de calcul ZigZag est à nouveau exécutée.
4) si l'extrémité actuelle (la queue du ZigZag) peut théoriquement être un extremum (on a le plus haut du dernier bas ou vice versa), elle devient aussi un extremum.
5) avec un nouveau tic-tac en recommençant à partir du point 2)
 
nen:
Mais ça n'est pas arrivé. La première poutre vacille. Il change de position.

Je ne l'ai pas encore vu. Est-ce qu'il laisse une extrémité de la poutre fixe ? Et lequel. Si c'est sur la barre de zéro, il faudrait peut-être examiner de plus près les conditions dans lesquelles les variables de type double sont comparées ?

.
Lorsque nous déplaçons la fenêtre pendant le calcul de l'indicateur (shift,shift+ExtDepth), l'apparition d'un nouvel extremum peut être liée soit au nouveau prix, soit à l'ancien extremum qui a quitté la fenêtre. - Il serait préférable de le spécifier explicitement. Pour que ce soit clair. Dans la description de la langue.

Cela me semble faire référence à l'algorithme plutôt qu'à la langue. Ainsi, un rappel que les fonctions dont nous discutons recherchent en fait la valeur maximale (minimale) du prix sur l'intervalle, plutôt qu'un extremum, serait approprié dans un livre ou dans certains commentaires.
.
Pour ce faire, j'ai inséré la ligne if(highpos!=shift) val=0.0 ; . Je ne comprends pas comment cela est fait dans le code standard. A en juger par le fait que les extrema pendants disparaissent dans ma variante, soit ce n'est pas fait correctement, soit ce n'est pas fait du tout. - Ma solution à ce problème est différente : si (High[shift]=val) ZigZagBuffer[shift]=val ; et si (Low[shift]=val) ZigZagBuffer[shift]=val ;
J'aime mieux ma version :). Il fonctionne avec des entiers. Dans un tel cas, la comparaison de doubles (comme Low[shift]==val) peut tout simplement apparaître comme des battements.
 
Rosh, j'ai la même option. Dans ma tête. Il y a quelques points vagues qui m'empêchent de le réaliser. Disons-le comme ça. Le point 4) est quelque peu en dehors de l'algorithme. C'est déjà un autre algorithme. Et lorsque la section traitée au point 4) sera disponible pour l'histoire, son traitement avec l'algorithme à partir du point 1) pourra conduire à dessiner d'autres extrema. C'est-à-dire que le temps réel et l'histoire seront différents. Cela, à mon avis, n'est pas acceptable.
 
Rosh J'ai la même option. Dans ma tête. Il y a quelques points vagues qui m'empêchent de le réaliser. Disons-le comme ça. Le point 4) est quelque peu en dehors de l'algorithme. Il s'agit d'un algorithme différent. Et lorsque la section traitée au point 4) sera disponible pour l'histoire, son traitement avec l'algorithme à partir du point 1) pourra conduire à dessiner d'autres extrema. C'est-à-dire que le temps réel et l'histoire seront différents. Cela, à mon avis, n'est pas acceptable.


le point 4) au tick suivant est traité avec un fichier passant par le point 2)
 
Дело в том, что алгоритм зигзага, скажем так, не расчленяется. Поясню это. Просчет проводится по всей истории. И если мы в какой-то части исправим ошибки, то в районе нулевого бара процесс обработки остается, скажем так, незавершенным. Затрудняюсь подобрать правильные слова. Так вот эта незавершенность в районе нулевого бара и вытаскивает на свет проблему правильного поиска экстремумов.


Ce problème est connu, et théoriquement résolu (il y a un algorithme en tête depuis longtemps).
Y a-t-il une description verbale de ce que doit faire le zigzag ? Quelque chose comme une spécification technique.
 
Je ne l'ai pas encore vu. Est-ce qu'il laisse une extrémité de la poutre attachée ? Et lequel. Si c'est le cas, alors il faudrait peut-être examiner de plus près les conditions dans lesquelles des variables de type double sont comparées ?
Le problème est que je teste l'indicateur qui utilise le zigzag dans des conditions très strictes. En minutes et avec des paramètres 2-1-1. Quel est le but de ces tests ? Ce type de test révèle assez rapidement toutes les failles cachées. En outre, il est souhaitable que l'indicateur fonctionne sur tous les horizons temporels sans exception. Le marché est une chose fractale. Il y a beaucoup de gens qui font du commerce sur les minutes. Pourquoi devrions-nous les priver de l'opportunité de travailler avec l'outil familier sur de petits délais ?

J'aime mieux ma version). Il fonctionne avec des entiers. En effectuant une telle comparaison de doubles (de type Low[shift]==val), cela peut provoquer des battements.
Jusqu'à présent, je n'ai pas rencontré de difficultés à travailler avec double. Ces numéros sont conservés en mémoire sans modification. Mais ma comparaison prend les valeurs d'une seule cellule de mémoire. S'il y a un problème à cet endroit, il s'agit d'un problème de matériel (c'est-à-dire d'ordinateur). Il faut faire quelque chose avec le matériel.

Il me semble que cela ne fait pas référence à la langue, mais à l'algorithme. Ainsi, un rappel que les fonctions dont nous discutons recherchent en fait la valeur maximale (minimale) du prix sur l'intervalle, plutôt qu'un extremum, serait approprié pour un livre ou quelques commentaires.

J'ai juste appelé ça un extremum. Il s'agit en fait du maximum et du minimum de l'intervalle choisi. C'est une prononciation longue. Mais le sens est le même.
 
Y a-t-il une description verbale de ce que doit faire le zigzag ? Quelque chose comme des termes de référence ?
Il y en a eu pendant longtemps sur CodeBase.mql4.com. Mais cette description est très difficile à comprendre. Et contradictoire. Pendant l'été, je pense que Slava a affiné le code du zigzag. Seule une partie de la description précédente est restée sur le site après cela.
 
nen:
Le travail en double n'a pas posé de difficultés jusqu'à présent. Ces numéros sont conservés en mémoire sans modification. Et ma comparaison prend les valeurs d'un seul emplacement mémoire. Si un problème survient ici, c'est une question de matériel - l'ordinateur. Il faut faire quelque chose avec le matériel.
Eh bien, je suis guidé par le code dans la branche. Et il calcule la valeur à chaque fois. Il est juste plus sûr de ne pas utiliser == quand on compare des dou...
 
Eh bien, je me base sur le code de la branche. Et il calcule la valeur à chaque fois. C'est vrai, ça l'est. Le numéro d'une cellule est trouvé. A partir de cette cellule (série temporelle), la valeur de la barre maximale ou minimale est prise. On considère que le maximum a été trouvé sur cette barre. Cette valeur est ensuite placée dans le tampon de l'indicateur avec le numéro trouvé. Le maximum de l'indicateur doit correspondre au maximum de la barre. Dans mon code, le maximum est également pris dans le tableau (timeseries) avec le même numéro trouvé et comparé à la valeur de val. On vérifie si on fait bien les choses : on met dans le tampon avec ce numéro la valeur de val. Elle doit également être égale au maximum de la barre. La comparaison de chiffres pris au même endroit est tout à fait correcte.
Raison: