Pas pour les développeurs MT ! Par quoi remplacer INIT_PARAMETERS_INCORRECT ? - page 10

Nouveau commentaire
 
Aleksey Vyazmikin:

Les paramètres incorrects sont généralement désactivés pour 3 raisons :

1. la zone d'étude ne présente pas d'intérêt (par exemple, l'exclusion d'un certain nombre d'échéances est l'option la plus compréhensible) ;

//--- пропустить бесполезные проходы оптимизации
   if(my_timeframe != PERIOD_M15   &&
      my_timeframe != PERIOD_M30   &&
      my_timeframe != PERIOD_H1    &&
      my_timeframe != PERIOD_H3    &&
      my_timeframe != PERIOD_H6      )
   {
      Print("ОШИБКА - Период не запланирован");
      return(INIT_PARAMETERS_INCORRECT);
   }
 
Сергей Таболин:

Tout à fait exact.

 
Сергей Таболин:

Comment organiser l'optimisation MA de l'exemple sans inclure les paramètres "invalides" ?

OK, je suis d'accord, je n'ai pas bien regardé. pour optimiser un autre paramètre avec une découpe d'écart invalide

 
TheXpert:

OK, je suis d'accord, je ne l'ai pas regardé attentivement. Pour optimiser, faites sortir un autre paramètre avec l'écart invalide coupé.

Pouvez-vous me donner un exemple ?

 
Сергей Таболин:

Je peux vous donner un exemple ?

input int period_MA_warp = 15;

//...

period_MA = (period_MA_warp <= 31) ? period_MA_warp : period_MA_warp + 50;
 
TheXpert:

Je suis d'accord. Qu'en est-il du cas des délais ?

 
Сергей Таболин:

Je suis d'accord. Et que faire en cas d'échéances ?

De la même manière - conversion d'un int dans un intervalle continu en un intervalle de temps. Par exemple, créez un tableau avec toutes les valeurs de TF et optimisez par l'index du tableau.

 
TheXpert:

Par exemple, pour créer un tableau avec toutes les valeurs TF et l'optimiser par index de tableau

Eh bien, ça ressemble à une béquille pour moi... Je me trompe peut-être, mais c'est presque la même chose que ce que j'ai dû faire avec mon exemple de départ. Sauf que dans ce cas, vous n'avez pas besoin de vider le tableau entier dans un fichier au préalable...

 

Une idée est apparue pour éliminer les paramètres "invalides" pendant l'optimisation génétique dans OnTester() :

double OnTester()
{
   if(MQLInfoInteger(MQL_OPTIMIZATION) && paramIncorrect())  return(-99999999.99);
}

Il s'avère que sans interférer avec la génétique, les résultats de INIT_PARAMETERS_INCORRECT peuvent ne pas être vus.

Une autre question se pose ici : pouvons-nous obtenir un " deep minus " sur le bénéfice dans ce cas ?

 

La façon dont je l'ai fait : un paramètre séparé est créé et d'autres valeurs sont substituées en fonction de sa valeur.

Un exemple simple (il y a 2 semaines) :

Il y a des paramètres de timeframe : TF_UP (Senior) et TF_DOWN (Junior), et le Senior doit toujours être supérieur au Junior, dans le cas inverse l'input_incorrect sort. Dans le testeur, il y a beaucoup de résultats nuls et la génétique "fonctionne pour rien" (bien que ce soit rapide). En conséquence, j'ai supprimé ces 2 paramètres et créé un nouveau paramètre qui a le type décrit ci-dessous, et optimiser uniquement celui-ci, et déjà dans la fonction OnInit la substitution dans 2 autres paramètres, dépendant de ce paramètre.

enum TF_only_opt
{
   _H4_H1 = 0,
   _H4_M30 = 1,
   _H4_M15 = 2,
   _H1_M30 = 3,
   _H1_M15 = 4,
   _H1_M5 = 5,
   _M30_M15 = 6,
   _M30_M5 = 7,
   _M30_M1 = 8,
   _M15_M5 = 9,
   _M15_M1 = 10,
   _M5_M1 = 11
};
1...34567891011
Nouveau commentaire