La Programmation Basée sur des Automates comme Nouvelle Approche pour créer des Systèmes de Trading Automatisés
306
0
ἓν οἶδα ὅτι οὐδὲν οἶδα ( ο φιλόσοφος Σωκράτης )
Je sais que je ne sais rien (le philosophe Socrate)
Introduction
Pour commencer, ce sujet est complètement inédit pour les traders qui développent des EA en utilisant le langage MetaQuotes 4/5 (MQL4/5). J'ai pu le constater par moi-même lorsque j'ai essayé de faire une recherche pertinente sur le site Web de MetaQuotes. Il n'y a rien sur ce sujet.
Chaque trader crée son propre Expert Advisor, ce qui nécessite une approche sérieuse pour s'attaquer à toutes sortes de problèmes associés à la programmation et à la logique de programme très compliquée. À la fin de la journée, le programme est censé fonctionner SEUL comme sur des roulettes dans n'importe quelle situation standard et de force majeure.
Mais comment peut-on tout embrasser ? C'est extrêmement difficile, c'est pourquoi les systèmes de contrôle automatique nécessitent une programmation appropriée de tous les systèmes de contrôle qui peut être mieux réalisée en utilisant la seule technologie de programmation appropriée de la programmation basée sur les automates. Ces dernières années, une grande attention s'est portée sur l’élaboration de technologies de programmation pour les systèmes embarqués et temps réel qui fixent de grandes exigences à la qualité des logiciels.
En 1991,l’auteur russe A.A. Shalyto(Conférencier,Professeur, DSc en ingénierie , chef de département «Technologies de Programmation» àSPbSU ITMO) a élaboré une technologie de programmation qu’il a baptisée «programmation à base d’automates» Je pense que les lecteurs trouveront peut-être intéressant de voir à quel point la programmation basée sur des automates ou la technologie SWITCH peut être simple. Il permet de rendre l’élaboration de MTS en utilisant le langage MetaQuotes si pratique qu'il ne pourrait tout simplement pas être mieux. Et il se fond parfaitement dans le système de prise de décision complexe.
1. Travailler jusqu'au problème
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.
2. Partie Logique du Programme
L'auteur de la "programmation basée sur les automates" a proposé le concept suivant de la partie logique idéale d'un programme. Toute la logique du programme est basée sur le commutateur. En termes simples, n'importe quel algorithme de contrôle (automate) peut être implémenté comme indiqué ci-dessous (ne réfléchissez pas beaucoup à la signification des commentaires à ce stade, jetez simplement un œil à la structure).
switch(int STATUS ) // Мulti-valued global state variable of the automaton. { case 0: // start // Checking arc and loop conditions (in order of priority), // transition (change of the value of the variable STATUS) // and execution of arc and loop actions (output function execution); // logging transitions and actions if the condition is met. 0 // Calling nested automata. // Execution of output functions in the state. break ; case 1: // Checking arc and loop conditions (in order of priority), // transition (change of the value of the variable STATUS) // and execution of arc and loop actions (output function execution); // logging transitions and actions if the condition is met. // Calling nested automata. // Execution of output functions in the state. break ; ********* ********* ********* case N-1: // Checking arc and loop conditions (in order of priority), // transition (change of the value of the variable STATUS) // and execution of arc and loop actions (output function execution); // logging transitions and actions if the condition is met. // Calling nested automata. // Execution of output functions in the state. break ; case N: // Checking arc and loop conditions (in order of priority), // transition (change of the value of the variable STATUS) // and execution of arc and loop actions (output function execution); // logging transitions and actions if the condition is met. // Calling nested automata. // Execution of output functions in the state. break ; }
3. Programmation Basée sur des Automates comme Expliqué par l'Auteur AA Shalyto
Quelles que soient les techniques d’élaboration, tout programme dispose d’ états déterminés par toutes ses valeurs de données à un moment donné. Il peut y avoir des centaines voire des milliers de variables et plusieurs flux de contrôle dans un grand programme d'application. Un ensemble complet de ces variables décrit l'état du programme d'application à un moment donné.
L'état du programme peut être traité de manière plus simple comme une collection de valeurs de toutes les variables de contrôle, celles qui participent à toutes les conditions de transition. Un changement dans la valeur d'une des variables de contrôle indiquera alors un changement dans l'état du programme, et le nombre d'états du programme sera déterminé par le nombre maximum possible de combinaisons de valeurs de variables de contrôle apparaissant pendant l'exécution du programme. Admettons que seules des variables de contrôle binaires (indicateurs) soient utilisées dans un programme. Le nombre d’états du programme comprenant des variables de contrôle binaire n se situeront, dans ce cas, dans la plage de n à 2n.
Il est possible que le développeur ait prévu des réactions pour toutes les combinaisons de valeurs de contrôle de variable (2n combinaisons dans notre cas). Cependant, il est plus que probable que certaines combinaisons de valeurs de contrôle de variable(jusqu’à 2n-n) se soient avérées non-spécifiées. Ensuite, si la combinaison inattendue d'actions d'entrée se produit, le programme peut passer à un état non spécifié.
Il a le même impact que l'inaction d'un EA pour un trader dans les événements suivants :
- écart,
- perte du dépôt,
- tomber dans une situation de solde négatif avec un Appel de Marge Ultérieur,
- ne pas prendre de bon bénéfice allant à zéro et plus loin dans le rouge,
- ouverture et clôture incorrectes des longs et des shorts,
- d'autres situations manifestement défavorables.
De tels états sont appelés "non visualisés". La complexité entraîne la difficulté d'énumérer, encore moins de comprendre, tous les états possibles du programme conduisant à son manque de fiabilité... La complexité de la structure est la source d'états non visualisés qui constituent des trappes de sécurité. Le comportement du programme dans un état non spécifié peut aller des défauts de protection de la mémoire à l'extension du programme à de nouvelles fonctions et à la création d'effets secondaires de nature diverse.
De nombreux utilisateurs de PC et probablement tous les développeurs de logiciels ont souvent rencontré des situations où un programme en cours d'utilisation ou en cours d’élaboration se retrouve dans un état non spécifié.
Pour éliminer la possibilité même d'états non spécifiés dans le programme, tous les états requis doivent être explicitement spécifiés dès la phase de conception et une seule variable de contrôle à valeurs multiples doit être utilisée pour les différencier. Il faut alors identifier toutes les transitions possibles entre les états et élaborer un programme pour qu'il ne puisse pas « s'égarer ».
Trois composants sont nécessaires pour atteindre la rigueur dans l’élaboration du comportement du programme :
- Modèle mathématique permettant d'identifier sans ambiguïté les états du programme et les transitions possibles entre eux ;
- Notation graphique pour ce modèle ;
- Méthode universelle d'implémentation des algorithmes exprimés dans cette notation.
Un automate fini basé sur la notion d'« état » est proposé pour à l’usage comme modèle mathématique. La programmation basée sur des automates prend en charge des étapes d’élaboration logiciel telles que la conception, l’implémentation, le débogage et la documentation.
Alors que l’'évènement' devient de plus en plus communément utilisé dans la programmation ces dernières années, l’approche suggérée est axée sur la notion de « État »' Après avoir l’avoir couplé avec le terme'action d’entrée' qui peut être soit une variable d’entrée ou un évènement,le terme 'automate sans sorite'peut être introduit. Ce dernier est suivi par le terme'action de sortie' et la notion de (déterministe fini)automateest introduite plus tard Le domaine de programmation basé sur ce concept est donc appelé programmation basée sur des automates et le processus d’élaboration respectif est appelé conception de programme basée sur des automates.
L’approché spécifiée est spéciale du fait que lorsqu’elle est appliquée,les automates sont représentés par des graphes de transition. Pour différencier entre les nœuds , le terme« affectation d'état » est introduit Lors du choix d'une 'affectation d'états à plusieurs valeurs', les états dont le nombre coïncide avec le nombre de valeurs que la variable sélectionnée peut prendre, peuvent être différencié à l'aide d'une seule variable. Ce fait a permis d’introduire dans la programmation le terme'observabilité du programme'.
La programmation dans le cadre de l'approche proposée est effectuée à travers des « états » plutôt que des « variables » (indicateurs), ce qui permet de mieux comprendre et spécifier le problème et ses composants. Le débogage dans ce cas se fait en se connectant en termes d'automates.
Étant donné que l'approche ci-dessus propose de passer du graphe de transition au code du programme en utilisant une méthode formelle et isomorphe, il semble plus raisonnable de le faire en appliquant des structures de commutation lorsque des langages de programmation de haut niveau sont utilisés. C'est pourquoi il a été décidé d'utiliser le terme « technologie SWITCH » pour désigner le paradigme de la programmation basée sur les automates.
4. Programmation Explicite Basée sur l 'État
L'application de l'approche basée sur les automates a été étendue aux systèmes pilotés par les événements, également appelés « réactifs ». Les systèmes réactifs interagissent avec l'environnement en utilisant des messages au rythme fixé par l'environnement (un EA peut être compris dans la même classe).
L’élaboration de systèmes dirigés par des évènements à l’aide des automates était rendue possible en utilisant l’approche procédurale depuis duquel le nom programmation explicite basée sur l’étatétait dérivé Les actions de sortie sont dans cette méthode affectées à des arcs, des boucles ou des nœuds de graphes de transition (des automates mixtes - des automates de Moore et de Mealy - sont utilisés). Cela permet d'obtenir une représentation compacte de la séquence d'actions étant des réactions aux actions d'entrée pertinentes.
L'approche proposée pour programmer la classe de systèmes donnée présente une centralisation accrue de la logique en raison de son élimination des gestionnaires d'événements et de la génération d'un système d'automates interconnectés appelés à partir des gestionnaires. L'interaction entre les automates dans un tel système peut être réalisée en imbriquant,appelant et échangeant des nombres d'états.
Le système d'automates interconnectés constitue une partie de programme indépendante du système, tandis qu'une partie dépendante du système est formée de fonctions d'action d'entrée et de sortie, de gestionnaires, etc.
Une autre caractéristique clé de l'approche donnée est que lorsqu'elle est appliquée, les automates sont utilisés de la manière trinitaire :
- Aucune spécification
- pour l’implémentation (ils restent dans le code du programme) ;
- pour la journalisation en termes d'automates (comme précisé ci-dessus).
Ce dernier permet de contrôler la précision du fonctionnement du système d'automates. L'enregistrement est effectué automatiquement sur la base du programme élaboré et peut être utilisé pour des problèmes à grande échelle avec une logique de programme complexe. Chaque journal peut dans ce cas être considéré comme un script pertinent.
Les journaux permettent de suivre le programme en fonctionnement et illustrent le fait que les automates ne sont pas des « images » mais de véritables entités actives. L'approche basée sur les automates est proposée pour être utilisée non seulement lors de la création d'un système de contrôle, mais également lors de la modélisation d'objets de contrôle.
5. Concepts de Base de la programmation Axée sur des Automates
Le concept de base de la programmation basée sur les automates estÉTAT.. La principale caractéristique de l’état du système à tout instant t0 est de 'séparer' le futur (t > t0) du passé (t < t0) dans le sens que l’état actuel comprend toutes les informations sur le passé du système qui est nécessaire dans la détermination de ses réactions envers toute action d’entre créée à tout moment donné t0.
Lors de l’utilisation du terme ÉTAT.la connaissance des données de l’historique n’est pas nécessaire. L'état peut être considéré comme une caractéristique spéciale qui combine implicitement toutes les actions d'entrée du passé affectant la réaction de l'entité au moment présent. La réaction ne dépend que de l'action d'entrée et de l'état actuel.
La notion d’ 'action d’entrée' est également l’une des notions principales de la programmation basée sur les automates. Une action d'entrée est le plus souvent un vecteur. Ses composants sont divisés en événements et variables d'entrée, selon la signification et le mécanisme de génération.
La combinaison de l'ensemble fini d'états et de l'ensemble fini d'actions d'entrée constitue un automate (fini) sans sortie. Un tel automate réagit aux actions d'entrée en changeant son état actuel d'une certaine manière. Les règles selon lesquelles les états peuvent être modifiés sont appelées fonction de transition de l'automate.
Ce que nous appelons l’automate (fini) dans la programmation basée sur les automates est essentiellement une combinaison d’'automate sans sorite' et 'action d’entrée'. Un tel automate réagit à l'action d'entrée non seulement en changeant son état mais aussi en générant certaines valeurs aux sorties. les règles de création des actions de sortie sont appelées fonction d’automate de sortie.
Lors de la conception d’un système dont le comportement est complexe, il est nécessaire de prendre comme point de départ le contrôle d’objets existants avec un certain ensemble d’opération et un ensemble d’évènements donné pouvant survenir dans l’environnement externe du (marché).
En pratique, la conception est plus généralement fondée sur des objets de contrôle et des événements :
-
Les données initiales du problème ne sont pas seulement une description verbale du comportement cible du système mais aussi une spécification (plus ou moins) précise de l'ensemble des événements entrant dans le système depuis l'environnement externe et un grand nombre de requêtes et de commandes de tous les objets de contrôle.
-
Un ensemble d'états de contrôle est créé.
-
Chaque demande d'objets de contrôle se voit attribuer une variable d'entrée correspondante de l'automate, tandis que chaque commande se voit attribuer une variable de sortie correspondante. L'automate qui va assurer un comportement système requis est créé en fonction des états de contrôle, des événements, des variables d'entrée et de sortie.
6. Caractéristiques et Avantages du Programme
La première caractéristique d'un programme à base d'automates est que la présence d'une boucle externe est essentielle. Il parait fondamentalement rien de nouveau; l’essentiel ici est que cette boucle sera la seule dans la partie logique de tout le programme! (c’est-à-dire nouvelle tick entrante.)
La seconde caractéristique suit à partir de la première. Tout automate comporte une structure de commutation (en fait, il en est virtuellement fait) qui comprend toutes les opérations logiques. Lorsqu'un automate est appelé, le contrôle est transféré sur l'une des étiquettes 'cas' et suite aux actions correspondantes, l'opération automate (sous-programme) est achevée jusqu'au prochain démarrage. Ces actions consistent à vérifier les conditions de transition et si une certaine condition est remplie, les fonctions de sortie pertinentes sont appelées et l'état de l'automate est modifié.
La principale conséquence de tout ce qui précède est que l’ implémentation d'un automate est non seulement simple mais surtout que le programme peut se passer de nombreuses variables logiques intermédiaires (indicateurs) dont la fonctionnalité dans chaque automate est fournie par une variable d'état à plusieurs valeurs.
La dernière affirmation est difficile à croire car nous nous sommes habitués à utiliser beaucoup de variables globales et locales (indicateurs) sans trop réfléchir. Comment faire sans eux ?! Ce sont très souvent des indicateurs signalant au programme qu'une condition est remplie. L'indicateur est défini (sur TRUE) lorsque le développeur le juge nécessaire mais est ensuite (généralement seulement après que l'indicateur commence à donner lieu aux effets souhaités en étant toujours TRUE) péniblement recherché à être réinitialisé sur FALSE ailleurs dans le programme.
Cela semble familier, n'est-ce pas? Maintenant, regardez l'exemple et voyez : aucune variable supplémentaire n'est utilisée ici ; le changement ne concerne que la valeur du numéro d'état et uniquement lorsqu'une condition logique est remplie. N'est-ce pas un remplacement digne des indicateurs ?!
L'algorithme joue un rôle majeur dans la création d'une partie logique d'un programme. La phrase clé à retenir ici est'partie logique'. L'État sous-entend tout dans ce cas. Un autre mot qui devrait être ajouté est "en attente". Et , à mon avis, nous obtenons une définition assez adéquate d’'état d’attente' Une fois dans l'état, on attend l'apparition des actions d'entrée (attributs, valeurs ou événements). L'attente peut être courte ou longue. Ou, en d'autres termes, il y a des états qui peuvent être instables et stables.
Le première propriété de l’état est le fait qu’un ensemble limité d’actions d’entrée est attendu dans l’état Tout algorithme (et évidemment tout programme) a des informations d'entrée et de sortie. Les actions de sortie peuvent être divisées en deux types : les variables (par exemple les opérations sur les propriétés de l'objet) et les fonctions (par exemple, l'appel de la fonction de démarrage de l'application, la fonction de rapport, etc.).
La second propriété de l’état est de fournir un ensemble de valeurs exactes des variables de sortie. Cela révèle une circonstance très simple mais extrêmement importante - toutes les valeurs de variables de sortie peuvent être déterminées à tout moment car l'algorithme (programme) est dans un certain état à chaque instant.
Le nombre d'états est limité, de même que le nombre de valeurs de variables de sortie. La fonction d'enregistrement des transitions est intégrée en douceur dans la fonction d'automate et la séquence des transitions entre les états, ainsi que la livraison des actions de sortie peuvent donc toujours être déterminées.
La liste complète des caractéristiques est fournie dans la section 2. Les caractéristiques de la Technologie Proposée, et la liste complète des avantages est disponible dans la section 3. Avantages de la technologie proposée. Cet article ne peut tout simplement pas couvrir la grande quantité d'informations sur le sujet ! Après une étude approfondie de toute la bibliographie de recherche écrite par Anatoly Shalyto, toutes les questions théoriques doivent lui être adressées personnellement à shalyto@mail.ifmo.ru.
Et étant l'utilisateur de ses idées scientifiques tout en ayant à l'esprit nos objectifs et nos problèmes, je donnerai plus loin ci-dessous trois exemples de mon implémentation de la technologie de programmation basée sur les automates.
7. Exemples de Programmation Basée sur des Automates
7.1. Exemple de Compréhension
L'état n'est qu'un mode dans lequel le système existe. Par exemple, l'eau existe sous 3 états : solide, liquide ou gazeux. Il passe d'un état à un autre lorsqu'il est influencé par une variable - la température (à pression constante).
Admettons que nous ayons un graphique temporel de la température (t) (dans notre cas - la valeur du prix):
int STATUS=0; // a global integer is by all means always a variable !!! STATUS is a multi-valued flag //----------------------------------------------------------------------------------------------// int start() // outer loop is a must { switch(STATUS) { case 0: //--- start state of the program if(T>0 && T<100) STATUS=1; if(T>=100) STATUS=2; if(T<=0) STATUS=3; break; case 1: //--- liquid // set of calculations or actions in this situation (repeating the 1st status -- a loop in automata-based programming) // // and calls of other nested automata A4, A5; if(T>=100 ) { STATUS=2; /* set of actions when transitioning, calls of other nested automata A2, A3;*/} if(T<0) { STATUS=3; /* set of actions when transitioning, calls of other nested automata A2, A3;*/} // logging transitions and actions when the condition is met. break; case 2: //--- gas // set of calculations or actions in this situation (repeating the 2nd status -- a loop in automata-based programming) // // and calls of other nested automata A4, A5; if(T>0 && T<100) { STATUS=1; /* set of actions when transitioning, calls of other nested automata A2, A3;*/} if(T<=0) { STATUS=3; /* set of actions when transitioning, calls of other nested automata A2, A3;*/} // logging transitions and actions when the condition is met. break; case 3: //--- solid // set of calculations or actions in this situation (repeating the 3rd status -- a loop in automata-based programming) // // and calls of other nested automata A4, A5; if(T>0 && T<100) {STATUS=1; /* set of actions when transitioning, calls of other nested automata A2, A3;*/} if(T>=100) {STATUS=2; /* set of actions when transitioning, calls of other nested automata A2, A3;*/} // logging transitions and actions when the condition is met. break; } return(0); }
Le programme peut être rendu plus sophistiqué en ajoutant le paramètre de pression P et de nouveaux états et en introduisant une dépendance complexe démontrée dans le graphique :
Cet automate a 32 = 9 conditions de transition donc rien ne peut être omis ou négligé. Ce style peut également être très pratique lors de la rédaction d'instructions et de lois ! Aucune échappatoire et contournement des lois ne sont autorisés ici - toutes les combinaisons de variantes de succession d'événements doivent être couvertes et tous les cas décrits.
La programmation à base d'automates nous oblige à tout prendre en compte, même si certaines variantes de succession d'événements ne seraient pas envisagées autrement, c'est pourquoi c'est l'outil principal pour vérifier la cohérence et l'intégrité des lois, des instructions et des systèmes de contrôle. Il existe aussi une loi mathématique :
Diagramme de transition : N = 3 états, le nombre de transitions et boucle est N2 = 9 (égal au nombre de flèches).
Si le nombre de variables dans l'exemple était différent, alors :
Il indique que les valeurs calculées dans le tableau augmententexponentiellement,c’est-à-dire que la conception est un processus compliqué qui exige de la minutie lors de la sélection des principales valeurs systémiques.
Même s'il n'y a que deux paramètres, il est très difficile de tout décrire ! Cependant, dans la pratique, tout est beaucoup plus facile! Dépendamment de la logique et la signification, les transitions de 50 à 95 % ne peuvent pas exister physiquement et le nombre d'états est également inférieur de 60 à 95 %. Cette analyse de la logique et du sens diminue considérablement la difficulté de décrire toutes les transitions et tous les états.
Dans les cas plus compliqués, il est nécessaire de calculer le nombre maximum d'états pour toutes les données d'entrée et de sortie connues dans un EA. La solution à ce problème peut être trouvée en appliquant la combinatoire etcombinaison, permutation, disposition et formules énumératives combinatoires
7.2. Relais avec Hystérésis
La programmation de relais, de déclencheurs, de registres, de compteurs, de décodeurs, de comparateurs et d'autres éléments de système de contrôle numérique et analogique non linéaires peut être très pratique dans un EA.
- xmax = 100 - la valeur de la reprise maximale
- xmin = -100 - la valeur de la reprise minimale
- x = x(t) - signal à l'entrée ;
- Y = Y(t) - signal à la sortie.
int status=0; // at the beginning of the program we globally assign //------------------------------------------------------------------// switch(status) { case 0: // start Y=x; if(x>xmax) {status=1;} if(x<xmin) {status=2;} break; case 1: //++++++++++++++++++++ if(x>xmax) Y=x; if(x<xmax) Y=xmin; if(x<=xmin) {status=2; Y=xmin;} break; case 2: //-------------------- if(x<xmin) Y=x; if(x>xmin) Y=xmax; if(x>=xmax) {status=1; Y=xmax;} break; }
La caractéristique du relais :
7.3. Modèle pour 9 États et 81 variantes de succession d'événements
Y est l'état d'entrée courant de l'automate de 1 à 9. La valeur de Y est créée dans l'EA en dehors du sous-programme donné. MEGASTATUS est l'état passé de Y.
int MEGASTATUS=0; // at the beginning of the program we globally assign //---------------------------------------------------------------------// void A0(int Y) // automaton template { switch(MEGASTATUS) { case 0: // start MEGASTATUS=Y; break; case 1: // it was the past // it became current, repeating if(Y=1) { /*set of actions in this situation, calls of other nested automata A2, A3, ... */ } // Loop// // new current if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 2: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } //Loop// if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } // e.g. if the transition from 2 to 6 is in essence impossible or does not exist, do not write anything if(Y=6) { /* set of actions in this situation */ } // the automaton will then be reduced but the automaton template shall be complete to count in everything if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 3: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } //Loop// if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 4: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } //Loop// if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 5: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } //Loop// if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 6: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } //Loop// if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 7: // it was the past //it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } //Loop// if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 8: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } //Loop// if(Y=9) { /* set of actions in this situation */ } // logging transitions and actions when the condition is met. break; case 9: // it was the past // it has become current if(Y=1) { /* set of actions in this situation */ } if(Y=2) { /* set of actions in this situation */ } if(Y=3) { /* set of actions in this situation */ } if(Y=4) { /* set of actions in this situation */ } if(Y=5) { /* set of actions in this situation */ } if(Y=6) { /* set of actions in this situation */ } if(Y=7) { /* set of actions in this situation */ } if(Y=8) { /* set of actions in this situation */ } if(Y=9) { /* set of actions in this situation */ } //Loop// // logging transitions and actions when the condition is met. break; } MEGASTATUS=Y; }
7.4. Automate de Lecteur Audio
Passons en revue Simple Lecteur Audio.
Cet appareil peut être dans 6 états :
- Prêt
- Pas de piste ;
- Jouant;
- Avance rapide;
- Rembobiner;
- Pause.
Le système de contrôle du lecteur audio est représenté par un automate. Les boutons enfoncés sont considérés comme des événements ayant un impact sur l'automate. Les transitions entre les pistes, la lecture, le contrôle de l'affichage, etc. sont des actions de sortie.
switch(STATUS) { case 0: //--- "Ready" if(Event == 3) { STATUS = 3; } //«>>» button pressed if(Event == 6) { STATUS = 1; } //Audio file not found if(Event == 1) { STATUS = 2; } //«PLAY» button pressed z1(); // Set the indicator to the initial state break; case 1: //--- "No Track" z6(); // Give the «No Track» message break; case 2: //--- "Playing" if(Event == 4) { STATUS = 4; } //«<<» button pressed if(Event == 5) { STATUS = 5; } //«PAUSE»( | | ) button pressed if(Event == 3) { STATUS = 3; } //«>>» button pressed if(Event == 2) { STATUS = 0; } //«STOP» button pressed z2(); // Playing break; case 3: //--- "Fast-Forward" z3(); // Next track { STATUS=2; } break; case 4: //--- "Rewind" z4(); // Previous track { STATUS=2; } break; case 5: //--- "Pause" if(Event == 5) { STATUS = 2; } //«PAUSE» button pressed if(Event == 1) { STATUS = 2; } //«PLAY» button pressed if(Event == 2) { STATUS = 0; } //«STOP» button pressed if(Event == 3) { STATUS = 3; } //«>>» button pressed if(Event == 4) { STATUS = 4; } //«<<» button pressed z5(); //Pause break; }
En théorie, cet automate pourrait comprendre 36 variantes de transition, mais seulement 15 existent réellement et tous les détails peuvent être trouvés dans la description fournie par l'auteur.
8. А.А. Recommandations de Shalyto concernant l'exécution du projet
Des informations complètes sur la préparation et la rédaction de la documentation du projet peuvent être trouvées ici http://project.ifmo.ru/books/3, en revanche dans cet article je vais seulement vous donner un court extrait:
- Le livre de А.А. Shalyto "Contrôle Logique. Méthodes d’Implémentation Matérielle et Logicielle des Algorithmes. SPb. : Nauka, 2000", disponible sur le site Web spécifié dans la section "Livres" peut être considéré comme un prototype". Il incarne une présentation correcte de l'information telle qu'elle a été publiée par la maison d'édition la plus ancienne et la plus réputée de Russie.
- L'introduction doit justifier la pertinence du sujet choisi, énoncer brièvement le problème examiné et préciser le langage de programmation et le système d'exploitation utilisés dans le projet.
- Une description verbale détaillée du problème à résoudre doit être fournie dans la section « Description du problème » avec des chiffres, des diagrammes et des captures d'écran clarifiant le problème décrit.
- Lors de l'utilisation de la programmation orientée objet, la section "Conception" doit inclure un diagramme de classes. Les classes principales doivent être soigneusement décrites. Il est conseillé qu'un "Schéma bloc de la classe" soit préparé pour chacun d'eux visant à présenter son interface et les méthodes utilisées ainsi que l'indication des méthodes à base d'automates.
- Trois documents doivent être fournis pour chaque automate dans la section « Automates » : une description verbale, un schéma de liaison de l'automate et un graphe de transition.
- Une description verbale doit être assez détaillée, mais étant donné que le comportement d'un automate complexe est difficile à décrire de manière claire, il s'agit généralement d'une "déclaration d'intention".
- Le schéma de liaison de l'automate fournit une description détaillée de son interface. La partie gauche du diagramme doit comporter :
- source de données;
- nom complet de chaque variable d'entrée ;
- nom complet de chaque événement ;
- prédicats avec des numéros d'état d'autres automates qui sont utilisés dans l'automate donné comme actions d'entrée. Par exemple, le prédicat Y8 == 6 peut être utilisé qui prend la valeur égale à un une fois que le huitième automate passe au sixième état) ;
- variables d'entrée désignées par x avec les indices pertinents ;
- événements notés e avec les indices pertinents ;
- des variables pour mémoriser les états de l'automate avec le nombre N, noté YN.
La partie droite du diagramme doit comporter :- des variables de sortie notées z avec des indices pertinents ;
- nom complet de chaque variable de sortie ;
- événements créés par l'automate donné (le cas échéant) ;
- nom complet de chaque événement créé ;
- récepteurs de données.
- Si des algorithmes de calcul complexes sont utilisés dans des nœuds ou des transitions, la section "Algorithmes de Calcul" explique le choix des algorithmes et fournit leur description (y compris la description mathématique). Ces algorithmes sont désignés par les variables x et z, selon que les calculs sont faits en entrée ou en sortie.
- Les spécificités de l’ implémentation du programme doivent être énoncées dans la section « implémentation ». Il devrait notamment présenter un modèle pour une implémentation formelle et isomorphe d'automates. Des implémentations d'automates devraient également être fournies ici.
- « Conclusion » couvre les avantages et les inconvénients du projet achevé. Elle peut aussi offrir des pistes d'amélioration du projet.
9. Conclusion
Je vous encourage tous à :
- explorer cette nouvelle approche de la programmation.
- implémenter cette approche totalement nouvelle et extrêmement intéressante pour programmer vos idées et stratégies de trading.
J'espère que la programmation basée sur les automates :
- au fil du temps, deviendra la norme en matière de programmation et de conception pour tous les traders et même les développeurs du langage MetaQuotes.
- être la base d'une prise de décision complexe lors de la conception d'une EA.
- à l'avenir,élaborer un nouveau langage - MetaQuotes Language 6 - prenant en charge l'approche de programmation basée sur les automates et une nouvelle plate-forme - MetaTrader 6.
Si tous les développeurs de trading suivent cette approche de programmation, l'objectif de créer un EA sans perte peut être atteint. Ce premier article est ma tentative de vous montrer un tout nouveau débouché pour la créativité et la recherche dans le domaine de la conception et de la programmation basées sur les automates comme impulsion à de nouvelles inventions et découvertes.
Et encore une chose - je suis entièrement d'accord avec l'article de l'auteur et je pense qu'il est important de vous le fournir sous une forme concise (texte complet ici http://is.ifmo.ru/works/open_doc/):
Pourquoi les Codes Sources ne sont Pas une Solution pour Comprendre les Programmes
La question centrale dans la programmation pratique est la question de la compréhension des codes de programme. Il est toujours avantageux d'avoir des codes sources à portée de main mais le problème est que cela ne suffit souvent pas. Et une documentation supplémentaire est généralement nécessaire pour acquérir une compréhension d'un programme non trivial. Ce besoin augmente de façon exponentielle à mesure que la quantité de code augmente.
L'analyse de code de programme visant à restaurer les décisions de conception originales prises par les développeurs et la compréhension des programmes sont deux branches importantes de la technologie de programmation dont l'existence va de pair avec l'insuffisance des codes sources pour comprendre les programmes.
Quiconque a déjà été impliqué dans un projet majeur de reconstruction de logiciel se souviendra toujours du sentiment d'impuissance et de perplexité qui survient lorsque vous voyez pour la première fois un tas de codes sources mal documentés (mais pas toujours mal écrits). La disponibilité des codes sources n'est pas vraiment d'une grande aide lorsqu'il n'y a pas d'accès aux développeurs clés. Si le programme est écrit dans un langage de niveau relativement bas et est en outre mal documenté, toutes les principales décisions de conception se dispersent généralement dans les détails de programmation et nécessitent une reconstruction. Dans de tels cas, la valeur de la documentation de niveau supérieur, telle que la spécification de l'interface et la description de l'architecture, peut l'emporter sur la valeur du code source lui-même.
La prise de conscience du fait que les codes sources sont inadéquats pour comprendre les programmes a donné lieu à des tentatives de combiner le code et une documentation de niveau supérieur.
Si vous manquez les premières étapes du projet, la complexité et la quantité de travail vous "verrouilleront" virtuellement les codes sources, à condition qu'il n'y ait pas de documentation de haut niveau en place. Comprendre le code « préhistorique » en l'absence des développeurs travaillant à l'origine sur le projet ou d'une documentation adéquate permettant de trier les décisions architecturales pertinentes est probablement l'un des défis les plus difficiles rencontrés par les programmeurs ».
Pourquoi les Programmes Manquent de Conception
Ainsi, si l'absence de codes sources peut être mauvaise, leur disponibilité peut également être peu bénéfique. Que manque-t-il encore à une vie « heureuse pour toujours » ? La réponse est simple - une documentation de conception détaillée et précise qui inclut la documentation du programme comme l'un de ses composants.
Les ponts, les routes et les gratte-ciel ne peuvent normalement pas être construits sans documentation à portée de main, ce qui n'est pas le cas des programmes.
La situation qui s'est produite dans la programmation peut être définie comme suit : « Si les maçons construisaient des bâtiments comme les programmeurs écrivaient des programmes, alors le premier pique-bois qui arriverait détruirait la civilisation. »
Pourquoi est-ce qu'une bonne partie de la documentation de conception détaillée et claire est publiée pour le matériel et peut être relativement facilement comprise et modifiée par un spécialiste moyen même des années après sa publication, alors qu'une telle documentation est soit inexistante pour le logiciel, soit écrite dans un manière purement formelle et un spécialiste hautement qualifié est nécessaire pour la modifier (si le développeur est absent) ?
Apparemment, cette situation peut être expliquée comme suit. Premièrement, l’élaboration et la fabrication de matériel informatique sont deux processus différents exécutés par des organismes différents Par conséquent, si la qualité de la documentation est médiocre, l'ingénieur de développement passera le reste de sa vie à travailler dans « l'usine », ce qui n'est évidemment pas ce qu'il souhaiterait. En ce qui concerne l’élaboration de logiciels, la situation change car dans ce cas, le développeur et le fabricant du logiciel sont généralement une seule et même entreprise et donc, quelle que soit la liste des documents, leur contenu sera, en règle générale, assez superficiel.
Deuxièmement, le matériel est « dur », tandis que le logiciel est « doux ». Cela facilite la modification des programmes mais ne justifie pas la non-émission complète de la documentation de conception. Il est connu que la plupart des programmeurs sont pathologiquement réticents à lire, et a fortiori à écrire, de la documentation.
L'expérience suggère que pratiquement aucun des programmeurs fraichement diplômés, même les plus intelligents, ne peut préparer la documentation de conception. Et malgré le fait que beaucoup d'entre eux aient suivi et réussi des cours longs et complexes en mathématiques, cela n'a pratiquement aucun impact sur leur logique et leur rigueur dans la rédaction de la documentation. Ils peuvent utiliser des notations différentes pour une seule et même chose dans toute la documentation (quelle que soit sa taille), l'appelant ainsi par exemple l'ampoule, l'ampoule, la lampe ou la lampe, en l'écrivant avec une lettre minuscule ou majuscule quand ils le souhaitent. Imaginez ce qui se passe quand ils donnent toute leur envergure à leur fantaisie !
Apparemment, cela est dû au fait que lors de la programmation, le compilateur signale des incohérences alors que la documentation de conception est écrite sans une quelconque incite.
La question de la qualité de la documentation des logiciels devient une question d'importance sociale croissante. L’élaboration de logiciels s'apparente progressivement au show business avec sa forte motivation au profit. Tout se fait dans une course folle, sans penser à ce que deviendra le produit dans le futur. Comme le show business, la programmation mesure tout en termes de « bénéfices et pertes », plutôt que de « bons et mauvais ». Dans la majorité des cas, une bonne technologie n'est pas celle qui est réellement bonne mais celle qui rapporte.
La réticence à rédiger la documentation de conception est probablement aussi associée au fait que plus le projet est restreint (non documenté), plus l'auteur est indispensable.
Un tel comportement au travail s'étend malheureusement à l’élaboration de logiciels pour des systèmes hautement critiques. C'est en grande partie dû au fait que les programmes sont dans la plupart des cas écrits et non conçus. "Lors de la conception de toute technique plus compliquée que cartes CRC ou usage des diagrammes de cas est considéré trop complexe et par conséquent n’est pas utilisé Un programmeur peut toujours refuser d'appliquer une technologie donnée en signalant au patron qu'il pourrait ne pas être en mesure de respecter le délai".
Cela conduit à des situations où même les "utilisateurs ne considèrent pas les erreurs dans le logiciel comme quelque chose d'anormal".
Il est actuellement largement admis que la conception et la documentation appropriée doivent être en place lorsqu'il s'agit de grands bâtiments, et non de logiciels.
En conclusion, il convient de noter qu'une telle situation n'existait pas dans la programmation dans le passé - lorsque les premiers ordinateurs à grande échelle étaient utilisés, les programmes étaient soit conçus ou élaborés avec beaucoup de soin car en cas d'erreur, la prochaine tentative aurait normalement lieu dès le début d'une journée. Ainsi, les progrès techniques nous ont conduits à une programmation moins soignée.
Les références
Malheureusement, nos problèmes et préoccupations ne peuvent pas être retracés sur le site Web du département de l'institut où AA Œuvres de Shalyto Ils ont leurs propres problèmes et objectifs et ne connaissent pas du tout, et ignorent, nos concepts et définitions, d'où aucun exemple pertinent pour notre sujet.
Les principaux livres/manuels de AA Shalyto :
- Programmation Basée sur des Automates. http://is.ifmo.ru/books/_book.pdf
- Utiliser des Graphes de Fluence et les Graphes de Translation dans l’implémentation des algorithmes de Contrôle Logiquehttp://is.ifmo.ru/download/gsgp.pdf
- Programmation Basée sur les Automates. http://is.ifmo.ru/works/_2010_09_08_automata_progr.pdf
- Transformation d'algorithmes itératifs en algorithmes basés sur des automates. http://is.ifmo.ru/download/iter.pdf
- Technologie Switch : Approche basée sur les automates pour le développement de logiciels pour les systèmes réactifs. http://is.ifmo.ru/download/switch.pdf
- Conception de Programmes Basés sur des Automates. Algorithmisation et programmation de problèmes de contrôle logique. http://is.ifmo.ru/download/app-aplu.pdf
- Utiliser une Algorithme Génétique pour Concevoir un Autopilote d’un Modèle Simplifié d’Hélicoptère.http://is.ifmo.ru/works/2008/Vestnik/53/05-genetic-helicopter.pdf
- Programmation explicite basée sur l'état. http://is.ifmo.ru/download/mirpk1.pdf
- Algorithmisation et programmation pour le contrôle logique et les systèmes réactifs. http://is.ifmo.ru/download/arew.pdf
- Approche orientée objet de la programmation basée sur des automates. http://is.ifmo.ru/works/ooaut.pdf
- Notation graphique pour l'héritage des classes basées sur des automates. http://is.ifmo.ru/works/_12_12_2007_shopyrin.pdf
- Programmation en... 1 (une) minute. http://is.ifmo.ru/progeny/1minute/?i0=progeny&i1=1minute
Projets
- Modélisation du fonctionnement des guichets automatiques. http://is.ifmo.ru/unimod-projects/bankomat/
- Modélisation du processus de contrôle des réacteurs nucléaireshttp://is.ifmo.ru/projects/reactor/
- Système de contrôle d'ascenseur. http://is.ifmo.ru/projects/elevator/
- Élaboration basé sur des automates du système de contrôle de la cafetière. http://is.ifmo.ru/projects/coffee2/
- Conception et recherche d'automates pour la conduite. http://is.ifmo.ru/projects/novohatko/
- Modélisation d'un appareil photo numérique à l'aide d'une programmation basée sur des automates.http://project.ifmo.ru/shared/files/200906/5_80.pdf
- Utilisation de la programmation basée sur des automates pour modéliser un système multi-agents pour les véhicules sans pilote.http://project.ifmo.ru/shared/files/200906/5_41.pdf
- Système de solution visuelle Rubik's Cube. http://is.ifmo.ru/projects/rubik/
et d'autres articles et projets intéressants : http://project.ifmo.ru/projects/, http://is.ifmo.ru/projects_en/ and http://is.ifmo.ru/articles_en/.
P.S.
Le nombre d'événements différents possibles d'un Rubik's Cube est(8! × 38−1) × (12! × 212−1)/2 = 43 252 003 274 489 856 000. . Mais ce nombre ne tient pas compte du fait que les carrés centraux peuvent avoir des orientations différentes.
Ainsi, compte tenu des orientations des faces centrales, le nombre d'événements devient 2048 fois plus important, soit 88 580 102 706 155 225 088 000.
Le marché et l'échange Forex n'ont pas autant de variantes de succession d'événements, mais les problèmes qui leur sont associés peuvent facilement être résolus en 100 à 200 étapes en utilisant ce paradigme de programmation. C'est vrai! Le marché et les EA sont en concurrence constante. C'est comme jouer auxéchecs Où personne ne sait les mouvements prochains de l’opposant (juste comme nous) Cependant, il existe des programmes informatiques impressionnants, tels que Rybka (moteur d'échecs très puissant) conçu sur la base d'algorithmes d'élagage alpha-bêta.
Puissent ces succès des autres dans d'autres domaines de programmation vous donner de l'énergie et de l'engagement envers notre travail ! Bien que nous sachions certainement tous que nous ne savons rien.
Traduit du russe par MetaQuotes Ltd.
Article original : https://www.mql5.com/ru/articles/446
Les membres de la MQL5.community les plus actifs ont reçu des iPhones !
OpenCL : De la programmation naïve à une programmation plus perspicace
Documentation générée automatiquement pour le code MQL5
OpenCL : Le Pont vers les Mondes Parallèles
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Vous acceptez la politique du site Web et les conditions d'utilisation