![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
72 cas, 24 nouveaux cas spéciaux, un système d'écriture non linéaire, une grammaire matricielle, une morphosyntaxe, un boustrophédon et une phonétique spéciale - exactement ce dont les sectes commerciales les plus cool ont besoin (pour que les Tchékistes et les Francs-maçons ne puissent pas voler le Graal).
Oui, il faut absolument traduire l'expression "croisement de deux moyennes mobiles" en Ifkuil).
En raison du fait que le sujet de ce thème est largement philosophique et ne s'inscrit pas seulement dans les limites de l'algotraining, mais aussi (dans certains endroits) de la programmation en général, j'ai décidé de compléter la série de parties du concept par une dernière théorie de "l'algorithme de complication", en exposant sa compréhension et en répondant à la question - un tel algorithme peut-il exister en principe ?
Comme prévu, nous allons considérerle "mécanisme de complication" sur l'exemple d'un simple marqueur rectangulaire sur l'écran de pixels, dessiné en appelant une fonction graphique composée de deux boucles imbriquées (hauteur et largeur) et utilisant 5 paramètres de base - x, y, largeur, hauteur, couleur.
Nous appellerons la fonction de dessin le "constructeur" et son jeu de paramètres l'objet. Il convient de noter que, pour la plupart des gens,un objet est un "sous-ensemble" de pixels séparés par une couleur et combinés géométriquement en un ensemble commun de pixels de l'écran, mais pour le programmeur, un objet n'est pas seulement une forme externe, perçue par l'œil, mais aussi la création du mécanisme lui-même. Une étiquette, comme nous le savons, est "construite" en deux cycles par la fonction de dessin, ce qui signifie que la fonction avec ses paramètres est également une "étiquette". Ce point est difficile à réaliser, car la personne est habituée à la perception visuelle d'une coquille d'objet et considère le code qui se cache derrière comme quelque chose de farfelu et de secondaire, cependant - c'est l'objet lui-même, après tout, en cas de changement de la mise en œuvre de la fonction initiale ou des valeurs de ses paramètres, le changement externe d'une coquille suit inévitablement.
Je trouve plus facile de séparer le jeu de paramètres d'une fonction de son implémentation interne et de le traiter comme l'objet principal, bien que ce ne soit évidemment pas vrai, car l'implémentation interne de la fonction constructeur et son jeu de paramètres sont inextricablement liés. Cependant, l'implémentation interne change beaucoup moins fréquemment et ces changements sont plus fondamentaux que, par exemple, des changements dans les valeurs de l'ensemble paramétrique, qui sont faciles à travailler et à expérimenter. Si la méthode de mise en œuvre de la fonction constructeur change, un nouvel ensemble de paramètres apparaît, ce qui entraîne des modifications de tous les "proto-blocs" construits sur la base de l'ancien ensemble de paramètres de la fonction constructeur. I.e. si nous avons initialement construit un état alternatif de l'étiquette avec 5 paramètres :x, y, largeur, hauteur, couleur avec des valeurs différentes et que nous l'avons ensuite "activé" lors d'un événement, alors un changement inattendu de la méthode d'implémentation du constructeur de fonctions, qui réduit le nombre de paramètres, disons, à 3, changera la structure de l'ensemble paramétrique primaire (à partir duquel d'autres états, événements ou processus ont probablement déjà été créés) et la construction précédente de l'état alternatif de l'étiquette "s'effondrera", devenant inutile pour la nouvelle version du constructeur de fonctions. Nous sommes ici confrontés au premier obstacle majeur de la mise en œuvre de l'algorithme de complication : la méthode de mise en œuvre de la fonction-constructeur fixe des limites au potentiel de complication de l'objet. Transcender ces frontières sans intervention humaine, selon un algorithme quelconque, est une complication automatisée.
Considérons une complication expérimentale "simple" d'une étiquette sans changer la méthode originale de sa mise en œuvre de fonction-constructeur et sans entrer dans le sens de la complication - nous allons seulement changer les valeurs de son jeu de paramètres et "débrancher" de nouveaux états sur sa base et voir ce que nous obtenons :
Conclusion :
Il est certain qu'il serait nécessaire d'écrire plus d'un livre et qu'un post ne suffira pas, mais il est déjà évident que si nous définissons l'objectif de la complication d'un programme, de sorte qu'il crée des modèles d'objets avec différents états, événements, réactions à l'environnement, même sans changer la mise en œuvre d'un concepteur de fonctions et en s'appuyant sur un ensemble de paramètres fixes, probablement, après une nième quantité d'essais et d'erreurs, il pourrait créer une étiquette exécutant une tâche simple, mais ce programme devrait "être capable" de construire des "proto-blocs" - états, événements, Je suis optimiste, même si je peux imaginer la complexité d'une telle tâche.
Bonjour à tous j'ai un conseiller expert j'ai besoin de plus de détails si quelqu'un est bon à cela maintenant je teste environ 100$ par jour sur eurusd et usdchf.
va...
les objets qu'il contient sont mal représentés :-)
PS/ garantie d'échec, quels que soient les objets
Si vous vous trouvez soudainement dans un état d'esprit cognitif, lisez sur la programmation génétique (spoiler : vous ne pouvez pas faire sans Bacus-Naurus).