![MQL5 - Langage des stratégies de trading intégré au terminal client MetaTrader 5](https://c.mql5.com/i/registerlandings/logo-2.png)
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Je veux les options d'un MT, avec tous les deltas et les artifices.
J'aimerais que le testeur soit divisé en deux parties, un testeur-optimiseur rapide et un testeur-débogueur précis (il devrait également inclure un visualiseur).
L'optimiseur vérifie uniquement la rentabilité des signaux des indicateurs, le débogueur vérifie la précision de l'exécution.
Il semble nécessaire de les séparer depuis longtemps, même sans le débogueur. // L'utilisation du testeur et de l'optimiseur à partir d'un seul et même bouton est un casse-tête, la convivialité est faible.
Que peut-elle nous apporter en pratique ?
1. des tests jusqu'à la minute en cours.
S'il est compréhensible de limiter l'optimiseur de cette manière, alors pourquoi limiter les tests ?
Je pense que maintenant c'est dû au collage excessif de testeur+optimiseur, je commence à voir toutes sortes d'horreurs de la série :
"Renat : - vous suggérez d'inonder servicedesk de demandes que les résultats de l'optimisation ne coïncident pas avec les résultats des tests?". :)))
2. la possibilité de tester en profondeur des implémentations individuelles de jeux de paramètres sans interrompre le processus d'optimisation - une fonction très utile.
3. Enfin, appelez les tests et l'optimisation directement à partir des conseillers experts travaillant dans les graphiques (à partir de MQL).
Le dernier argument "contre" mentionné par les développeurs : "Comment tester les EA auto-optimisantes ? Lorsque le testeur et l'optimiseur sont implémentés séparément, la récursion est facilement évitée en interdisant à l'optimiseur d'appeler le testeur lui-même, tout en permettant à l'optimiseur d'être appelé par le testeur.
4,5,6.... Je peux donner beaucoup d'autres arguments, mais n'importe lequel d'entre eux suffira.
Et aussi depuis longtemps il y a une demande pour faire l'analyse Walk-Forward dans le testeur.
Prenez le C#, par exemple. Lorsque vous essayez de lier une fonction ou une variable, le compilateur génère une erreur, car la fonction ou la variable sont des concepts de niveau inférieur et ne peuvent être placées qu'à l'intérieur d'une classe ou d'une structure. Et dans MQL5, il semble y avoir une certaine confusion - il y a des classes, mais aussi des fonctions qui appellent ces classes, et ce devrait être l'inverse : beaucoup de classes communiquent entre elles par le biais de méthodes qu'elles supportent.
1 Graphique. Améliorer la convivialité du tableau, des objets graphiques... Je veux une ombre pour les étiquettes de texte. Et des styles avec des points à dessiner avec des points... Et des fenêtres de graphiques à dessiner derrière le terminal, et une fenêtre de propriétés à étirer, et des onglets à faire glisser dans la fenêtre du marché. C'est tout.
2 Historique personnalisé.
3 CCA, Si fait
Pour faire la formation NS dans un testeur.
J'aimerais voir une petite chose comme des événements de clic de souris ou de pression de touche, en plus des événements de pression déjà existants.
C'est superficiel. J'ai besoin de fenêtres normales pilotées par MQL, de boîtes de dialogue standard de Windows et de moyens de les modifier visuellement. Naturellement, avec une gestion complète de tous les événements utilisateur.
L'idéal serait que toute l'interface du terminal soit implémentée en mql6, ce qui permettrait aux développeurs de ne pas manquer les requêtes claires des programmeurs sur les fonctions de l'interface.