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 3

Nouveau commentaire
 
Rorschach:

"3. j'étais curieux et je voulais entendre le bruit blanc de vraies tiques, et j'ai pu le faire en utilisant le logiciel WaveLab 6.0".

Hee. Il s'avère que je ne suis pas le seul cinglé dans ce cas))))) Voici ce que j'ai obtenu. Je l'ai fait par l'intermédiaire d'Adobe Audience.

Comment avez-vous normalisé le prix ?

Comme d'habitude, en coupant les longues queues, tout ce qui dépasse 3*sko est ramené à cette valeur.
 

Une cargaison d'émotions

1) Beaucoup de bukaf, rien...

2) En regardant cela, on commence à comprendre pourquoi les Américains sont sur Mars et pas nous.

3) Je préfère garder le silence sur le reste (pour les émotions seulement).

 

J'ai bien aimé l'article, notamment en ce qui concerne les pratiques modernes de développement et de documentation des programmes. C'est ainsi que les choses se passent.

Bien sûr, l'article aurait dû montrer au moins le Conseiller Expert le plus simple basé sur la méthode des automates. Ou est-ce prévu pour le prochain article ?

A mon avis, la méthode des automates présente un gros problème. Pour les vrais conseillers experts, il est impossible de définir l'état sans ambiguïté. L'état du conseiller expert est déterminé par certaines variables internes sur l'ordinateur de l'utilisateur et par l'état des positions (taux actuel, capitaux propres, exécution des ordres) sur le serveur. L'état interne est déterminé sans ambiguïté, mais l'état des positions sur le serveur peut ne pas être connu, être connu avec un retard, être dans un état incertain (certains ordres et demandes sont exécutés, d'autres non, et personne ne sait pourquoi).

Et comme l'état actuel du conseiller n'est pas connu, que les ordres et les demandes ne sont pas exécutés, il est impossible de construire une logique claire d'automates. En réalité, nous obtenons cet algorithme :

comp : Achetez-moi quelques centaines d'euros, serveur.

Serveur : Va te faire foutre, comp, tes stops dans la requête sont erronés.

comp : Pourquoi sont-ils erronés ?

Serveur : Le prix a donc augmenté.

Comp : Bien, alors achète sans stop.

Le serveur reste silencieux.

comp : Eh bien, qu'as-tu acheté ?

Le serveur est silencieux

comp : Eh bien, va te faire foutre. Faisons une sieste de huit minutes.

Comp dans huit minutes : comment ça se passe ?

Serveur : J'ai acheté des eurobucks, mais pendant que j'achetais, le prix est parti ailleurs.

comp : On s'en fout. Faisons encore une heure de sieste.

Et ainsi de suite.

 
l'évolution tourne en rond - il est temps de revenir aux automates (non) finis, puis nous construirons des machines de Turing.
 
Virty:

...

Et un gros problème de la méthode des automates, à mon avis. Pour les vrais conseillers experts, il est impossible de définir l'état sans ambiguïté. L'état du conseiller expert est déterminé par certaines variables internes sur l'ordinateur de l'utilisateur et par l'état des positions (taux actuel, capitaux propres, exécution des ordres) sur le serveur. L'état interne est déterminé sans ambiguïté, mais l'état des positions sur le serveur peut ne pas être connu, être 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).

Eh bien, puisque l'état actuel de l'EA n'est pas connu, que les ordres et les demandes ne sont pas exécutés, il est impossible de construire une logique claire d'automates.

...

C'est quelque chose de nouveau. N'IMPORTE QUELLE TS (sans exception) est construite 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'EA n'est pas clairement connu", alors ce n'est certainement pas un EA, et certainement pas un programme, et le mot "algorithme" en relation avec un EA devrait être rayé et oublié pour toujours.

 

Beaucoup d'émotion.

Je propose d'orienter la discussion dans un sens pratique. Analysons un algorithme concret basé sur la théorie des automates finis. Discutons de ses forces et de ses faiblesses. Je n'écris pas moi-même selon cette méthode, mais je connais un peu la question et les algorithmes, et je vais donc esquisser le principe général de ce contrôle :

