eine Handelsstrategie auf der Grundlage der Elliott-Wellen-Theorie - Seite 11

Neuer Kommentar
 
Ich habe Ihre Diskussion mit Interesse gelesen, und zwar mit noch größerem Interesse, weil die von Ihnen angewandten Methoden mir aufgrund meiner beruflichen Tätigkeit sehr nahe sind. Gestatten Sie mir, einen kleinen Beitrag zu leisten. <br / translate="no">
Ich verwende keine Glättungsalgorithmen - sie hinken alle hinterher

Versuchen Sie die DCT-Wandlung mit einem Beugungskern - glättet sehr gut, überhaupt keine Verzögerung. Meiner Meinung nach funktioniert es besser als das traditionelle LCF. Nachfolgend finden Sie einige Teile des C++-Codes. Die Art und Weise, wie sie zu verwenden ist, geht meines Erachtens aus den Kommentaren hervor.



Danke - ich werde es ausprobieren.

Viel Glück und viel Erfolg mit den Trends.
 
Alexjou, bitte zeigen Sie mir zum Vergleich die Glättung durch gewöhnliche muvin und DCT, mit dem gleichen "Fenster" und auf dem gleichen Abschnitt des Diagramms. D.h. ein Bild im Atelier :) Ich glaube, dass dies der qualitativ hochwertigste Test ist.
 
Ich kann es nicht mit genau denselben Parametern machen, da es keine Eins-zu-eins-Entsprechung gibt. Mit Parametern, die nahe beieinander liegen, kann ich es versuchen.
 
"MQL4: DCT-Glättung"
 
Schöne DCT-Gravur, aber es gibt eine Annahme, dass es so schön postfaktisch ist. Oder liege ich da falsch?
 
Schöne gravik DCT, aber es gibt eine Annahme, dass es so schön ist post-factum. Oder liege ich da falsch?

Im Allgemeinen ist dies richtig. Das Problem ist, dass, um es zu zeichnen, müssen wir jedes Mal das gesamte Array von einer bestimmten Anzahl von Bars neu zu berechnen, dh IndicatorCounted wird nicht funktionieren. Die Frage ist, wie man dieses berechnete Feld im Nachhinein korrekt zeichnet, um die Geschichte nicht nachträglich zu korrigieren. Wenn wir das gesamte Feld neu zeichnen, wird der Verlauf korrigiert. Wenn wir nur die letzten Balken neu zeichnen, geht die ganze Schönheit verloren :(((( In einem separaten Fenster sieht das Ganze besonders beeindruckend aus.
Ich denke, wenn die TC-Methode ausdrücklich die Neuberechnung von Arrays erfordert (wie die von Vladislav, soweit ich seine Ideen verstanden habe), wird dieser Nachteil nicht sehr bedeutend sein.
 
Wenn man das Ganze neu zeichnet, wird man den Verlauf optimieren, wenn man nur die letzten Takte neu zeichnet, geht die ganze Schönheit verloren :(((( Das Ganze sieht in einem separaten Fenster besonders eindrucksvoll aus. <br/ translate="no"> Ich denke, wenn die TC-Methode ausdrücklich die Neuberechnung von Arrays erfordert (wie ich Vladislavs Ideen verstanden habe), wird dieser Nachteil nicht sehr bedeutend sein.

Wow, wow...
Wozu soll das alles gut sein?
Es geht nicht darum, wer der beste Post-Facto-Künstler ist:).

Die Frage ist, ob die gegebene Methodik es erlaubt, einen Hinweis auf die Lösung mit einer hohen Erfolgswahrscheinlichkeit zu erhalten.
Nach meinem Verständnis der Physik des Prozesses wird die Spitze dieser schönen Kurve mit jedem Ticken hin- und herwackeln und abwechselnd das Extrem und das Fehlen eines solchen darstellen.
Die Zeichnung ist aussagekräftig, wenn sie die "Spur" des Endes der (ex post facto schönen) Linie zeigt.
Ich glaube nicht, dass sich diese Spur wesentlich von der MA unterscheiden wird.
Sie erhalten entweder einen Lag oder ein Zucken.
 
Ganz genau... Schlimmer noch: "die Spitze dieser schönen Kurve" kreuzt nach der Differenzierung abwechselnd den Nullpunkt und dann wieder nicht. Für mich ist die Tatsache eines stabilen Nulldurchgangs in einem bestimmten Korridor extrem wichtig. Da ich mit fertig geformten Balken arbeite, berechne ich den Indikator nur für diese Balken neu - als Palliativmaßnahme. Zu meiner Entschuldigung kann ich nur sagen, dass ich irgendwo (leider kann ich mich nicht mehr genau erinnern, wo) eine Beschreibung eines Indikators gesehen habe, in den ein adaptiver LCF-Generator eingebaut ist. Der erzeugte Filter variierte in Abhängigkeit vom Kursverhalten und berechnete, soweit ich mich erinnere, die gesamte Reihe von Balken neu. Da es keinen Quellcode gab, habe ich die Demoversion nicht heruntergeladen. Sie wollten eine Menge Geld für ein voll funktionsfähiges Gerät.
 
Und nebenbei bemerkt. Ich wäre sehr dankbar, wenn mir jemand die Bedeutung und Verwendung der Funktion SetIndexDrawBegin(...) erklären könnte.
Der Hinweis lautet:
<br / translate="no"> void SetIndexDrawBegin( int index, int begin)

Legt die Nummer des Balkens im Diagramm fest, der zum Zeichnen der angegebenen Indikatorlinie verwendet werden soll. Indikator-Array-Werte mit einem Index, der kleiner als die angegebene Balkenanzahl ist, werden nicht im Diagramm gezeichnet und im DataWindow angezeigt. Der Standardwert ist 0.
...

"Egal, wie oft ich damit experimentiert habe, ich habe nie Ergebnisse erzielt, die in den Tabellen sichtbar waren. Angenommen, ich setze die "angegebene Taktnummer" auf 10. Frage: Wo sollte er nicht gezeichnet werden - vor diesem Balken (d.h. von +Inf bis zu ihm) oder nach ihm (d.h. von ihm bis 0)? Aus irgendeinem Grund wird es überall gezeichnet. Und wie kann der Index kleiner als der standardmäßig eingestellte Wert Null sein, es sei denn, man versucht, im MT-Koordinatensystem in die Zukunft zu schauen? Vielleicht übersehe ich etwas?
 
Und nebenbei bemerkt. Ich wäre sehr dankbar, wenn mir jemand die Bedeutung und Verwendung der Funktion SetIndexDrawBegin(...) erklären könnte
.
In einem benachbarten Thread. "Kann nicht herausfinden, wie man den Indikator malt"
Neep 13.03.06 20:56.
Nur diese Funktion ist nützlich.
1...456789101112131415161718...309
Neuer Kommentar