Discussion de l'article "La Programmation Basée sur des Automates comme Nouvelle Approche pour créer des Systèmes de Trading Automatisés"
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
Un nouvel article La Programmation Basée sur des Automates comme Nouvelle Approche pour créer des Systèmes de Trading Automatisés a été publié :
Cet article nous emmène dans une toute nouvelle direction dans l’élaboration d' EA, d'indicateurs et de scripts en MQL4 et MQL5. À l'avenir, ce paradigme de programmation deviendra progressivement la norme de base pour tous les traders dans l’implémentation des EA. En utilisant le paradigme de programmation basé sur les automates, les développeurs MQL5 et MetaTrader 5 seront tout près de pouvoir créer un nouveau langage - MQL6 - et une nouvelle plate-forme - MetaTrader 6.
Un rêve longtemps chéri de tous les créateurs de problèmes et développeurs de logiciels doit avoir une solution planifiée au problème (algorithme) et une implémentation de cet algorithme entièrement compatible avec celui-ci. Mais cela ne semble pas fonctionner de cette façon pour les créateurs et les développeurs. Les algorithmes ont tendance à laisser de côté ce qui est important pour les développeurs pour l’implémentation, tandis que le texte du programme en soi ne ressemble guère à l'algorithme.
Ainsi, il existe deux algorithmes - l'un est sur papier (pour enregistrer et documenter les solutions de conception) qui représente généralement un certain résultat de conception au lieu des méthodes employées pour obtenir un résultat donné, tandis que le second algorithme est dans l'esprit du développeur (qui est, cependant, , également enregistré textuellement).
La version finale du texte du programme est souvent suivie de tentatives de modification de la documentation au cours desquelles de nombreux éléments ne sont à nouveau pas pris en compte. Dans ce cas, la logique du programme peut être différente de la logique de l'algorithme, démontrant ainsi un manque de correspondance. Je dis intentionnellement "probable" car personne ne vérifiera jamais le texte du programme d’autrui.
Si le programme est volumineux, il est impossible de vérifier s'il correspond à l'algorithme par le texte seul. L'exactitude de l’implémentation peut être vérifiée à l'aide d'une procédure appelée « test ». Il vérifie essentiellement comment le développeur a saisi l'algorithme (présenté sur papier),l'a transformé en un autre algorithme dans son esprit et l'a sorti en tant que programme. Finalement, le développeur est le seul détenteur d'informations précieuses sur la logique et tout ce qui a été inventé avant l’implémentation devient absolument hors de propos.
Ce n'est même pas que le développeur puisse tomber malade (ou... démissionner). Le fait est que la logique du programme sous-jacent serait différente avec chaque développeur, en fonction de son intelligence et de sa connaissance d'un langage de programmation. Dans tous les cas, le développeur introduit et utilise beaucoup de variables intermédiaires comme bon lui semble. Et si le programme est volumineux et logiquement complexe, un spécialiste plus qualifié sera nécessaire pour trouver les problèmes (et je ne parle pas ici de problèmes de système d'exploitation ou d'utilisation incorrecte des fonctions du langage, mais plutôt d'une implémentation incorrecte en termes de logique) et de le résoudre à travers le texte du programme lui-même.
La majorité des développeurs, pour le moins, n'aiment pas écrire des algorithmes avant de les programmer (ou même de les dessiner sur papier), ce qui est probablement dû au fait qu'ils auront encore besoin de penser à quelque chose par eux-mêmes en cours de route. . En effet, pourquoi perdre du temps à dessiner des rectangles, des losanges et des flèches alors qu'il vaut mieux passer tout de suite à la programmation et disposer ensuite un algorithme un peu similaire ou très général dans la documentation.
Tout le monde s'y est habitué - les développeurs le font parce que c'est plus facile de cette façon, alors que les auteurs de problèmes n'ont pas toujours les compétences de programmation nécessaires et même dans le cas où ils le font, ils sont tout simplement incapables de modifier en temps voulu ce que les développeurs trouveront. Des environnements de programmation pratiques contribuent également à la validité de l'ordre d’élaboration indiqué. Des outils avancés de débogage et de surveillance des valeurs des variables nous donnent l'espoir de détecter toute erreur dans la logique.
Alors que le temps passe et que la date limite du projet approche, le développeur est assis et esquisse sur un « mouchoir » des solutions à un problème logique donné qui, soit dit en passant, doivent encore être implémenté, sans parler des erreurs négligées lors des tests pour les tests suivants à peu près le même scénario (chaotique)... C'est la situation actuelle. Existe-t-il une solution ou peut-elle au moins être améliorée ? On sent que quelque chose d'important est perdu dans la transition d'un algorithme présenté de manière standard au code du programme.
Auteur : MT5