Wenn MetaTrader 6 morgen auf den Markt kommt - Seite 3
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
Ich möchte Optionen und MT, mit allen Deltas und Tricks.
Ich möchte, dass der Tester in zwei Teile unterteilt wird, einen schnellen Tester-Optimierer und einen genauen Tester-Debugger (er sollte auch einen Visualisierer enthalten).
Der Optimierer prüft nur die Rentabilität der Signale der Indikatoren, der Debugger prüft die Genauigkeit der Ausführung.
Es scheint notwendig zu sein, sie schon vor langer Zeit zu trennen, auch ohne den Debugger. // Die Verwendung des Testers und des Optimierers über ein und dieselbe Schaltfläche ist nervig, die Benutzerfreundlichkeit ist gering.
Was kann sie uns in der Praxis bringen?
1. die Prüfung bis zur aktuellen Minute.
Wenn es verständlich ist, den Optimierer auf diese Weise einzuschränken, warum dann nicht auch die Tests?
Ich denke, dass es jetzt an der übermäßigen Verklebung von Tester+Optimierer liegt, ich fange an, alle Arten von Schrecken aus der Serie zu sehen:
"Renat: - schlagen Sie vor, servicedesk mit Anfragen zu überschwemmen, dass die Optimierungsergebnisse nicht mit den Testergebnissen übereinstimmen?" :)))
2. die Möglichkeit, einzelne Implementierungen von Parametersätzen gründlich zu testen, ohne den Optimierungsprozess zu unterbrechen - eine sehr nützliche Funktion.
3. Schließlich, rufen Sie für die Prüfung und Optimierung direkt von Expert Advisors arbeiten in Charts (von MQL).
Das letzte von den Entwicklern genannte "Gegenargument": "Wie kann man selbstoptimierende EAs testen? Wenn der Tester und der Optimierer getrennt implementiert sind, kann eine Rekursion leicht verhindert werden, indem dem Optimierer untersagt wird, den Tester selbst aufzurufen, während der Optimierer vom Tester aufgerufen werden kann.
4,5,6.... Ich könnte noch viele weitere Argumente anführen, aber jedes von ihnen wird ausreichen.
Und seit langem gibt es auch den Wunsch, eine Walk-Forward Analyse im Tester zu machen.
Nehmen Sie zum Beispiel C#. Beim Versuch, eine Funktion oder eine Variable zu binden, wird der Compiler einen Fehler erzeugen, da Funktionen und Variablen Konzepte einer niedrigeren Ebene sind und nur innerhalb einer Klasse oder Struktur platziert werden können. Und in MQL5 scheint es eine gewisse Verwirrung zu geben - es gibt Klassen, aber es gibt auch Funktionen, die diese Klassen aufrufen, und es sollte umgekehrt sein: viele Klassen kommunizieren miteinander durch Methoden, die von ihnen unterstützt werden.
1 Grafiken. Verbesserung der Benutzerfreundlichkeit des Diagramms, grafische Objekte... Ich möchte einen Schatten für Textbeschriftungen. Und Stile mit Punkten, die mit Punkten gezeichnet werden... Und Fenster von Diagrammen, die hinter dem Terminal gezeichnet werden sollen, und Eigenschaftsfenster, die gestreckt werden sollen, und Registerkarten, die im Marktfenster gezogen werden sollen. Das ist alles.
2 Benutzerdefinierte Geschichte.
3 CCA, falls vorhanden
NS-Schulung in einem Prüfgerät durchführen.
Ich würde gerne so eine Kleinigkeit wie Mausklick- oder Tastendruckereignisse sehen, zusätzlich zu den bereits existierenden Ereignissen des Drückens.
Das ist oberflächlich. Ich brauche normale MQL-gesteuerte Fenster, Standard-Windows-Dialoge und Mittel für ihre visuelle Bearbeitung. Natürlich mit voller Handhabung aller Benutzerereignisse.
Idealerweise sollte die gesamte Schnittstelle des Terminals in mql6 implementiert werden, dann vermissen die Entwickler sicher keine so klaren Programmiererabfragen zu Schnittstellenfunktionen.