Prüfung von Echtzeit-Prognosesystemen - Seite 53

 
grasn писал(а) >>

an Yurixx

Ich schlage vor, den guten alten Fingerhut zu spielen, man kann alle Strategien anwenden und überall suchen :o) Prognose für EURUSD M15 für 300 Stichproben (von Montag bis einschließlich Mittwoch):

Option 1:

Prozess-Entropie: 13,84

Variante 2:

Prozess-Entropie: 13,01

Option 3:

Prozess-Entropie: 14,36

Welchen Fingerhut nimmst du in die Hand? :о)

Ich neige zu Option 1, da sich diese Situation seit langem entwickelt hat und nur darauf wartet, weitergeführt zu werden.

 
forte928 >> :

Ich neige zu Option 1, da sich diese Situation seit langem entwickelt hat und nur darauf wartet, weitergeführt zu werden.

D.h. durchläuft der Kurs jetzt eine Art Umkehrzone? Nur aus Neugier, wenn es nicht zu viel Mühe macht, könnten Sie das näher erläutern?

 
grasn писал(а) >>

Der Kurs durchläuft jetzt also eine Art Pivot-Zone? Nur aus Neugierde, wenn es nicht zu viel Mühe macht, bitte ich Sie, dies näher zu erläutern.

Im Moment gibt es den ersten Faktor, auf dessen Grundlage wir auf eine Seitwärtsbewegung des EUR-Dollar-Paares schließen können.

Paar hat das Niveau der Konsolidierung OP-Linie bei 1,4850 erreicht. Genau die gleichen Schwankungen wurden bei 1,3437 und 1,3937 mit einem anschließenden Rollback, die auf den Ebenen 0,382, 0,618 und 1,00 entspricht beobachtet.

in der zweiten Abbildung das gleiche Diagramm, aber mit berechneten Wachstum Ebenen im Verhältnis zu den niedrigen - 1,4162 und aktuelle 1,4951 und wenn Sie auf der Grundlage dieser Preis-Chart Ebenen 1,4951 und 1,4851 können Sie sehen, dass der Preis ist nur in der Balance Punkt auf der durchschnittlichen Höhe der Schwankungen dieser Indikatoren in den letzten zwei Tagen... Weiter, in der Tabelle nach unten Indikator hat gezeigt, eine Sättigung Ebene, auf der die Umkehr sollte auftreten.

Aber es gibt eine Reihe von Dingen, die dies nicht zulassen:

1) Das Tagesdiagramm zeigt eine negative Wachstumsbewegung (unterer Indikator)

2) Das Tagesdiagramm hat das Konsolidierungsniveau von 0,382 bei 1,4877 auf dem ersten Indikator erreicht

3) Tages-Chart erreicht Konsolidierung Ebene der COP bei 1,4892 auf den zweiten Indikator

4) Es gibt eine aktive Opposition gegen die Aufwärtsbewegung auf dem H4-Chart

5) Vorhandensein von zwei Konsolidierungsniveaus in Bezug auf das Tief von Ende September OP und 0,236 (1,4931 und 1,4933), die ein starkes Indiz für das Vorhandensein einer anhaltenden Korrektur ist

Fortsetzung folgt...

 

Grasn, darf ich dir eine Frage stellen? Haben Sie schon einmal versucht, in einer Zeitreihe nach Kipppunkten zu suchen?

Update: Ich frage, weil ich in diese Richtung gehe (und es sieht gut aus). Hier ist ein Beispiel dafür, wie meine Suche nach kritischen Punkten aussieht:


Kritische Punkte

Wie Sie sehen können, ändert sich der Charakter der Schwingungen des Indikators stark, bevor die Reihe ihr Verhalten ändert (es gibt Ausbrüche mit großer Amplitude, genauer gesagt, Maxima/Minima beginnen, sich perfekt an den Graphen der Funktion f(x)=a^x anzupassen). Die Spitzen treten etwas früher auf (in der Regel :)) als sich das Verhalten der Serie ändert. Allerdings komme ich damit noch nicht so gut zurecht. Ich muss an der Grenze der doppelten Genauigkeit arbeiten (die Zahlen sind sehr klein) und mir fehlen Richtungsvorhersagen.

 
grasn писал(а) >>