//СХЕМА + ПСВЕДОКОД
enum eTradeState {NoTradeRegim, BuyRegim, SellRegim, WaitRegim};
eTradeState TradeState = eTradeState.NoTradeRegim;
int Trade()
{
   switch (TradeState)
   {
       case eTradeState.NoTradeRegim:
          NoTradeRegim();
          break;
       case eTradeState.WaitRegim:
          WaitRegim();
          break;
       case eTradeState.SellRegim:
          SellRegim();
          break;
       case eTradeState.BuyRegim:
          BuyRegim();
          break;
   }
}
//Nous décrivons ici les conditions dans lesquelles le conseiller expert commencera à travailler. Par exemple
void NoTradeRgim()
{
   /Le pseudo-code suivant suit. 
   if(CurrentDay == WorksDays && Market.Enable = true)
      TradeState = eTradeState.WaitRegim;
}
//Ici, nous recevons des signaux pour entrer dans une position longue ou courte.
void WaitRegim()
{
   if(CheckForNoTrade() == true)
   {
      TradeState = eTradeState.NoTradeRegim;
   }
   if(CheckForBuy() == true)
   {
      BuyAtStop(...)
      TradeState = eTradeState.BuyRegim;
   }
   if(CheckForSell() == true)
   {
      SellAtStop(...);
      TradeState = eTradeState.SellRegim;
   }
}
//Dans cette fonction, nous accompagnons une longue affaire
void BuyRegim()
{
   //Écrivez ici les conditions dans lesquelles la transaction est clôturée, ou son stop loss ou d'autres paramètres sont modifiés, etc.
   if(StopLossChanged() == true)
      NewStop = ...;
   if(profit >= takeprofit)
   {
      CloseDeal(...);
      TradeState = eTradeState.WaitRegim;
   }

}
//Dans cette fonction, nous accompagnons une transaction à découvert
void SellRegim()
{
   //Écrivez ici les conditions dans lesquelles la transaction est clôturée, ou son stop loss est déplacé, etc.
   if(StopLossChanged() == true)
      NewStop = ...;
   if(profit >= takeprofit)
   {
      CloseDeal(...);
      TradeState = eTradeState.WaitRegim;
   }

}

La description est schématique, mais je pense que l'idée de base est claire. A chaque instant, l'Expert Advisor n'a qu'un seul état (mode hors marché, mode attente de signal, mode achat, mode vente). Dans chaque état, il existe un certain nombre d'actions et de conditions qui permettent de passer de l'état actuel à un autre. L'idée est que nous contrôlons clairement chacun des états et que, par conséquent, la logique interne est strictement localisée et que des erreurs logiques telles que la fermeture d'une transaction inexistante ou déjà fermée ne peuvent tout simplement pas se produire.

Je n'écris pas moi-même avec cette technique, car je pense qu'elle ne convient pas à tous les algorithmes. Mais elle résout tout de même certaines tâches mieux que l'approche classique.

Qu'en pensent les experts ?

 
C-4:
...

Je n'écris pas moi-même avec cette technique, je pense qu'elle n'est pas adaptée à tous les algorithmes. Néanmoins, elle résout certains problèmes mieux que l'approche classique.

Qu'en pensent les experts ?

Et puis-je vous demander ce que vous entendez par "approche classique" ?

Car chacun a sa propre vision de la réalité.

 
Urain:

Puis-je vous demander ce que vous entendez par "approche classique" ?

Parce que chacun a son propre reflet de la réalité.

J'ai dû mal m'exprimer. Bien sûr, chacun écrit à sa manière. Je parlais de la plupart des approches lorsque l'état du système à chaque étape n'est pas clairement défini. Il doit être déterminé non seulement pendant l'exécution du conseiller expert. L'exemple le plus simple est le code écrit en un seul bloc OnTick(). Aucun mode n'est analysé. Le choix d'une solution se fait sur la base d'un bloc de branchements if(...).
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
Документация по MQL5: Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров
  • www.mql5.com
Стандартные константы, перечисления и структуры / Торговые константы / Свойства ордеров - Документация по MQL5
 
C-4:
Je faisais référence à la plupart des approches dans lesquelles l'état du système à chaque étape n'est pas clairement défini. Il doit être déterminé au moment de l 'exécution de l' EE.

Si l'état n'est "pas clairement défini", comment définir ce qui n'est "pas clairement défini" ? Dans le cas d'un travail avec des ordres/positions, n'est-il pas nécessaire que l'EA comprenne à chaque tick l'état dans lequel il se trouve ? Ou bien l'EA se trouve-t-il à chaque tick dans un "état non défini". Quel est le type d'EA qui ne sait pas ce qu'il doit faire à chaque tic-tac ?

 

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.

1234567
Nouveau commentaire