Indikatoren: Liner Regression
Ihre Version scheint die gleiche Mathematik zu sein wie:
https://www.mql5.com/de/code/429
Ich habe beide für einen Zeitraum von 20 Jahren für NZDUSD, D1, durchgeführt, und sie stimmen genau überein.
Differenzen:
- Ihre Version kodiert die Steigung farblich.
-
- Seine hat die Möglichkeit, Balken und Punkte zu "verschieben".
-
- Ihre hat die Fähigkeit, APPLIED_PRICE wechseln.
Ihre Version scheint die gleiche Mathematik zu sein wie:
https://www.mql5.com/de/code/429
Ich habe beide für einen Zeitraum von 20 Jahren auf NZDUSD, D1, ausgeführt, und sie stimmen genau überein.
Differenzen:
- Ihr Programm kodiert die Steigung farblich.
-
- Seine hat die Fähigkeit zu "verschieben" Bars und Punkte.
-
- Ihre hat die Fähigkeit, APPLIED_PRICE zu wechseln.
Dieser Weg (die 3*lwma-2*sma) wird in dem Link aus dem Beitrag erklärt (bitte überprüfen Sie diesen Link auch, dieser Link https://www.mql5.com/de/articles/270) und existiert schon lange, lange Zeit und wurde zum ersten Mal in diesem Forum vorgestellt (ehrlich gesagt erinnere ich mich nicht genau daran, wer diesen Algo zum ersten Mal vorgestellt hat, ich glaube es war "mathemat", aber bitte nehmen Sie mich nicht beim Wort)
Was den Code betrifft: der Code, den ich gepostet habe, ist ein Single-Pass-Code (deshalb ist er schnell) und hat nichts mit Nikolays Code gemeinsam, den Sie auch selbst überprüfen können. Der Zweck des Beitrags war es, einen schnellen (CPU-technisch schnellen) Weg zu zeigen, der flexibel genug ist, um in jeder Art von Code verwendet zu werden. Und nach allen Tests ist er schnell genug, um in Metatrader 5 verwendet zu werden und ist auch flexibel genug.
alles Gute
- www.mql5.com
Was den Code betrifft: Der Code, den ich gepostet habe, ist ein Single-Pass-Code (deshalb ist er schnell) und hat nichts mit Nikolays Code gemeinsam, den Sie auch selbst überprüfen können. Der Zweck des Beitrags war es, einen schnellen (CPU-technisch schnellen) Weg aufzuzeigen, der flexibel genug ist, um in jeder Art von Code verwendet zu werden. Und nach allen Tests ist es schnell genug, um in Metatrader 5 verwendet zu werden und ist auch flexibel genug
GUT. Schnell ist gut. Ich habe nicht wirklich den Code verglichen, sondern nur die Ergebnisse; daher habe ich fälschlicherweise gesagt, es sei "dieselbe Mathematik".
Ich benutze den Code von Nikolays schon seit einer Weile, und ja, es ist der langsamste Indikator, den ich habe. Schnell ist gut.
Weiter so mit der guten Arbeit!
Schöne Implementierung. Ich gratuliere.
- Was ist der Zweck von diesem ? Verschleierung? :-D
#define ¤ instance #define _functionInstances 1
- Gibt es irgendeinen Grund, >= im untenstehenden Code nicht zu verwenden ? ;-)
if(i>period)
Gute Umsetzung. Ich gratuliere.
- Was ist der Zweck von diesem ? Verschleierung? :-D
- Gibt es irgendeinen Grund, >= im untenstehenden Code nicht zu verwenden ? ;-)
Keine Verschleierung :
Von "¤" : Das gefällt mir einfach besser (eine Konvention, die ich für mich selbst verwende - für mich ist der Code so besser lesbar - ein Blick auf den Funktionscode und ich kann genau sehen, was wo verwendet wird). Ich könnte das direkt als Parametername verwenden, aber dann wäre es "zu kryptisch", wenn ich den Namen der Funktion eingebe und die automatische Ausfüllung die Parameternamen anzeigt
Von "_functionInstances": da es in eine Kompilierzeit-Direktive übersetzt wird, dient es der Planung - wenn ich mehr als eine Funktionsinstanz verwenden möchte (d.h.: verschiedene Parameter aus irgendeinem Grund), dann ändere ich einfach den Definitionswert und dann wird er in die korrekte Anzahl für die Array-Zuweisung kompiliert, um mit verschiedenen Parametern verwendet zu werden - und ich muss nicht darüber nachdenken, ob ich es an allen Stellen im Code geändert habe, wo es getan werden muss. Und da es sich um eine Compiler-Direktive handelt, entstehen keine Laufzeitkosten.
Was ">=" betrifft, gibt es zwei Gründe:
- eine Bedingung weniger (die bei jedem Funktionsaufruf ausgeführt wird), es sei denn, der Compiler übersetzt sie in etwas anderes (das ">="), aber nach den Profiler-Ergebnissen zu urteilen, verwendet er sie in diesem Fall als 2 Bedingungen und nicht als 1
- die endgültige Geschwindigkeit wird dadurch nicht beeinträchtigt und es wird sichergestellt, dass alles für die weitere Verarbeitung richtig eingestellt ist (eine zusätzliche anfängliche Summenverarbeitung stellt dies sicher)
Keine Verwirrung:
Von "¤": Das gefällt mir einfach besser (eine Konvention, die ich für mich selbst benutze - für mich ist der Code so besser lesbar - ein Blick auf den Funktionscode und ich kann genau sehen, was wo verwendet wird). Ich könnte das direkt als Parametername verwenden, aber dann wäre es "zu kryptisch", wenn ich den Namen der Funktion eingebe und die automatische Ausfüllung die Parameternamen anzeigt
Von "_functionInstances": da es in eine Kompilierzeit-Direktive übersetzt wird, dient es der Planung - wenn ich mehr als eine Funktionsinstanz verwenden möchte (d.h.: verschiedene Parameter aus irgendeinem Grund), dann ändere ich einfach den Definitionswert und dann wird er in die korrekte Anzahl für die Array-Zuweisung kompiliert, um mit verschiedenen Parametern verwendet zu werden - und ich muss nicht darüber nachdenken, ob ich es an allen Stellen im Code geändert habe, wo es getan werden muss. Und da es sich um eine Direktive zur Compilerzeit handelt, entstehen keine Kosten zur Laufzeit.
Was ">=" betrifft, gibt es zwei Gründe:
- eine Bedingung weniger (die bei jedem Funktionsaufruf ausgeführt wird), es sei denn, der Compiler übersetzt sie in etwas anderes (das ">="), aber nach den Profiler-Ergebnissen zu urteilen, verwendet er das als 2 Bedingungen und nicht als 1 in diesem Fall
- Es beeinträchtigt die endgültige Geschwindigkeit überhaupt nicht und stellt sicher, dass alles für die weitere Verarbeitung richtig eingestellt ist (eine zusätzliche anfängliche Summenverarbeitung stellt das sicher).
Natürlich funktioniert ">". Mit meiner Bemerkung wollte ich nur sagen, dass Sie "1 Schleife" verlieren, was sich natürlich nicht wesentlich auf die Endgeschwindigkeit auswirkt. "Dafür zu sorgen" scheint eher ein Aberglaube zu sein ;-)
Alain Verleyen:
You should try an OOP approach.
...
Du meinst so etwas wie das hier :)
Es ist geringfügig (aber nur geringfügig) langsamer - ich verwende den Ringpuffer-Ansatz im OOP-Modus und das fügt eine Mod-Anweisung zur gesamten Berechnung hinzu, das ist der Grund. Ich denke, dass der Beitrag auch in Ordnung ist :)
Du meinst so etwas wie das hier :)
Es ist geringfügig (aber nur geringfügig) langsamer - ich verwende den Ringpuffer-Ansatz im OOP-Modus und das fügt eine Mod-Anweisung zur gesamten Berechnung hinzu, das ist der Grund. Ich denke, dass der Beitrag auch in Ordnung ist :)
Ja, es ist immer ein Kompromiss zwischen Geschwindigkeit und Speicher.
Und natürlich ist der Hauptvorteil von OOP die Wartung und Wiederverwendbarkeit, nicht die Geschwindigkeit.
- Freie Handelsapplikationen
- Über 8.000 Signale zum Kopieren
- Wirtschaftsnachrichten für die Lage an den Finanzmärkte
Sie stimmen der Website-Richtlinie und den Nutzungsbedingungen zu.
Liner Regression:
Lineare Regression
Autor: Mladen Rakic