Was sollte zur zusätzlichen Unterstützung von universellen mathematischen Berechnungen in MQL5 und MQL5 Cloud Network hinzugefügt werden? - Seite 7
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
meinen PC im Cloud Computing zu nutzen in
MQL5 Cloud-Netzwerk. Aber hier ist das Problem, mein Konto beihttp://www.mql5.com zeigt keine Agenten an, was bedeutet, dass ich für die Nutzung meines PCs nicht belastet werde. Ich habe meinen Kontonamen im MT5MetaTrader 5 Agents Manager selbst eingegeben.
Aber hier ist das Problem in meinem Konto aufhttp://www.mql5.com werden keine Agenten angezeigt, was bedeutet, dass die Gebühr für die Nutzung meines PCs nicht tropft. Im MT5MetaTrader 5 Agents Manager selbst habe ich meinen Kontonamen eingegeben.
Daher die Frage: Welche weiteren Funktionen sollten einbezogen werden, um die Möglichkeiten des Abrechnungsnetzes zu verbessern?
Wahrscheinlich Methoden von Klassen, die aus der Ferne aufgerufen werden können und ihre Werte von Agenten erhalten: Remote Procedure Call (RPC). Etwa so:
Zusammen mit einem Methodenaufruf müssen wir natürlich auch die aktuellen Feldwerte des Objekts, das die Methode aufruft, an den Agenten weitergeben.
Die Idee ist, dass die Instanz der Hauptklasse eine Methode aufruft, und innerhalb der Methode werden Instanzen anderer Klassen erstellt, die Aufgaben an die Cloud senden. Das (die) Ergebnis(se) wird (werden) zurückgegeben.
Zum Beispiel wird eine Aufgabe in Form der Berechnung mehrerer Schachzüge erstellt. In der Hauptmethode, die aus der Ferne ausgeführt wird, werden verschiedene Kombinationen mit einer Zählung für einen Zug in Form von Objekten einer bestimmten Klasse erstellt und verschickt. Diese wiederum rufen, wenn der Zug nicht mit einem Ergebnis endete oder die Berechnungstiefe den Grenzwert nicht überschritt, erneut die gleiche Methode auf. Und so weiter und so fort.
Ohne die Beteiligung des Terminals ist dies eine gute Sache.
Wer wird die Daten für diesen "einen der Agenten" generieren? Kann ein Skript oder ein Indikator dies bewerkstelligen?
Jeder der Agenten kann Rohdaten für die anderen generieren. Kann entweder per Fordcast an alle oder an einen ausgewählten Agenten gesendet werden.
Jeder Agent kann Datenrahmen an alle anderen Agenten senden.
Was ist der Zweck der Kommunikation von Agent zu Agent, klären Sie die Unwissenden auf, wenn Sie können.
Für verwandte Aufgaben, bei denen Daten/Ergebnisse früherer Berechnungen ausgetauscht werden müssen.
Es muss nicht in der Cloud sein. Sie können ein Hochgeschwindigkeitsnetz von Agenten in Ihrem lokalen Bereich aufbauen und eine komplexe Aufgabe mit viel Datenaustausch darauf ausführen.
So können Sie ein leistungsfähiges Netz ohne Supercomputer aufbauen.
Wahrscheinlich Methoden der Klasse, die aus der Ferne aufgerufen werden können und ihre Werte von Agenten erhalten. Etwa so:
Hier müssten wir natürlich neben einem Methodenaufruf auch die aktuellen Feldwerte des Objekts, das diese Methode remote aufruft, an den Agenten übergeben.Nein, die einzige praktikable und realistische Option ist der Austausch von Datenrahmen. Die Fernausführung von Funktionen ist nicht seriös, denn niemand, der bei Verstand ist, würde die Informationsumgebung replizieren.
Im Rahmen der Rahmenarbeit kann die Funktionalität erweitert werden:
Nur für den Fall der Fälle zur Information:
Die Kosten der Netzwerklatenz sind so hoch, dass Sie zur Optimierung des Gesamtprozesses eine explizite Stapelverarbeitung der Ergebnisse vornehmen und die Daten so selten wie möglich übertragen sollten. Wenn es beispielsweise ein schnelles (innerhalb von Sekundenbruchteilen) mathematisches Problem für 100.000.000 Durchgänge gibt, ist es besser, den Prozess sofort algorithmisch in Portionen von 1.000-10.000 Durchgängen zu optimieren und einen Stapelverarbeitungscode zu schreiben, dessen Ergebnisse in einem Stapel zurückgegeben werden. Dies wäre ein enormer Vorteil gegenüber 100.000.000 Rücksendungen, bei denen sehr viel Zeit im Netz verbracht werden müsste.
Wir selbst leisten bei Hochgeschwindigkeitsaufgaben ernsthafte Hilfe, indem wir den Output in Dutzenden oder Hunderten von Durchläufen an jeden Agenten weitergeben und auch die Antworten bündeln. Dies führt zu enormen Einsparungen bei der Netzübertragung und hält die Netzlatenz auf ein Minimum.
Nein, die einzige praktikable und realistische Option ist der Austausch von Datenrahmen. Die Fernausführung von Funktionen ist nicht seriös, denn niemand, der bei Verstand ist, würde eine Informationsumgebung replizieren.
Nicht alle Aufgaben können gebündelt werden, denn bei einigen Anwendungen und sehr ressourcenintensiven Aufgaben kann das Ergebnis das einzige sein oder es wird überhaupt nicht erkannt, und sinnlose Aufgaben werden auf dem Weg verworfen, d. h. fehlende Ergebnisse sollten gar nicht erst zurückgegeben werden.
Dann gibt es noch eine andere Möglichkeit, dies zu tun. D.h. die Hauptaufgabe erzeugt ihrerseits Aufgaben und informiert die Agenten darüber. Die Agenten rufen Remote-Methoden mit Aufgaben auf, führen Berechnungen durch, und wenn sie Ergebnisse erhalten, rufen sie Remote-Methoden auf, um die Ergebnisse zurückzugeben.
Zum Beispiel die Aufgabe: Suche nach Primteilern der Fermat-Zahlen. Vielleicht gibt es gar kein Ergebnis, oder eines, oder mehrere. Der Punkt ist, dass die Suche nach diesen potenziellen Teilern eine sehr ressourcenintensive Aufgabe ist, da zunächst ein Objekt in Form einer großen Zahl erstellt werden muss (in der Aufgabe können nur zwei Zahlen als ganze Zahlen angegeben werden: Primzahl und Mantisse, um die Kosten für die Übertragung von Informationen zu reduzieren). Dann die Zahl, die auf Primzahlen überprüft werden soll (führen Sie einen vereinfachten Test durch, der zeigt, dass die Zahl in mehr als 90 Prozent keine Primzahl ist). Und dann, wenn der Einfachheitstest erfolgreich bestanden wurde, in der Schleife, Quadratur modulo nach einer Übereinstimmung suchen. Wenn die Bedingung vor dem Ende der Schleife nicht zutrifft, gibt es kein Ergebnis und nichts zurückzugeben. In diesem Fall muss der Agent den nächsten Auftrag per Fernzugriff anfordern, indem er die entsprechende Methode von der Host-Anwendung aus aufruft. Findet sie das Ergebnis, muss sie eine andere Methode aufrufen und das gleiche Ergebnis übergeben.
D.h. die Aufgaben sind unterschiedlich und die Rahmenstrukturen sind nicht für alle geeignet. Und auch die Kosten für die Netzlatenz sind im obigen Beispiel vernachlässigbar, da eine Aufgabe darin besteht, zwei ganze Zahlen an einen Agenten zu übergeben.
Nicht alle Aufgaben können gebündelt werden, da bei einigen Anwendungen und sehr ressourcenintensiven Aufgaben möglicherweise nur ein Ergebnis oder gar kein Ergebnis vorliegt, und nicht schlüssige Aufgaben werden im Laufe des Spiels verworfen, d. h. fehlende Ergebnisse müssen nicht einmal zurückgegeben werden.
Wenn Sie ein Rahmenschema verwenden, geben Sie einfach keine leeren Ergebnisse an den "Server-Agenten" zurück oder geben Sie nur das Kennzeichen "Paket berechnet, keine Daten" zurück.
Ist Ihnen bekannt, wie der Bildmodus funktioniert? Der EA-Header startet direkt im Terminalfenster und wartet auf Antworten (Datenrahmen) von entfernten Agenten. Das heißt, der Serverteil sitzt auf dem Diagramm, empfängt Daten und kann alles visualisieren.
Lesen und probieren Sie es selbst: https://www.mql5.com/ru/code/914
Wenn Sie ein Rahmenschema verwenden, geben Sie einfach keine leeren Ergebnisse an den "Server-Agenten" zurück.
Nun, das ist nur die Grundlage. Die Hauptaufgaben, die sehr rechenintensiv sind, sind rekursiv. Und die Cloud ist für solche Aufgaben nicht vorgesehen, weil sie nur für die vollständige Suche konzipiert ist. Bei vielen angewandten Aufgaben verwenden wir nicht die rohe Gewalt, da sie keine Perspektive hat. Rekursive Aufgaben sind für die Suche in der Tiefe und in der Breite und in der Tiefe mit der Breite notwendig. Zum Beispiel die Synthese von Molekülen. D.h. im Laufe des Spiels wird ein Baum von möglichen Lösungen aufgebaut, wobei jeder Zweig rechenintensiv ist. Aber nicht jeder Zweig ist effektiv. D.h. die Suche bleibt irgendwo stehen, aber gleichzeitig geht die Suche nach anderen möglichen Verzweigungen in der Tiefe oder Breite weiter.
Die vollständige Suche wird praktisch nirgends verwendet, da sie für die meisten Anwendungsaufgaben nicht genügend Zeit benötigt, um eine Lösung zu finden (z. B. Problem der Analyse von Schachzügen). Aber rekursive Methoden mit dem Abschneiden von nicht-perspektivischen Lösungszweigen ermöglichen eine hohe Geschwindigkeit, insbesondere bei verteilten Berechnungen. Wenn Sie also Anwendungsingenieure für die Cloud gewinnen wollen, sollten Sie die Cloud an ihre Aufgaben anpassen, anstatt zu denken, dass sie alles stehen und liegen lassen und alle Varianten hintereinander ausprobieren werden, unabhängig von ihren Perspektiven. Es wird für sie einfacher sein, ihr eigenes verteiltes Computernetzwerk zu schaffen, auch wenn es weniger schnell in Bezug auf die Gigaflops ist und weniger Computer hat, aber es wird effizienter sein, weil es nur in vielversprechenden Richtungen suchen und die benötigte Lösung viel schneller finden wird als das Cloud-Netzwerk. Und viele Programmiersprachen verfügen über ein Toolkit dafür, d.h. über fertige RPC-Implementierungen.
Zum Beispiel kann dieselbe Suche nach Primteiler der Fermat-Zahlen in Teilaufgaben aufgeteilt werden. Die Hauptanwendung erzeugt die Aufgaben. Die nächste Ebene erstellt Objekte und führt eine schnelle Einfachheitsprüfung für sie aus den übrigen Aufgaben durch. Auf der nächsten Ebene wird nach Bedingungen gesucht, d. h. ob ein Teiler einer Fermat-Zahl gefunden wird oder nicht. Aus den gefundenen Zahlen werden wiederum Jobs generiert. Die nächste Ebene führt eine vollständige Einfachheitsprüfung durch, und wenn die Zahl keine Primzahl ist, erzeugt sie Aufträge. Wenn es sich um eine Primzahl handelt, gibt es das Ergebnis an die Hauptanwendung zurück. Die nächste Schicht faktorisiert nicht-einfache Teiler der Fermat-Zahlen und generiert daraus Aufgaben für die vorherige Schicht.
Auf diese Weise entsteht ein Förderband, auf dem die Agenten der einzelnen Schichten ihre Aufgaben erfüllen. Es ist unklar, ob das Ergebnis gefunden werden wird. Wichtig ist, dass wissentlich aussichtslose Zahlen für die weitere Lösungssuche im Förderband aussortiert werden. Mit anderen Worten, es spart eine Menge an Rechenressourcen, anstatt Tausende von Agenten auf wenig aussichtsreiche Aufgaben zu hetzen und zu versuchen, sie abzuschleifen.
Das ist nur die Grundlage. Die Hauptaufgaben sind rekursiv und sehr ressourcenintensiv für Berechnungen. Und die Cloud ist für solche Aufgaben nicht gedacht, weil sie nur für die vollständige Suche konzipiert ist. Bei vielen angewandten Aufgaben verwenden wir nicht die rohe Gewalt, da sie keine Perspektive hat. Rekursive Aufgaben sind für die Suche in der Tiefe und in der Breite und in der Tiefe mit der Breite notwendig. Zum Beispiel die Synthese von Molekülen. D.h. im Laufe des Spiels wird ein Baum von möglichen Lösungen aufgebaut, wobei jeder Zweig rechenintensiv ist. Aber nicht jeder Zweig ist effektiv. D.h. irgendwo hört die Suche auf, aber gleichzeitig geht die Suche nach anderen möglichen Verzweigungen in der Tiefe oder Breite weiter.
Stapelberechnungen in 1.000-10.000 Durchläufen und Rückgabe nur der wichtigsten Ergebnisse. Dies ist eine sehr effektive algorithmische Technik.
Darüber habe ich weiter oben ausführlich geschrieben.
Die vollständige Suche wird fast nie verwendet, da sie für die meisten angewandten Probleme nicht genügend Zeit benötigt, um eine Lösung zu finden (z. B. ein Schachspielzug-Analyseproblem). Aber rekursive Methoden mit dem Abschneiden von nicht-perspektivischen Lösungszweigen bieten eine hohe Geschwindigkeit, insbesondere bei verteilten Berechnungen. Wenn Sie also Anwendungsingenieure für die Cloud gewinnen wollen, sollten Sie die Cloud an ihre Aufgaben anpassen, anstatt zu denken, dass sie alles stehen und liegen lassen und alle Varianten hintereinander ausprobieren werden, unabhängig von ihren Perspektiven. Es wird für sie einfacher sein, ihr eigenes verteiltes Computernetzwerk zu schaffen, auch wenn es weniger schnell in Bezug auf Gigaflops ist und weniger Computer hat, aber es wird effizienter sein, weil es nur in vielversprechenden Richtungen sucht und die benötigte Lösung viel schneller findet als das Cloud-Netzwerk. Und viele Programmiersprachen haben dafür ein Toolkit, d.h. fertige Implementierungen von RPC.
Zum Beispiel kann dieselbe Suche nach Primteiler der Fermat-Zahlen in Teilaufgaben aufgeteilt werden. Die Hauptanwendung erzeugt die Aufgaben. Die nächste Ebene erstellt Objekte und führt eine schnelle Einfachheitsprüfung für sie aus den übrigen Aufgaben durch. Auf der nächsten Ebene wird nach Bedingungen gesucht, d. h. ob ein Teiler einer Fermat-Zahl gefunden wird oder nicht. Aus den gefundenen Zahlen werden wieder Aufgaben gebildet. Die nächste Ebene führt eine vollständige Einfachheitsprüfung durch, und wenn die Zahl keine Primzahl ist, erzeugt sie Aufträge. Wenn es sich um eine Primzahl handelt, gibt es das Ergebnis an die Hauptanwendung zurück. Die nächste Schicht faktorisiert nicht primäre Teiler von Fermat-Zahlen und erzeugt Aufträge für die vorherige Schicht.
Lesen Sie oben über den Datenaustausch und das Demo-Beispiel:
Es wird eine weitere Erweiterung des Datenaustauschs vorgeschlagen, so dass der Hauptprozess zusätzlich alle zusätzlichen benutzerdefinierten Daten an jeden Agenten weitergeben kann. Dadurch ist es möglich, in Teilen zu lesen und neue benutzerdefinierte Bedingungen an Remote-Agenten zu verteilen. Daher kann es nach Belieben lesen und die Bedingungen jedes Mal ändern.
Eine weitere mögliche Erweiterung besteht darin, dass Agenten nicht nur Aufgaben vom Master erhalten, sondern auch Daten untereinander austauschen können. Sie können dies natürlich über den Assistenten tun (was bei großen Datenmengen sehr langsam sein kann), aber es ist noch effizienter und schneller, dies direkt über Cloud-Server zu tun.
Renat:
Eine weitere mögliche Erweiterung besteht darin, dass Agenten nicht nur Aufgaben vom Assistenten erhalten, sondern auch Daten untereinander übertragen können. Sie können dies natürlich auch über den Assistenten tun (was bei großen Datenmengen sehr langsam sein kann), aber noch effizienter und schneller ist es, dies direkt über die Cloud-Server zu tun.
Das ist es, was benötigt wird, d.h. eine rekursive Datenübertragung von einem Agenten zu einem anderen ohne Assistenten, aber mit garantierter Rückgabe der Ergebnisse an den Master. So konnte der Agent nicht eine Aufgabe übernehmen und die Arbeit einstellen, ohne sie zu Ende zu führen, weil z. B. der Computer heruntergefahren und ein möglicherweise wirksamer Lösungszweig unterbrochen war.
Also zum Beispiel die Aufgabe, eine Schachpartie zu analysieren. Der Assistent ordnet die Steine an und generiert Zuordnungen für die Farbe der Steine, die jetzt bewegt werden sollen, d.h. ein Stein - eine Zuordnung. Jeder Agent, der eine Aufgabe für seine Figur erhalten hat, verwirft die wenig aussichtsreichen Varianten zur weiteren Analyse, wenn eine Figur nicht ziehen kann, und bildet neue Formationen, die als Aufgaben für die gegnerischen Figuren weitergegeben werden. Und so weiter und so fort, bis das Matt oder die Pattsituation oder die Suchtiefe überschritten ist.
Wenn eine solche Aufgabe der aktuellen Cloud-Implementierung anvertraut wird, können Sie nur Aufgabenpakete für die vollständige Suche erstellen. Und die Cloud hat nicht genug Agenten dafür, und es ist unwahrscheinlich, dass der Assistent genug Speicher hat, um all diese Aufträge zu verarbeiten. Denn es gibt keinen Mechanismus zur Aussonderung unvorteilhafter Varianten. Denn mit jedem neuen analysierten Zug von Spielsteinen wächst die Zahl der Aufgaben exponentiell an, aber auch ein beträchtlicher Teil davon wird verworfen und erzeugt keine sinnlosen Aufgaben, wie im völligen Overkill. Und das kann man nur herausfinden, wenn man in eine gewisse Tiefe oder Breite des Entscheidungsbaums eintaucht. Und die Tiefe in dieser Cloud-Implementierung ist 1, d. h. vom Master zum Agenten und wieder zurück.
Mein Standpunkt ist folgender. Für den Handel ist auch die Implementierung einer rekursiven Suche mit Abschneiden von Sackgassen erforderlich. Es ist besser, nicht nur nach einem einzigen Extremum zu suchen, sondern nach einer Reihe von lokalen Extremen (von denen es tatsächlich viele gibt). Und der Suchraum für alle möglichen Varianten ist astronomisch, d.h. kein Agent aus allen verteilten Rechnernetzen wird ausreichen. Zu diesem Zweck werden in jedem Schritt die nächstgelegenen Nachbarschaften eines Punktes (Punktkoordinaten - Eingabeparameter des EA) in einem bestimmten Abstand und mit einem bestimmten Winkelwert aufgezählt, um zu sehen, ob sie die Ergebnisse im Vergleich zum aktuellen Punkt verbessern oder nicht. Wenn eine von ihnen schlechter ist oder die Suchtiefe überschreitet, verwerfen wir sie. Wenn sie sich verbessern, schauen wir rekursiv weiter und bilden aus den verbesserten Punkten eine Menge weiterer Aufgaben, die wir an die Agenten verteilen. Wenn ein lokales Extremum gefunden wird (alle Punkte in der Nachbarschaft verschlechtern das aktuelle Ergebnis nur), geben wir das Ergebnis an die Hauptanwendung zurück. Sobald die Extrema identifiziert sind, werden sie an den Assistenten übergeben und mit Hilfe von Vorwärtstests weiteranalysiert.
Eine solche Aufgabe kann nicht direkt gelöst werden, da die Anzahl der Varianten astronomisch ist. Ein genetischer Algorithmus sucht auch nicht nach lokalen Extremen (er hält auch in der unmittelbaren Nachbarschaft des globalen Extrems an) und zeigt nur Zwischenergebnisse an, unabhängig von deren Extremwert. Das bedeutet nicht, dass der Suchraum von genetischen Algorithmen und Brute-Force-Algorithmen begrenzt und diskret ist. Es ist die Suche nach der maximalen Anzahl von lokalen Extrema, aber schnell, d.h. mit dem Abschneiden von nicht-perspektivischen Generationen von Aufgaben von Master zu Agenten und von Agenten zu anderen Agenten und unbegrenzter Reichweite (aber so, dass Einschränkungen gesetzt werden können, wenn nötig, z.B. ist die Suchtiefe in solchen Algorithmen immer begrenzt). Wenn die Cloud eine rekursive Auftragsübertragung implementieren würde, wäre das Problem gelöst.