Angenommen, es gibt ein solches Konstrukt:

Wie ich verstanden habe, wird es dynamisch Array memRow[] erhöhen, wenn einige Bedingung auslöst. D.h. ich kenne die Länge des Arrays nicht im Voraus. Habe ich es richtig verstanden?

1. In MKL4 kann man nicht mit Arrays arbeiten, deren Größe nicht definiert ist. Wenn Sie die Größe beim Deklarieren des Arrays nicht angegeben haben, müssen Sie dies in init() nachholen. Außerdem können Sie die Größe während der Arbeit nach Bedarf ändern.

2. 2. die Ratschläge von Lea sind sehr praktisch, es lohnt sich, sie zu beherzigen. Damit ein Ratschlag angemessen ist, sollten Sie klar erklären, wofür das Array verwendet wird und warum Sie seine Größe ändern müssen. Es ist durchaus möglich, dass Sie sich mit der Option zufrieden geben, einfach Platz zuzuweisen und eine Variable mit dem Index des letzten Elements zu haben. Dann spielt es keine Rolle, ob Sie die Anzahl der benötigten Elemente kennen oder nicht.

.

Ich spiele nicht mit Fingerhüten. Aber ich bevorzuge Variante 2. Oder will ich nur, dass die euR wächst? :-)

Aber auch die Varianten 1 und 3 sind in Ordnung, obwohl sie sich nur wenig voneinander unterscheiden.

 
Yurixx >> :

1. In MKL4 kann man nicht mit Arrays arbeiten, deren Größe nicht festgelegt ist. Wenn Sie die Größe des Arrays nicht angeben, müssen Sie dies in init() nachholen.

1 Überhaupt nicht obligatorisch.

Wenn ein Array deklariert wird, ohne seine Größe zu definieren, wird der Prozess der Array-Vorbereitung in drei Teile geteilt:

1 Deklaration als solche - mit diesem Verfahren teilt der Programmierer dem Compiler mit, ob das Array global oder lokal ist.

2 Festlegen der Größe durch ArrayResize() - nach diesem Vorgang ist das Array tatsächlich einsatzbereit.

3 Initialisierung - wenn dies nicht angegeben wird, bleibt das Array unverändert (und speichert die Werte vergangener Starts). Wenn das Array erstellt wird, wird es automatisch auf 0 initialisiert.

 
grasn >> :

Danke, ich werde es ausprobieren, aber ich kann nicht einschätzen, was optimal wäre. Andererseits kenne ich bei einem kleinen Array auch nicht seine Dimensionalität, und außerdem muss ich bei dieser Implementierung das Array verdoppeln, zuerst das kleine und dann das große, in dem die berechneten Werte akkumuliert werden. Aber ich werde experimentieren müssen, danke für den Tipp.

Meiner Erfahrung nach empfehle ich, Arrays direkt dort zu definieren und zu verwenden, wo sie gebraucht werden, solche Arrays sind meist lokal, sie verwenden den Speicher dynamisch, was im Vergleich zu statischen Arrays besser ist, die der Wind in die Auslagerungsdatei verschieben will oder nicht, und deshalb wird ihre Arbeit um ein Vielfaches langsamer als aus dem RAM, vor allem, wenn das Array klein ist, macht es keinen Sinn statisch für sie viel Platz zu reservieren. Der MQL-4-Compiler ist so konzipiert, dass Sie den Unterschied zwischen der Deklaration eines Arrays mit einer expliziten Größe und einer verzögerten Größe nicht spüren werden.

 
Urain писал(а) >>

