Discussion de l'article "La Programmation Basée sur des Automates comme Nouvelle Approche pour créer des Systèmes de Trading Automatisés" - page 4
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
L'article n'aborde pas du tout le sujet, si ce n'est qu'il existe un interrupteur. Qu'il existe ou non n'a pas d'importance, il peut être commuté par des "si".
Une fois, j'écrivais un EA, il y avait un système très complexe avec des ordres. J'ai dû l'analyser sérieusement et dresser une liste d'états : aucun ordre, un ordre en attente, un ordre de marché, deux ordres en attente, un ordre en attente et un ordre de marché, etc. Ce n'est que de cette manière que j'ai réussi à surmonter le problème. Mais il s'est avéré qu'il s'agissait d'une chose tellement universelle et rapidement reprogrammable. Il y a là matière à article.
Peut-être pourriez-vous alors écrire un article ? Je pense que beaucoup de gens seraient intéressés par sa lecture.
D'accord, je le ferai.
Je préfère également utiliser un if classique. En général, il y a deux approches : avec l'aide de if et avec l'aide de fonctions spéciales qui sont appelées par le commutateur d'état. La question est de savoir quelle approche est la meilleure/simple.
Il est nécessaire d'examiner le sujet, le compteur est plus rapide dans le choix d'une solution, mais if est plus facile à appeler.
S'il y a beaucoup de compteurs imbriqués, alors if fonctionnera plus rapidement, parce qu'un appel à if est moins coûteux qu'un appel à switch.
Mais s'il existe plusieurs solutions à chaque niveau, switch est plus approprié.
Il s'agit d'une nouveauté. N'IMPORTE QUELLE TS (sans exception) est basée sur l'analyse et la compréhension claire des états de la TS. Les états les plus simples : le traitement des signaux pour l'ouverture/la clôture/la modification d'un ordre, etc. etc.
Si "l'état actuel de l'Expert Advisor n'est pas clairement connu", alors ce n'est certainement pas un Expert Advisor, et certainement pas un programme, et le mot "algorithme" en relation avec un Expert Advisor devrait être rayé et oublié pour toujours.
Les informations sur le marché arrivent en retard, il peut y avoir (et il y a probablement) des erreurs dans le logiciel sur le serveur et sur l'ordinateur, les ordres peuvent ne pas être exécutés pour un million de raisons, le réseau - la connexion au fournisseur peut clignoter, l'électricité peut être coupée à tout moment (rappelez-vous les pannes et les redémarrages au championnat). Les facteurs d'incertitude sont plus que suffisants. Et un conseiller expert ou un algorithme doit les prendre tous en compte. Il est impossible de compter sur le fonctionnement parfait du serveur, du logiciel, de la communication, du marché, de l'opérateur, de l'électricité.
Ainsi, l'état actuel des ordres, du marché, de la communication, de l'électricité n'est jamais connu de l'Expert Advisor, et l'Expert Advisor ou l'algorithme doit toujours fonctionner correctement dans des conditions floues.
les informations sur le marché arrivent en retard, il peut y avoir (et il y a probablement) des erreurs dans le logiciel du serveur et de l'ordinateur, les ordres peuvent ne pas être exécutés pour un million de raisons, le réseau - la connexion au fournisseur - peut se détraquer, l'électricité peut être coupée à tout moment (rappelez-vous les pannes et les redémarrages au championnat). Les facteurs d'incertitude sont plus que nombreux. Et un conseiller expert ou un algorithme doit les prendre tous en compte. Il est impossible de compter sur le fonctionnement parfait du serveur, du logiciel, de la communication, du marché, de l'opérateur, de l'électricité.
Ainsi, l'état actuel des ordres, du marché, de la communication, de l'électricité n'est jamais connu de l'Expert Advisor, et l'Expert Advisor ou l'algorithme doit toujours fonctionner correctement dans des conditions floues.
Absurde. Tout mélanger en un seul gros tas.
- vérification d'éventuels retards de cotation ; - refus du courtier d'exécuter un ordre ; - redémarrage anormal du conseiller expert - il s'agit d'états clairs et précis du conseiller expert - à la suite de l'identification de chacun de ces états - exécution de la fonction correspondante
- si une fonction n'est pas fournie en réponse à un état possible, cela ne signifie pas un "état de fonctionnement flou", mais simplement que l'EE n'analyse pas (selon son algorithme clair et sans ambiguïté) cet état.
Tout programme (y compris un conseiller expert) fonctionne selon un algorithme clair et prédéterminé. Il n'y a pas d'actions floues et indéfinies dans le travail d'un programme. Dans le cas contraire, il s'agirait d'un état de "gel". Et le "gel" d'un programme est, comme nous le savons, une erreur d'algorithme, et non la conséquence d'un flou éthéré.
Pour les véritables conseillers experts, il est impossible de définir l'état sans ambiguïté. L'état interne est déterminé sans ambiguïté, mais l'état des positions sur le serveur peut être inconnu, connu avec un retard, être dans un état flou (certains ordres et demandes sont exécutés, d'autres non, et personne ne sait pourquoi).
Les facteurs d'incertitude sont plus que suffisants. Un conseiller expert ou un algorithme doit les prendre tous en compte. Il est impossible de compter sur un fonctionnement parfait du serveur, du logiciel, de la communication, du marché, de l'opérateur, de l'électricité. Par conséquent, l'état actuel des ordres, du marché, de la communication, de l'électricité n'est jamais connu du conseiller expert en général.
Il n'y a pas d'incertitudes. Il y a des erreurs d'un programmeur qui n'a pas pris quelque chose en compte.
"Non connu", "dans un état peu clair" sont des états à part entière comme tous les autres. Bien sûr, il faut les prendre en compte, sinon il n'y a pas d'autre solution.
Si vous écrivez la ligne "c = a + b", il s'agit d'une programmation théorique, qui n'est acceptable que dans les cours d'école. Mais lorsque vous programmez une véritable installation industrielle, une opération utile comme "c = a + b" nécessite 100500 opérations de vérification pour confirmer qu'une entrée est bien "a", qu'une autre entrée est bien "b", et vous devez également vous assurer que "a" et "b" n'ont pas changé pendant l'addition, et si soudainement "c" n'atteint pas la sortie, l'opération doit être reconnue comme incorrecte et tout doit être annulé, etc.etc. Bienvenue dans le monde réel ))))
Il n'y a pas d'incertitudes. Il y a des erreurs d'un programmeur qui n'a pas pris quelque chose en compte.
"Non connu", "dans un état imprécis" - ce sont des états à part entière, comme tous les autres. Il faut bien sûr les prendre en compte, sinon il n'y a pas d'autre solution.
Si vous écrivez la ligne "c = a + b", il s'agit d'une programmation théorique, qui n'est acceptable que dans les cours scolaires. Mais lorsque vous programmez une véritable installation industrielle, une opération utile comme "c = a + b" nécessite 100500 opérations de vérification pour confirmer qu'une entrée est bien "a", qu'une autre entrée est bien "b", et vous devez également vous assurer que "a" et "b" n'ont pas changé pendant l'addition, et si soudainement "c" n'atteint pas la sortie, l'opération doit être reconnue comme incorrecte et tout doit être annulé, etc.etc. Bienvenue dans le monde réel )))).
C'est une bonne analogie. )) Mais avec tout cela, il ne faut pas oublier qu'il est de toute façon impossible de rendre compte de tout. Même la nature fait des erreurs et rate ses erreurs sous forme de mutations. Mais il faut viser la perfection, bien sûr. ))
La nature ne fait pas d'erreurs, parce qu'elle s'en moque. C'est nous qui élaborons des théories justificatives.
Et la nature est une chose inconsciente, et donc ne suit pas qui a raison et qui est coupable.
...
Et la nature est inconsciente et donc...