Tester zur Unterstützung von MG4-Skripten und Beratern - Seite 10
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
Das habe ich nicht gesagt.
Ich habe mich mit diesem Thema überhaupt nicht befasst und habe auch nicht vor, mich damit zu befassen.
Offensichtlich, so schien es mir:
Und die integrierten Stoplots und Takeprofits sind eigentlich virtuell und werden zum richtigen Zeitpunkt zur Ausführung auf den Markt geworfen. Diese Lösung hat eine gute Seite - sie spart an CS (Sicherheiten, Marge).
Überlegen Sie, was die neuen Datenzugriffsfunktionen bieten und warum dies der Fall ist.
MetaTrader 4 verfügt über eine begrenzte Tiefe der Historie, separate Zeitrahmen und direkten Zugriff auf die Balken seines Symbols über Open/High/Low/Close/Time[xxx]. Ein solcher Direktzugriff ist in Bezug auf Ressourcen und CPU-Kosten sehr kostspielig zu implementieren. Beachten Sie, dass jeder Expert Advisor seine eigene lokale Kopie dieser Daten hat, um Konflikte mit anderen Expert Advisors und dem Terminal selbst zu vermeiden.
Wenn die Anzahl der Symbole wächst (z.B. in MT5 können Sie 5.000-10.000 Symbole haben) und die tiefe 1-Minuten-Historie als Basis für alle Zeitrahmen verwendet wird, ist es im Prinzip nicht mehr möglich, die Methoden von MT4 zu verwenden. Der Arbeitsspeicher reicht nicht aus, und das Kopieren großer Datenmengen beeinträchtigt die Leistung. Aus diesem Grund unterhält MT5 nicht mehr automatisch eine versteckte und teure Kopie des Charts für jeden Experten.
Stattdessen sind wir zu sehr sparsamen CopyXXX-Funktionen übergegangen, bei denen der Entwickler genau so viele Daten in das lokale Array anfordert, wie er benötigt, und nicht das gesamte verfügbare Diagramm. Als nächstes kommt die schnellstmögliche lokale Datenverarbeitung (anstelle des alten, recht teuren Open/High/Low/Close/Time[xxx]), und der Autor kann diese Daten zwischenspeichern und beim nächsten Aufruf sparsam verwenden. Die Einsparungen bei Speicher und CPU sind enorm. Darüber hinaus ist die Plattform selbst besonders frei in der Verwaltung umfangreicher Datenbanken - der Zugriff auf sie erfolgt immer auf Anfrage (im Gegensatz zum unkontrollierten Direktzugriff), was eine flexible Verwaltung der Caches ermöglicht.
Es sollte auch beachtet werden, dass die Einfachheit der Open/High/Low/Close/Time[xxx]-Aufrufe in MQL4 auf das aktuelle Symbol und den aktuellen Zeitrahmen beschränkt war und alle anderen Daten für andere Symbole und Zeitrahmen mit Hilfe von iClose/iLow(...)-Funktionen erhalten wurden, was zu erheblichen Verzögerungen führte. Der Übergang in MQL5 zu einem einzigen CopyXXX-Funktionsmodell hat die Situation radikal verbessert und ermöglicht es den Entwicklern, die benötigten Datenpakete mit einer einzigen Anfrage zu erhalten und nicht mehrere blockierte Aufrufe zu tätigen (man denke nur an all die Blockierungen bei jedem einzelnen Aufruf von iClose).
...
Wie sieht es mit der Leistung von CopyXXX aus?
Was die Einsparung von Speicherplatz angeht - keine Frage. Es ist jedoch teurer, CopyXXX für jeden Tick aufzurufen, als ein Array von Kursen einmal in einen Puffer zu kopieren und über einen direkten Index vom Typ Rates[X] darauf zuzugreifen. Hier haben wir ein klassisches Programmierdilemma: "Speicher sparen vs. CPU-Zeit sparen".
Nicht weniger als ein MT5. Stellen Sie sich nun die gleiche Frage, nur dass Sie ein B durch ein A ersetzen.
Lernen Sie, was der MARKT ist! Händler, die Sie kennen....
Sie meinen also, dass MT4 z.B. die Spread-Historie speichern kann oder über reale Volumina "Bescheid weiß" (ohne alle Krücken und andere völlig unzureichende Lösungen)?
Sind Sie auch der Meinung, dass der Spread auf dem realen Markt eindeutig nicht fix ist? Gehen Sie und in der MT4-Tester versuchen, die EA auf Kurse mit wechselnden Spreads zu testen, dann werden wir reden.
Ich kümmere mich weniger um den Rest der Welt als um die Interessen der Entwicklung von Experten mit komplexer Logik. ;)
Die Kompromisslösung wäre, virtuelle Aufträge auf der MT5-Ebene zu organisieren. Dann gäbe es sowohl das Netting, das jemand braucht, als auch die alte Logik des Arbeitens mit Aufträgen.
Sind Sie bereit, das Risiko einer solchen "Visualisierung" einzugehen?
Im MT5 hat jeder, der wollte, schon lange die Lösung genutzt, indem er mit Trades auf verschiedenen Instrumenten mit einem hohen Korrelationsgrad abgesichert hat.
Ja, dies kann eine viel größere Marge als in MT4 erfordern, aber der gesunde Menschenverstand sagt, dass es richtig ist.
Natürlich hat in diesem Fall niemand die "virtuelle" Regelung aufgehoben.
Wollen Sie damit sagen, dass MT4 z.B. die Spread-Historie speichern kann oder über reale Volumina "Bescheid weiß" (ohne alle Krücken und andere unzureichende Lösungen)?
Sind Sie auch der Meinung, dass der Spread auf dem realen Markt eindeutig nicht fix ist? Gehen Sie und in der MT4-Tester versuchen, die EA auf Kurse mit wechselnden Spreads zu testen, dann werden wir reden.
Sie werden die Risiken einer solchen "Visualisierung" auf sich nehmen?
Im MT5 nutzt jeder, der wollte, eine Hedging-Lösung, indem er Trades in verschiedenen Instrumenten mit einem hohen Korrelationsgrad einsetzt.
Gott sei Dank gibt es jetzt MT4. :) Sie können es auf einem Instrument verwenden, wenn Sie möchten. Sie können verschiedene Instrumente verwenden.
Worin bestehen Ihrer Meinung nach die Risiken?
Wie sieht es mit der Leistung von CopyXXX aus?
In Bezug auf den Speicherplatz - keine Frage. Es ist jedoch teurer, CopyXXX für jeden Tick aufzurufen, als ein Array von Kursen einmal in einen Puffer zu kopieren und über einen direkten Index vom Typ Rates[X] darauf zuzugreifen. Hier haben wir ein klassisches Programmierdilemma: "Speicher sparen vs. CPU-Zeit sparen".
CopyXXX hat die gleiche Geschwindigkeit wie die Funktionen iClose/iOpen/iXXXX. Nur iXXX gibt jeweils ein Element zurück, während CopyXXX viele Elemente zurückgibt und somit effizienter und schneller ist.
Wahrscheinlich bedenken Sie nicht, dass MT4 vor jedem Tick-Handler-Start zwangsweise _alle_ Historien des lokalen Charts in die lokale (Cache-) Marktumgebung des EA kopiert. Und das ist sehr teuer, obwohl wir eine Methode zur wirtschaftlichen Aktualisierung dieser Informationen haben. Die spezielle Funktion RefreshRates in MQL4 bewirkt eine erzwungene Auffrischung der Caches und der Historie des lokalen Diagramms.
Der Aufruf von CopyXXX ist viel effizienter, und die Entwickler verfügen über einen sehr genauen und präzisen Mechanismus zur Zwischenspeicherung zuvor angeforderter Daten. Sie müssen z. B. nicht bei jedem Tick die Deep History erneut abfragen, sondern können sie lokal speichern/schreiben und so schnell wie möglich darauf zugreifen.
Wenn wir die alten Methoden des "direkten" (nicht wirklich direkten) Zugriffs Open/High/Low/Close und die Arbeit mit dem lokalen Array double local[xxxx] vergleichen, ist letztere um ein Vielfaches schneller. Daher ist es besser, sich selbst lokal zu kopieren und dann einen schnellen lokalen Zugriff auf wiederholt abgefragte Daten zu haben.
Zum Glück gibt es jetzt einen MT4. :) Damit können Sie jeweils ein Instrument verwenden. Sie können verschiedene Instrumente verwenden.
Worin bestehen Ihrer Meinung nach die Risiken?
Bei der Entwicklung/Benutzung von "Handelsplattformen" entstehen gewisse Kosten und Risiken, die letztendlich jemand auf sich nimmt.
Was die "Virtualisierung" in Software von anderen Entwicklern betrifft
Das ist eine gute Sache, solange alles für sich selbst genutzt wird und die Leute, die die Lösung implementieren, verstehen, was sie tun.
Die Hauptkosten sind: die Kosten für die Entwicklung des Systems, die Kosten für die Aufrechterhaltung des Betriebs und der Zeitaufwand für die Durchführung des Projekts.
Die Hauptrisiken: Es wird zu viel Zeit oder Geld für die Umsetzung eines tragfähigen Projekts aufgewendet (das Projekt wird sich nicht auszahlen), das Projekt wird im Vergleich zu anderen Lösungen nicht effektiv sein, versteckte Fehler im Code oder in den Algorithmen werden während der Projektumsetzung eingeführt.
Ja, Banken und andere Marktteilnehmer entwickeln ihre eigene Software mit den erforderlichen Funktionen, aber sie wenden dafür sehr viel Zeit und Ressourcen auf. In der Zwischenzeit tragen sie absolut alle Risiken.
Bezüglich der Arbeit mit MT5 (verschiedene Varianten mit MT5)
Hier hat MQ natürlich den größten Teil der Arbeit übernommen, aber auch gewisse Einschränkungen der Funktionalität eingeführt.
Die Hauptkosten sind: die Kosten für die Aufrechterhaltung der Leistung des Systems und die für das Projekt aufgewendete Zeit.
Die Hauptrisiken: Das Projekt wird im Vergleich zu anderen Lösungen nicht effizient sein, bei der Umsetzung des Projekts werden versteckte Fehler im Code oder in den Algorithmen auftreten, Sie müssen die Leistung des gesamten Systems ständig überwachen (Schutz vor Software- und Hardware-Problemen, Überwachung der Kommunikationsqualität, Stromversorgung, Datensicherheit usw.).
Man kann natürlich auch an eine kommerzielle Anwendung denken (die es anderen erlaubt, sie zu nutzen), allerdings mit gewissen Einschränkungen und Vorbehalten.Ich würde gerne einen Blick auf
Hier ist ein Beispiel, bei dem die Einfachheit und Benutzerfreundlichkeit von OOP beim Schreiben einfacher Programme besonders deutlich wird.