Ein wenig überrascht :) Ich dachte, ich teile das und stelle eine NICHT rhetorische Frage. - Seite 14

 
Renat:

Der Optimierer ist nicht gerade ein "linear skalierter Tester", sondern verfügt über eigene Optimierungsmethoden, die bei wiederholten Berechnungen in großem Maßstab effektiv funktionieren.

Wir sind gerade dabei, die Massenberechnungen zu beschleunigen. Hier ist ein Link zu den bisherigen Ergebnissen, und eine neue Version mit schnelleren Berechnungen ist fertig.

Ich stimme zu, es ist nicht gerade ein "linear skaliertes Prüfgerät". Sie führen explizite Optimierungen durch, was eine sehr gute Sache ist. Ich kann mir jedoch nicht vorstellen, wie man für einen univariaten Fall einer sehr häufigen Situation eine Optimierung vornehmen könnte:

Die Optimierung bezieht sich auf zwei Parameter, wobei ein Parameter (Bereich von 100 Werten) die Aufrufe des Indikators nicht berührt, der zweite (Bereich von 5 Werten) dagegen schon.

In diesem Fall werden Sie die Indikatorwerte 500 Mal berechnen und dabei 500 Varianten suchen. In diesem Fall werden Sie tatsächlich eine große Anzahl von Neuberechnungen durchführen. Der Grund dafür ist, dass der Bereich der zweiten Variablen nur 5 und nicht 500 beträgt.

Dies ist nur das einfachste Beispiel. Vielleicht haben Sie schon eine Idee, wie man diese lineare Skalierbarkeit des Testers für den Optimierer umgehen kann.

P.S. Es sind Beispiele wie diese, die Ihnen in Ihren eigenen Rechnern einen Geschwindigkeitsvorteil in Größenordnungen verschaffen, nicht in Prozent. Aber diese Rechner sind nicht universell, so dass der Vergleich von vornherein falsch ist.

 
Academic:

Ok - sagen wir, es gibt einen Optimierer ohne Cloud Computing, aber Multi-Threaded, und die unterstützt C++ und MT4 (und alle seine Subsystem) und ist 100 mal schneller als es, und 6 mal schneller rein durch MT5-Code, ja .... und "löst" nicht nur mit Brute Force und GA, sondern auch mit etwa 50 weiteren Varianten. Für wie viel würden Sie es kaufen? Würden Sie es für 1000 Dollar kaufen? Warum so teuer? Sie und zehn andere Personen werden die einzigen Käufer sein. :)

Wenn der Optimierer universell ist und solche Eigenschaften hat, würde ich ihn kaufen.
 
hrenfx:

Ich kann mir jedoch nicht vorstellen, wie man für einen univariaten Fall - eine sehr häufige Situation - optimieren könnte:

Ich kann mir schon etwas vorstellen (aber nicht ganz). Bevor Sie den Optimierer starten, sollten Sie eine Abhängigkeitsanalyse für die zu optimierenden Eingabeparameter durchführen (im obigen Beispiel sind zwei Variablen völlig unabhängig). Anschließend wird die Optimierung zunächst für die unabhängigen Variablen vom kleinsten bis zum größten Bereich durchgeführt (nicht immer korrekt, da dies auch von der Ressourcenintensität derselben Indikatoren abhängt). Manchmal ist es besser, den leichten Indikator 100 Mal zu zählen, als den schweren 5 Mal), wobei die Ergebnisse zwischengespeichert werden.

Es ist klar, dass die Umsetzung einer solchen Optimierung sehr komplex ist (insbesondere im Fall der Cloud). Aber wenn es implementiert wird, dann werden zumindest alle in MQL5 Wizard erstellten Expert Advisors um Größenordnungen schneller optimiert sein. Denn der MQL5-Assistent ist eine Kombination aus einer großen Anzahl von Indikatoren untereinander (d.h. es gibt eine große Anzahl von voneinander unabhängigen Eingabeparametern). Eine andere Sache ist, dass eine solche Aktivität für einen profitablen Handel nicht sinnvoll ist...

 

Das Zwischenspeichern und anschließende Abtasten der Ergebnisse bei großen (Millionen und Zehnmillionen) Stichproben ist teurer als die direkte Berechnung.

 
Renat:

Die Zwischenspeicherung mit anschließender Abtastung der Ergebnisse bei großen (Millionen und Zehnmillionen) Stichproben ist teurer als die direkte Berechnung.

Ich bin sicher, dass es fast unrealistisch ist, einen perfekten Universaloptimierer zu implementieren, der so "intelligent" ist, wie ich es oben beschrieben habe. Natürlich gibt es Raum für Verbesserungen, aber perfekt kann es auf keinen Fall sein.

Bei riesigen Stichproben (zig Millionen) übertreiben Sie natürlich erheblich. Es besteht überhaupt keine Notwendigkeit, solche Dinge zwischenzuspeichern.

Ich denke, Sie alle verstehen sehr gut, was ich meine. Und das tun viele. Niemand wird Sie dafür kritisieren, sonst wäre es die Ignoranz der Programmierer gegenüber den Kritikern. Denn diejenigen, die dafür geeignet sind, wissen sehr wohl, wie schwierig es ist, solche Dinge umzusetzen.

Lassen Sie mich die Idee der Zwischenspeicherung anhand desselben Beispiels erklären:

Wenn der Indikator nicht neu gezeichnet wird, haben Sie am Ende eines einzigen Laufs im Tester einen vollen Puffer mit allen Werten des Indikators. Sie haben es bereits. Und wenn beim nächsten Durchlauf dieselben Indikatorwerte verwendet werden (die zweite Variable hat sich nicht geändert), müssen wir sie nicht erneut lesen. Sie können Werte aus dem bereits berechneten Puffer übernehmen (der Ihnen bereits zur Verfügung steht, Sie müssen ihn nicht zwischenspeichern, da der Speicher aus dem vorherigen Lauf nicht vollständig frei ist).

 
hrenfx:

Wenn der Indikator nicht neu gezeichnet wird, dann

dies ist das "Wenn", das jede weitere Suche zunichte macht
 
Ja, gerade weil es unmöglich ist, einen so schnellen universellen Optimierer zu schreiben, werden nicht-universelle numerische Grinder immer in Bezug auf die Geschwindigkeit gewinnen. Und das ist weder gut noch schlecht.
 
hrenfx:

Ich bin sicher, dass es fast unrealistisch ist, einen perfekten Universaloptimierer zu implementieren, der so "intelligent" ist, wie ich es oben beschrieben habe. Natürlich gibt es noch viel Raum für Verbesserungen, aber perfekt kann es ohnehin nicht sein.

Bei riesigen Stichproben (im zweistelligen Millionenbereich) übertreibt man natürlich erheblich. Es besteht überhaupt keine Notwendigkeit, solche Dinge zwischenzuspeichern.

Der EURUSD-Test für die letzten 11 Jahre ergibt zum Beispiel mehr als 50 Millionen Ticks.

Das bedeutet, dass ein einfacher Ein-Puffer-Indikator wie MA 50 Millionen Zustände speichern muss (50 Millionen * 8 Bytes(double) = 400 MB Puffer), was zu viel ist. Wenn etwas Komplexeres oder eine größere Anzahl von Agenten verwendet wird, passt der Cache nicht in den Speicher, ganz zu schweigen von Multi-Core-Agenten.

Wir arbeiteten an der Idee von Indikator-Caches und es stellte sich heraus, dass es viel schneller und ressourcenschonender ist, den nächsten Indikatorwert zu berechnen (und das sogar mit einer sparsamen Methode) als Caches zu bauen.

 
hrenfx:
Ja, gerade weil es unmöglich ist, einen so schnellen universellen Optimierer zu schreiben, werden nicht-universelle numerische Grinder immer in Bezug auf die Geschwindigkeit gewinnen. Und das ist weder gut noch schlecht.

Sie gewinnen nichts.

Sie haben kein Marktumfeld, keine Infrastruktur, keine Indikatoren, keine Analysen. Und das ist wichtiger als ein einmaliger Zyklus (und nicht einmal dargestellt).

 
Renat:

Der EURUSD-Test der letzten 11 Jahre ergibt zum Beispiel mehr als 50 Millionen Ticks.

Wir sprechen hier von einem Optimierer, nicht von einer Vielzahl einzelner Testläufe. Das Konzept des Optimierers ist ganz anders. Dort werden erhebliche Geschwindigkeitsgewinne auf Kosten kleiner Fehler in den Ergebnissen erzielt. Der Optimierer braucht überhaupt keine Modelle, die auf Ticks basieren. Sie beruhen allenfalls auf den Eröffnungspreisen. Ein Optimierer ist kein Tester, er ist etwas ganz anderes. Ihr Ansatz ist anders, und auch ziemlich logisch.

Renat:

Sie werden nichts gewinnen.

Sie haben kein Marktumfeld, keine Infrastruktur, keine Indikatoren, keine Analysen. Und das ist wichtiger als ein einmaliger Zyklus (und nicht einmal vertreten).

Sie gewinnen bei der Geschwindigkeit, denn nichts kann schneller sein als der For-Zyklus allein. Manchmal ist Geschwindigkeit genau das, was man braucht, und ein Taschenrechner schlägt jeden Universaltester in puncto Geschwindigkeit (aber nicht bei anderen Parametern). Nicht nur von MetaQuotes.

Ich kann meine Behauptung aus folgendem Grund nicht beweisen:

Mein Rechner ist einfach eine C++-Implementierung meines EA, bei der alle Operationen speziell ganzzahlig sind (die Preise sind ganzzahlig), wobei unnötige Übergänge usw. vollständig auf Null reduziert werden. Es gibt dort keine Schnittstelle, nichts. Die einzige Ausgabe ist eine Datei mit den Optimierungsergebnissen. D.h. ich kann einen EA mit algorithmischer Optimierung in C++ schreiben und mein Tester wird keine Handelsprüfungen durchführen (z.B. prüfen, ob genügend Margin vorhanden ist, etc.). Es wird die Geschichte nicht nachbilden und keine Indikatoren berechnen. Es gibt nichts Universelles in Bezug auf die Vielseitigkeit des MT5-Testers. Die einzige Aufgabe des Taschenrechners ist es, schnell zu rechnen, so schnell wie möglich. Und er zählt hundertmal schneller als der MT4-Tester und produziert einen Fehler von <1%. Ich verstehe nicht, was ich hier zu zeigen versuche.

Es ist offensichtlich, dass eine for-Schleife ohne Überprüfungen und nur mit ganzen Zahlen immer schneller zählt als ein universelles Prüfgerät.

Grund der Beschwerde: