![MQL5 - Sprache von Handelsstrategien, eingebaut ins Kundenterminal MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Sie verpassen Handelsmöglichkeiten:
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Registrierung
Einloggen
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Wenn Sie kein Benutzerkonto haben, registrieren Sie sich
Es gibt eine Frage von Kollegen:
Wäre es nicht logischer, die Berechnungen ganz in die Minutengeschichte zu verlegen?! Das heißt, wir sind meist an Prognosen interessiert, die älter als M5 sind, für mich war es schon immer interessant, in 5 und 15 Minuten...
was zu tun ist - wenn Sie zu einer höheren TF wechseln, ändern Sie die Glättung (Filterung) für die winzigen Werte von Geschwindigkeit und Beschleunigung ... Da die Bildung der Balken im älteren Zeitrahmen durch OHLC erfolgt, scheint die Filterung (Glättung) beim Erhalt eines berechneten Punktes der vorherigen Balken zum Vergleich zu grob zu sein ... Bei der Durchsicht der Prognosen aller verfügbaren TFs bin ich zu dem Schluss gekommen, dass die Einstellungen einer TF nicht für die anderen geeignet sind, was meines Wissens nach an der groben Balkenstruktur liegt ... Ich denke, es ist logischer, die kleinste Einheit der Historie zu verwenden - M1-Balken und ohne auf ältere TFs (über M30) umzusteigen, die Prognosen auf der Basis von Minutenbalken zu erstellen und nur eine strengere Filterung zu verwenden.
Tatsächlich ist die Abstufung selbst M1, M5, M15 ... ist weit hergeholt ... Zumindest ist die Verzerrung der Prognosen aufgrund der Einfachheit eines solchen Filters wie BAR meiner Meinung nach offensichtlich.
Meiner Meinung nach, nen, deshalb hat er den Mehrzeitrahmen ZZ als Grundlage genommen. In seinem Beitrag :
Indikator http://www.onix-trade.net/forum/index.php?showtopic=85972&view=findpost&p=386627
Alle Charts sind 1-Minuten-Charts, d.h. die Beschleunigung wird in Minuten gezählt, aber ZZ kann von jedem höheren Zeitrahmen genommen werden.
Wenn nen es also ermöglicht, alle Situationen, die die Bedingungen erfüllen, in der Historie zu sehen, auch wenn das ZZ-Knie neu gezeichnet wurde (wenn es Bedingungen für den Bau von Fiba gab), dann wird es möglich sein, die optimale TF zur Bestimmung der Beschleunigung zu sehen und eindeutige Schlüsse über die Machbarkeit dieses Ansatzes zu ziehen. Ich persönlich zweifle nicht an der Richtigkeit der Idee, es ist nur so, dass etwas noch nicht spürbar ist, und wenn wir nicht auf Blasen und Punkte zurückgreifen, dann wird alles gut werden.
...
Ich persönlich zweifle nicht an der Richtigkeit der Idee, es ist nur so, dass etwas noch nicht spürbar ist, und wenn wir nicht in Brei und Punkte abrutschen, wird es tip-top sein.
Ich stimme zu!!! >> Ich werde mich weiter mit dem Produkt beschäftigen.
Boris, ich bitte dich immer noch, nicht aufzugeben, deinen Indikator zu verfeinern ...
Gefunden Integer's KvantLevels Indikator ... Es ist eine lustige Alternative zu den KvantLevels.
KvantLevels als Alternative zu Accelerator
Kann ich einen Link zu dem Indikator bekommen?)
http://dmffx.com/index.php?page=2&subpage=3
Version 2
minSize_0_100_fibo - Mindestabstand zwischen 0 und 100 Fibo-Ebenen in Punkten. 0 - beliebige Entfernung.
CalculationVariant - Variante der Geschwindigkeitsberechnung. 0 - die Geschwindigkeit wird zwischen den Balken berechnet, die sich in einem durch den Parameter Balken festgelegten Abstand befinden.
1 - Die Geschwindigkeit wird relativ zu dem Balken berechnet, an dem sich der Zickzack-Extremwert befindet.
Es sieht so aus, als ob der "Accelerator" separat behandelt werden muss ...
1. Warum bewirkt "CalculationVariant = 1" eine Änderung des Parameters "Bar" ...? d.h. der Wert von Bar= ... ... sollte die Berechnungen nicht beeinflussen!
2. Der "Beschleuniger" muss separat geändert werden, um die Grafik zu sehen ...
Es sieht so aus, als ob der "Accelerator" separat behandelt werden muss ...
1. Warum bewirkt "CalculationVariant = 1" eine Änderung des Parameters "Bar" ...? d.h. der Wert von Bar= ... sollte die Berechnung nicht beeinflussen!
Weil:
Nun zur Sache.
Geschwindigkeit = Entfernung / Zeit und die Berechnung von ZZ (wie du vorgeschlagen hast) ist ziemlich logisch:
Abstand = Wert(NiedrigsterZZZ oder HöchsterZZZ) - Wert(Berechneter Balken);
Zeit = NoBar(NiedrigsterZZZ oder HöchsterZZZ) - NoBar(Design Bar)
und die Beschleunigung würde bereits korrekt als :
Beschleunigung = Geschwindigkeit (geschätzter Balken) - Geschwindigkeit (geschätzter Balken+1).
Die Geschwindigkeit sollte also in Bezug auf das Zickzack-Extremum berechnet werden und die Beschleunigung in Bezug auf den angrenzenden Balken? Oder?
Also
Die Geschwindigkeit zählt relativ zum Zickzackbruch, und die Beschleunigung zählt genauso wie vorher
.Setzen Sie einfach Bar=1 für diese Variante
===========
Die Version, bei der Bar = 1 für CalculationVariant = 1 ist, ist starr eingestellt. Es gibt keine Möglichkeit zu wählen.