Algorithmes, méthodes de résolution, comparaison de leurs performances - page 22

Nouveau commentaire
 

Mis à jour en 2269. Résultats du profileur d'une grande EA (non synthétique).


Testeur



Virtual


Probablement, le profileur fait de mauvaises mesures. Sinon, il s'avère que OrderSend five prend 912 ms en moyenne.

 

Tous les doublets normalisés par le même algorithme (par exemple via NormalizeDouble) peuvent être comparés entre eux directement.


Ce fait évident permet d'éviter les constructions coûteuses de comparaison de nombres réels dans de nombreux cas. Ce qui, dans certaines tâches, peut augmenter considérablement les performances.

L'une des tâches les plus exemplaires est peut-être celle de Testeur. Analysons-la par l'exemple.


Il y a une BuyLimit. A chaque tick, le testeur doit comparer la BuyLimit avec le prix Ask. Le testeur standard procède de cette manière pour le moment

if (NormalizeDouble(BuyLimit_Price - Ask , Symbol_Digits) >= 0)
  BuyLimit -> Buy;


C'est-à-dire que tout niveau de transaction(ordre en suspens ou SL/TP) déclenche une normalisation.


Mais nous pouvons toujours nous en sortir avec une construction de comparaison très efficace si les prix ont été normalisés au préalable (avant le backtest).

if (BuyLimit_Price >= Ask)
  BuyLimit -> Buy;


Essayons une comparaison. J'ai fait tourner ce robot dans Tester via Virtual.

#include <MT4Orders.mqh>

#define  VIRTUAL_TESTER // Запуск в виртуальном торговом окружении
#include <fxsaber\Virtual\Virtual.mqh>

#define  Ask SymbolInfoDouble(_Symbol, SYMBOL_ASK)

input int inAmountOrders = 10;
input int inFakeRange = 0;

void OnTick()
{
  static bool FirstRun = true;
  
  if (FirstRun)
  {
    for (int i = 0; i < inAmountOrders; i++)    
      OrderSend(_Symbol, OP_BUYLIMIT, 0.1, Ask - 10000 * _Point, 0, 0, 0);
      
    FirstRun = false;
  }
}


Comparaison des prix par la normalisation.

pass 0 returned result 100000.000000 in 0:00:01.578
pass 1 returned result 100000.000000 in 0:00:00.759
pass 2 returned result 100000.000000 in 0:00:00.894
pass 3 returned result 100000.000000 in 0:00:00.769
pass 4 returned result 100000.000000 in 0:00:00.806
pass 5 returned result 100000.000000 in 0:00:00.772
pass 6 returned result 100000.000000 in 0:00:01.253
pass 7 returned result 100000.000000 in 0:00:01.200
pass 8 returned result 100000.000000 in 0:00:01.089
pass 9 returned result 100000.000000 in 0:00:00.780
pass 10 returned result 100000.000000 in 0:00:01.258
optimization finished, total passes 11
optimization done in 0 minutes 11 seconds
shortest pass 0:00:00.759, longest pass 0:00:01.578, average pass 0:00:01.014


Sans normalisation.

pass 0 returned result 100000.000000 in 0:00:01.743
pass 1 returned result 100000.000000 in 0:00:00.844
pass 2 returned result 100000.000000 in 0:00:00.672
pass 3 returned result 100000.000000 in 0:00:00.817
pass 4 returned result 100000.000000 in 0:00:00.635
pass 5 returned result 100000.000000 in 0:00:00.604
pass 6 returned result 100000.000000 in 0:00:00.867
pass 7 returned result 100000.000000 in 0:00:00.611
pass 8 returned result 100000.000000 in 0:00:00.899
pass 9 returned result 100000.000000 in 0:00:00.649
pass 10 returned result 100000.000000 in 0:00:00.742
optimization finished, total passes 11
optimization done in 0 minutes 09 seconds
shortest pass 0:00:00.604, longest pass 0:00:01.743, average pass 0:00:00.825


Nous pouvons voir que le gain est supérieur à 20% si nous ne faisons pas de normalisation lors de la comparaison des prix.


Par conséquent, si le testeur interne passe aux prix normalisés et n'effectue pas de normalisation interne lors de la comparaison des prix, il est possible d'obtenir une sérieuse amélioration des performances.

 
Après une affectation directe sans opérations matricielles, également
 
TheXpert:
Après une affectation directe sans mat. les opérations

Le préfixe, bien sûr, copie la représentation en octet du nombre sans modification.

 

Devrions-nous effectuer un test de plus d'une seconde pour plus de clarté ?

Il y a un écart de 3 temps dans une version : passage le plus court 0:00:00.604, passage le plus long 0:00:01.743. Que comparons-nous ?

 
Andrey Khatimlianskii:

Peut-être faire un test de plus d'une seconde pour plus de clarté ?

Il y a un écart de 3 temps dans une version : passage le plus court 0:00:00.604, passage le plus long 0:00:01.743. Que comparons-nous ?

En comparant le plus court, bien sûr. J'ai l'habitude de courir sur des ticks filtrés. Je préparerai les non filtrés plus tard.

 
fxsaber:

En comparant le plus court, bien sûr.

Pourquoi ? L'optimisation ne consiste pas en un seul passage. Quelle différence cela fait-il qu'un passage soit si rapide, si la moyenne n'est pas très différente ?


fxsaber:

J'ai l'habitude de courir sur des ticks filtrés. Je préparerai les non filtrés plus tard.

Je peux juste faire un intervalle plus long. Au moins 30 secondes pour le test.

 
Andrey Khatimlianskii:

Pourquoi ? Ce n'est pas comme si l'optimisation consistait en un seul passage. Quelle différence cela fait-il qu'un passage soit si rapide, si la moyenne n'est pas très différente ?

Ce paramètre est optimisé.

input int inFakeRange = 0;

Et cela n'affecte pas la logique. C'est pourquoi il est le plus court.

 
fxsaber:

Ce paramètre est optimisé

Et cela n'affecte pas la logique. C'est pour ça que c'est le plus court.

Qu'est-ce que la logique d'EA a à voir avec ça ? Nous mesurons la vitesse du testeur.

 
Andrey Khatimlianskii:

Qu'est-ce que la logique de l'EA a à voir avec ça ? Nous mesurons la vitesse du testeur.

C'est ainsi qu'un agent fonctionne, il compte consécutivement la même chose. Si vous enlevez tout le caractère aléatoire, la performance nette est proche de la plus courte.

1...151617181920212223
Nouveau commentaire
Raison: