une stratégie commerciale basée sur la théorie des vagues d'Elliott - page 11

Nouveau commentaire
 
Je lis votre discussion avec intérêt, et avec d'autant plus d'intérêt que les méthodes que vous utilisez sont très proches de moi de par mon occupation professionnelle. Permettez-moi d'apporter une petite contribution. <br / translate="no">
Je n'utilise pas d'algorithmes de lissage - ils sont tous à la traîne.

Essayez la transformation DCT avec le noyau de diffraction - elle lisse très bien, sans aucun décalage. IMHO, il fonctionne mieux que le LCF traditionnel. Voici quelques morceaux de code C++. La façon de l'utiliser, je pense, est claire d'après les commentaires.



Merci - je vais essayer.

Bonne chance et lancez-vous dans les tendances.
 
Alexjou, montrez-moi, pour comparaison, le lissage par muvin ordinaire et DCT, avec la même "fenêtre" et sur la même tranche de graphique. Par exemple, une photo dans le studio :) Je pense que ce test est de la plus haute qualité.
 
Je ne peux pas le faire avec exactement les mêmes paramètres, car il n'y a pas de correspondance biunivoque. Avec des paramètres proches les uns des autres, je peux essayer.
 
"MQL4 : Lissage DCT"
 
Belle gravure DCT, mais il y a une supposition qu'elle est si magnifiquement post-factum. Ou ai-je tort ?
 
Magnifique gravik DCT, mais il y a une supposition qu'il est aussi beau post-factum. Ou ai-je tort ?

En général, c'est correct. Le problème est que pour le dessiner, nous devons à chaque fois recalculer le tableau entier d'un nombre donné de barres, c'est-à-dire que IndicatorCounted ne fonctionnera pas. La question est de savoir comment dessiner correctement ce tableau calculé par la suite, afin de ne pas corriger l'histoire après coup ? Si nous redessinons l'ensemble du tableau, l'historique sera corrigé. Si nous ne redessinons que les dernières barres, toute la beauté sera perdue :(((( Le tout est particulièrement impressionnant dans une fenêtre séparée.
Je pense que si la méthodologie de TC exige explicitement le recalcul des tableaux (comme celle de Vladislav, pour autant que j'aie compris ses idées), cet inconvénient ne sera pas très important.
 
Si l'on redessine l'ensemble, on peut modifier l'historique, si l'on ne redessine que les dernières barres, toute la beauté est perdue :(((( Tout cela est particulièrement impressionnant dans une fenêtre séparée. <br/ translate="no">Je pense que si la méthodologie du CT exige explicitement le recalcul des tableaux (comme j'ai compris les idées de Vladislav), cet inconvénient ne sera pas très significatif.

Whoa, whoa...
A quoi ça sert tout ça ?
Il ne s'agit pas de savoir qui est le meilleur artiste post-facto :).

La question est de savoir si la méthodologie donnée permet d'obtenir une indication de la solution avec une forte probabilité de succès.
D'après ma compréhension de la physique du processus, la pointe de cette belle courbe va osciller d'avant en arrière à chaque tic, représentant alternativement l'extrême et l'absence d'extrême.
Le dessin est significatif s'il montre la "trace" de la fin de la ligne (belle ex post facto).
Je ne pense pas que cette trace sera très différente du MA.
Vous obtiendrez soit un lag, soit un twitch.
 
Exactement... Pire encore : "l'extrémité de cette belle courbe" après différenciation passe alternativement par zéro, puis non. Pour moi, le fait d'avoir un passage à zéro stable dans un certain couloir est extrêmement important. Comme je travaille avec des barres entièrement formées, je ne recalcule l'indicateur que sur celles-ci - comme un palliatif. Dans mon excuse, je peux seulement dire que j'ai vu quelque part (malheureusement, je ne peux pas me rappeler où exactement) une description d'un indicateur avec un générateur LCF adaptatif intégré. Le filtre généré variait en fonction du comportement du prix et, si je me souviens bien, il recalculait l'ensemble des barres. Comme il n'y avait pas de code source, je n'ai pas téléchargé la version de démonstration. Ils voulaient beaucoup d'argent pour un modèle entièrement fonctionnel.
 
Et d'ailleurs. Je serais très reconnaissant si quelqu'un pouvait m'expliquer la signification et l'utilisation de la fonction SetIndexDrawBegin(...).
La référence se lit comme suit :
<br / translate="no"> void SetIndexDrawBegin( int index, int begin)

Définit le numéro de la barre du graphique qui doit être utilisée pour commencer à dessiner la ligne de l'indicateur spécifié. Les valeurs du tableau d'indicateurs dont l'index est inférieur au numéro de barre spécifié ne seront pas dessinées dans le graphique et affichées dans la DataWindow. La valeur par défaut est 0.
...

"Peu importe le nombre de fois où je l'ai expérimenté, je n'ai jamais obtenu de résultats visibles dans les graphiques. Supposons que je définisse le "numéro de barre spécifié" comme étant égal à 10. Question : où ne doit-elle pas être dessinée - avant cette barre (c'est-à-dire de +Inf à celle-ci) ou après celle-ci (c'est-à-dire de celle-ci à 0) ? Pour une raison quelconque, il est dessiné partout. Et comment l'indice peut-il être inférieur à zéro fixé par défaut, à moins, bien sûr, que l'on essaie de se projeter dans l'avenir dans le système de coordonnées MT ? Peut-être que je rate quelque chose ?
 
Et d'ailleurs. Je serais très reconnaissant si quelqu'un pouvait m'expliquer la signification et l'utilisation de la fonction SetIndexDrawBegin(...)
.
Dans un fil voisin. "Je n'arrive pas à trouver comment peindre l'indicateur"
Neep 13.03.06 20:56.
Cette seule fonction est utile.
1...456789101112131415161718...309
Nouveau commentaire