Meiner Erfahrung nach empfehle ich, Arrays direkt zu deklarieren und zu verwenden, wo sie solche Arrays zum größten Teil verwenden müssen, stellen sich heraus, dass diese dynamisch Speicher verwenden, der besser ist im Vergleich zu statischen Arrays, die Sie wollen oder nicht Windows legt sie in Auslagerungsdatei und daher ihre Arbeit werden viele Male langsamer als aus dem RAM, desto mehr, wenn das Array klein, dann gibt es keinen Sinn statisch für sie viel Platz zu reservieren.

Ich versteh das nicht... Warum kann ein lokales Array nicht in eine Auslagerungsdatei ausgelagert werden? Eigentlich wird es dort preempted, wenn es eine Speicherknappheit gibt; Ich bin sicher, dass sowohl lokale als auch globale Arrays in genau der gleichen Weise preempted werden. Was ist der Unterschied?

 
lea >> :

Etwas, das ich nicht verstehe... Warum kann ein lokales Array nicht in eine Auslagerungsdatei ausgelagert werden? Im Allgemeinen wird er dorthin verschoben, wenn der Speicher knapp wird; ich bin sicher, dass sowohl lokale als auch globale Daten auf die gleiche Weise verschoben werden. Was ist der Unterschied?

Statische Arrays haben alle Chancen, bei jedem Programmaufruf erstellt zu werden und durch neu erstellte Arrays beim Swap verdrängt zu werden. Wenn jedoch mehr als genug Arbeitsspeicher vorhanden ist, kann dies nicht passieren.

 
Urain >> :

1 Überhaupt nicht notwendig.

Wenn ein Array deklariert wird, ohne seine Größe zu definieren, wird der Prozess der Array-Vorbereitung in drei Teile geteilt:

1 Deklaration als solche - mit diesem Verfahren teilt der Programmierer dem Compiler mit, ob das Array global oder lokal ist.

2 Festlegen der Größe durch ArrayResize() - nach diesem Vorgang ist das Array tatsächlich einsatzbereit.

3 Initialisierung - wenn dies nicht angegeben wird, bleibt das Array so, wie es war (und speichert die Werte vergangener Starts), wenn Sie ein Array erstellen, wird es automatisch auf 0 initialisiert.

Wenn Sie die Größe in init() mit ArrayResize() festlegen, wird dieses Array in start() keine Größe haben. Sie sollten die Größe in der Funktion angeben, in der das Array verwendet wird, und dasselbe gilt für die Verwendung des Arrays in den Benutzerfunktionen. Wenn das Array als Parameter übergeben wird, sollte seine Größe nicht in der benutzerdefinierten Funktion angegeben werden, sondern in start() (oder in init(), wenn die Funktion vom Initiator aufgerufen wird), dann in der aufgerufenen Funktion. Die Ausnahme sind die Indikator-Arrays, deren Größe gleich Bars zugewiesen wird, wenn der Indikatorstatus dem Array-Namen in SetIndexBuffer() zugewiesen wird, und die sich entsprechend der Änderung von Bars ändert.

Ihre Erklärungen sind also nicht nur nutzlos, sondern auch schädlich, weil sie den Menschen die Zeit nehmen, die Wahrheit herauszufinden.

Urain, Sie führen die Menschen in die Irre. MQL-Arrays, einschließlich lokaler Arrays, haben Persistenz - ihre Größe und ihr Inhalt bleiben zwischen Funktionsaufrufen und Ticks erhalten. Bitte lesen Sie die Hilfe. Globale Arrays verhalten sich genauso, der einzige Unterschied ist, dass sie einen globalen Geltungsbereich haben. Ein Array, das in einer init-Funktion verteilt wird, ist in start und anderswo lesbar. Ich würde empfehlen, einen neuen Thread zu eröffnen, wenn jemand Fragen zu einigen Aspekten der MQL-Programmierung hat. Ich würde mir wünschen, dass hier mehr substantielle Gespräche über Prognosen geführt werden. ;-)

Wenn Sie Fragen haben, filtern Sie bitte Informationen aus diesem Forum ;-). Wenn Sie das Problem genauer beschreiben (Sie können es persönlich tun), werden wir (ich) herausfinden, wie man es besser umsetzen kann.

Grund der Beschwerde: