Optimierung mit dem Strategy Tester - Seite 8
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
Der Testlauf des obigen Beispiels hat einen System-Overhead von etwa 1,5 Sekunden beim Start, um alle Daten vorzubereiten (Autorisierung und Synchronisierung der Berechnungsdaten). Der Punkt ist, dass die Testagenten völlig unabhängig und vom Terminal entkoppelt sind, was dazu führt, dass alle verwendeten Daten vollständig übertragen und synchronisiert werden müssen.
Wir können nicht sagen, dass der genetische Optimierer oder Tester bei superschnellen Berechnungen innerhalb weniger Sekunden langsam ist, da der System-Overhead einen erheblichen Einfluss auf die endgültige Berechnungszeit hat. Bei langen Berechnungen von 20 Sekunden oder mehr pro Lauf werden die Auswirkungen des System-Overheads auf vernachlässigbare Werte reduziert.
Mit jedem Build reduzieren wir diese Zeit, indem wir die meisten Daten direkt in den Agenten zwischenspeichern. Ich denke, wir werden dieses Problem bald lösen.
GA von joo ist bereits schneller als der Standard, und wenn man den Code mit Studio 10 (angepasst an Multi-Core-CPUs) nach CPP überträgt, ist die Beschleunigung noch einmal 6 Mal schneller.
Es gibt kein Marktumfeld, in dem man einen individuellen Geschwindigkeitsrechner für eine bestimmte Aufgabe zusammenstellen kann.
Wenn Sie jedoch versuchen, eine universelle Handelsmaschine mit On-Demand-Bereitstellung beliebiger Multiwährungs-Poti-Daten mit automatischer Berechnung von Gewinnen/Limits und Berichten zu entwickeln, wird die Geschwindigkeit sofort um 2-3-4 Größenordnungen sinken.
Die Durchführung von Tests mit dem obigen Beispiel hat einen System-Overhead von etwa 1,5 Sekunden beim Start, um alle Daten vorzubereiten (Autorisierung und Synchronisierung der Berechnungsdaten). Der Punkt ist, dass die Testagenten völlig unabhängig und vom Terminal entkoppelt sind, was dazu führt, dass alle verwendeten Daten vollständig übertragen und synchronisiert werden müssen.
Wir können nicht sagen, dass der genetische Optimierer oder Tester bei superschnellen Berechnungen innerhalb weniger Sekunden langsam ist, da der System-Overhead einen erheblichen Einfluss auf die endgültige Berechnungszeit hat. Bei langen Berechnungen von 20 Sekunden oder mehr pro Lauf werden die Auswirkungen des System-Overheads auf vernachlässigbare Werte reduziert.
Mit jedem Build reduzieren wir diese Zeit, indem wir die meisten Daten direkt in den Agenten zwischenspeichern. Ich denke, wir werden dieses Problem bald lösen.
Ohne ein Marktumfeld ist es möglich, einen benutzerdefinierten Schnellzähler für eine bestimmte Aufgabe einzurichten.
Wenn man jedoch versucht, eine universelle Handelsmaschine mit On-Demand-Bereitstellung beliebiger Mehrwährungsdaten mit automatischer Gewinn-/Limitberechnung und Berichterstattung zu entwickeln, sinkt die Geschwindigkeit sofort um 2-3-4 Größenordnungen.
Renat, ich meine nicht, dass es Zeit braucht, um das Marktumfeld und andere unvermeidliche "Bremsen" vorzubereiten, wie ich auf der vorherigen Seite schrieb:
Höchstwahrscheinlich ist eine solche monströse Unterschied aufgrund der Tatsache, dass der Tester, zusätzlich zu den direkten Berechnungen FF, müssen Protokolle, Display-Informationen, etc. zu schreiben, dass vorhanden ist "erzwungene Bremsen"
2010.11.28 17:38:30 Kern 1 genetischer Durchlauf (424, 98130899813578) lieferte Ergebnis 48.16 in 2059 ms
2010.11.28 17:38:30 Core 2 genetischer Durchlauf (426, 990006720) gestartet
2010.11.28 17:38:30 Kern 2 genetischer Durchlauf (425, 56291461) lieferte Ergebnis 26,67 in 2012 ms
2010.11.28 17:38:28 Kern 2 genetischer Durchlauf (425, 56291461) gestartet
2010.11.28 17:38:28 Kern 2 genetischer Durchlauf (423, 1510001908) liefert Ergebnis 49.98 in 2028 ms
2010.11.28 17:38:28 core 1 genetischer Durchlauf (424, 98130899813578) gestartet
2010.11.28 17:38:28 Kern 1 genetischer Durchlauf (422, 1668020166802) lieferte Ergebnis 48,36 in 2013 ms
2010.11.28 17:38:26 Kern 2 genetischer Durchlauf (423, 1510001908) gestartet
2010.11.28 17:38:26 Kern 2 genetischer Durchlauf (419, 99260769921339) lieferte Ergebnis 49.22 in 1935 ms
2010.11.28 17:38:26 Kern 1 genetischer Durchlauf (422, 1668020166802) gestartet
2010.11.28 17:38:26 Kern 1 genetischer Durchlauf (418, 32073563420604) lieferte Ergebnis 26.13 in 1934 ms
2010.11.28 17:38:24 Tester genetischer Pass (421, 730000073) gefunden im Cache mit Ergebnis 50.00
2010.11.28 17:38:24 Tester genetischer Pass (420, 2080000208) gefunden im Cache mit Ergebnis 50.00
2010.11.28 17:38:24 Kern 2 genetischer Durchlauf (419, 99260769921339) gestartet
2010.11.28 17:38:24 2010/11/28 17:38:24 Core 2 genetic pass (417, 99249619924961) liefert Ergebnis 49.26 in 2059 ms
2010.11.28 17:38:24 core 1 genetischer Durchlauf (418, 32073563420604) gestartet
2010.11.28 17:38:24 Kern 1 genetischer Durchlauf (416, 2479846771) lieferte Ergebnis 48.49 in 2309 ms
2010.11.28 17:38:22 Kern 2 genetischer Durchlauf (417, 99249619924961) gestartet
Das heißt, es dauert mehr als 2 Sekunden, um den nackten FF zu berechnen, und das, obwohl es überhaupt keinen Bezug zum Marktumfeld gibt.
Der Optimierer löst eine so einfache Aufgabe wie f(x1,x2)=x1*x1+x2*x2 irgendwo beim 500sten "Durchlauf" und probiert immer wieder Varianten aus, da er mehr als 1000 zu berechnende Varianten definiert hat.
Und es gibt keine Einstellungen, die die Suchmöglichkeiten des Algorithmus beeinflussen, außerdem ist die Begrenzung auf 64 optimierbare Parameter frustrierend.
Es ist möglich, einen benutzerdefinierten Geschwindigkeitsrechner für eine bestimmte Aufgabe ohne Marktumfeld einzurichten.
Wenn man jedoch versucht, eine universelle Handelsmaschine zu entwickeln, die bei Bedarf beliebige Mehrwährungsdaten mit automatischer Berechnung von Gewinnen/Limits und Berichten bereitstellt, sinkt die Geschwindigkeit sofort um 2-3-4 Größenordnungen.
Ich werde nicht streiten, aber es wäre gut, die Kontrollparameter des Algorithmus, die gleichen Einstellungen für den Suchausgang und die Anzahl der Suchparameter zu erweitern.
Wir hier bei mql5 arbeiten an Algorithmen für die Suche nach 3000 Parametern, und das ist nicht die Grenze, natürlich nicht in binärer Kodierung, sondern in kontinuierlicher Ebene.
Und Sie haben immer noch eine SRR in den Händen.
Ich habe versucht, es in binärer Codierung zu tun, aber GA verliert in einem solchen Fall auf mql5. Die kontinuierliche Suche ist gut, weil sie selbst die Konvergenzschritte reduziert. Außerdem brauchen wir keine Ressourcen für die Codierung/Decodierung. Nun, im Allgemeinen brauchen wir korrekte Tests, es ist zu früh, um etwas mit Sicherheit zu sagen.
Der genetische Optimierer wird wahrscheinlich besser anpassbar sein und wir werden den System-Overhead minimieren.
Ich danke Ihnen vielmals. Dies ist tatsächlich sehr wichtig, wichtiger als viele denken.
Und hoffentlich werden wir auch "Threshold 64" irgendwann vergessen.
In der neuen 366er-Version (die am Montag erscheint) haben wir den System-Overhead auf ein Minimum reduziert.
Der obige Genetikexperte benötigt nun zwischen 200 und 300 ms statt 2 Sekunden pro Durchgang.
Ich danke Ihnen vielmals. Sie ist wirklich sehr wichtig, wichtiger als viele denken.
Und hoffentlich vergessen wir auch irgendwann Threshold 64.
Vergessen Sie es gleich, bei 4 Parametern auf 8 Stellen gibt das Prüfgerät eine Warnung, dass die Übergröße die Länge überschritten hat.
Wenn Sie also andere Bedürfnisse als das Testen von EAs haben, schreiben Sie einen eigenen Optimierer.
Und 64 Parameter sind für die Optimierung von EAs völlig ausreichend.
Ja, ich habe den Thread gelesen, woher bekommen sie Berater mit so vielen Parametern:)
Ja, ich habe den Thread gelesen, woher bekommen sie Berater mit so vielen Parametern:)