Diskussion zum Artikel "Algorithmen zur Optimierung mit Populationen: der Algorithmus Simulated Annealing (SA). Teil I" - Seite 2
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
Ganz genau.
Es ist eine äußerst unbequeme Technologie, sowohl für die Kodierung als auch für die weitere Verwendung in der Praxis. Das zeigt sich zum Beispiel daran, dass der hauseigene Optimierer sie nicht verwendet.
Dieser Ansatz ist kaum anwendbar, wenn mehrere Optimierungen (eine unbestimmte Anzahl von Malen und möglicherweise mit einem unbestimmten Satz von Parametern bei jedem Mal) durchgeführt werden müssen. Dies könnte zum Beispiel bei Ensemble-MO-Modellen der Fall sein.
Was kann hier gesagt werden... OpenCL ist nicht so schrecklich und nicht bequem, der Code darauf unterscheidet sich syntaktisch nicht von MQL5 (es sei denn, Sie verwenden MQL5-spezifische Funktionen). Sie können nicht nur einzelne logische Codeabschnitte parallelisieren, sondern zum Beispiel auch die gesamte Logik eines Expert Advisors in OpenCL, indem Sie Läufe durch die Geschichte in der Art eines Standard-Optimierers auf Agenten organisieren. So ist es möglich, die Optimierung/das Training im Online-Modus des Expert Advisors zu organisieren.
MetaQuotes hat Parallelisierungsfunktionen bereitgestellt, aber es wäre großartig, wenn Funktionen in der Muttersprache verfügbar würden. Ich denke, dass es für Entwickler einfacher ist, Funktionstrips zu implementieren (es ist schneller, auf die Benutzer zu warten) als automatische Parallelisierung von Codeabschnitten. Als Wunsch an die Entwickler hoffe ich, dass er erhört wird.
Was kann hier gesagt werden... OpenCL ist nicht so schrecklich und nicht bequem, der Code darin unterscheidet sich syntaktisch nicht von MQL5 (es sei denn, Sie verwenden MQL5-spezifische Funktionen). Sie können nicht nur einzelne logische Codeabschnitte parallelisieren, sondern zum Beispiel auch die gesamte Logik eines Expert Advisors in OpenCL, indem Sie die Läufe durch die Historie in der Art eines Standardoptimierers auf Agenten organisieren. Auf diese Weise können Sie die Optimierung/das Training im Online-Modus des Expert Advisors organisieren.
.
MetaQuotes hat Parallelisierungsfunktionen bereitgestellt, aber wenn es Funktionen in der Muttersprache gäbe, wäre das großartig. Ich denke, dass es für Entwickler einfacher ist, Funktionstrips zu implementieren (es ist schneller, auf die Benutzer zu warten) als automatische Parallelisierung von Codefragmenten. Als Wunsch an die Entwickler hoffe ich, dass er erhört wird.
Imho sind die Möglichkeiten so schlecht.
Es ist eine Frage zum Populationsglühen aufgetaucht. Wäre es sinnvoll, dass jede Lösung aus der Population ihre Glühparameter (innerhalb vernünftiger Grenzen zufällig) wählt? Könnte dies a) die Konvergenz verbessern und b) ein Analogon zur Auswahl optimaler Metaparameter sein?
Das Problem liegt nicht so sehr in der Kodierung selbst, obwohl sie wahrscheinlich aufgrund des Fehlens von Handbüchern sein wird. Soweit ich weiß, gibt es Probleme bei der Portierung von Programmen auf andere GPUs als die, auf der sie debuggt wurden. Auch hier bin ich mir nicht sicher, ob sich das durchsetzen wird, wenn MT5 unter Linux über Wyne läuft. Die gefundene Lösung für Probleme kann immer durch unerwartete MT-Updates usw. kaputt gehen.
OpenCL wurde gerade als universeller Weg entwickelt, um parallele Berechnungen auf Multi-Core-Geräten (egal ob GPU oder CPU) zu organisieren. Die Wahrscheinlichkeit, dass OpenCL-Programme auf verschiedenen Geräten Probleme machen, ist nicht höher (und vielleicht sogar geringer) als die von normalen Windows-Anwendungen auf Computern mit unterschiedlicher Hardware.
Ich weiß nicht, wie es sich mit vyne verhält, es gab schon immer Probleme damit, es hängt von den Besonderheiten und der Qualität der Virtualisierung der Windows-Umgebung ab.
Es ist eine Frage zum Populationsglühen aufgetaucht. Wäre es sinnvoll, dass jede Lösung aus der Population ihre Glühparameter (innerhalb vernünftiger Grenzen zufällig) wählt? Könnte dies a) die Konvergenz verbessern und b) ein Analogon zur Auswahl optimaler Metaparameter sein?
Eine gute Frage. Beim Testen von Algorithmen und bei der Auswahl der äußeren Parameter der Algorithmen gehe ich von der aggregierten Gesamtleistung bei einer Reihe von Testfunktionen aus, obwohl die besten Parameter bei jeder einzelnen Funktion unterschiedlich sein können (und in der Regel auch sind). Außerdem können unterschiedliche äußere Parameter auch für unterschiedliche Problemdimensionen die besten sein. Daher: ja:
a) verbessert die Konvergenzgenauigkeit bei verschiedenen Arten von Problemen und verringert die Wahrscheinlichkeit, dass man stecken bleibt.
b) ja
Das einzige Problem ist, dass diese Technik wahrscheinlich die Konvergenzgeschwindigkeit ein wenig (oder sehr viel, man sollte schauen) verringert (während sie die Konvergenzgenauigkeit erhöht).
Gute Frage. Beim Testen von Algorithmen und bei der Auswahl externer Parameter von Algorithmen gehe ich von der Gesamtleistung bei einer Reihe von Testfunktionen aus, obwohl die besten Parameter für jede einzelne Funktion unterschiedlich sein können (und das sind sie in der Regel). Außerdem können verschiedene externe Parameter auch für verschiedene Problemdimensionen die besten sein. Daher: Ja:
(a) verbessert die Konvergenzgenauigkeit bei verschiedenen Arten von Problemen und verringert die Wahrscheinlichkeit, dass man stecken bleibt.
b) ja
Das einzige Problem ist, dass diese Technik wahrscheinlich die Konvergenzgeschwindigkeit ein wenig (oder sehr viel, man muss nachsehen) verringert (während sie die Konvergenzgenauigkeit erhöht).