Erreurs, bugs, questions - page 221

Nouveau commentaire
 
vikulin:

c'est le même résultat ! les paramètres d'entrée pour ces points sont les mêmes !

Veuillez expliquer. Je ne comprends pas l'expression "les paramètres d'entrée de ces points sont les mêmes". D'après ce que je comprends du fonctionnement de l'optimiseur, chaque passage correspond à un ensemble unique de paramètres d'entrée. Ou voulez-vous dire qu'en utilisant l'algorithme génétique, il peut y avoir des situations où un ensemble unique de paramètres d'entrée peut être traité plusieurs fois par l'optimiseur ?

...Eh bien, oui, c'est exactement ce que vous dites. Il s'avère ensuite que tous les points ultérieurs "issus du cache" ne sont qu'une fiction, faussant la perception visuelle des résultats de l'optimisation ?

 
sultanm:

Étrange. C'est la troisième fois. Il y a deux points sur le graphique qui sont proches en valeur, mais il n'y en a qu'un seul dans les résultats.

Conseil : veuillez trier par la valeur demandée, et n'oubliez pas d'afficher la barre de défilement verticale du tableau.

 

Ce problème sera-t-il jamais résolu ???

C'est la troisième fois que j'en parle et il n'y a aucune réaction !


 
vikulin:


Au fait, il me semble que si la modélisation des requêtes est sélectionnée, alors ce cache ne devrait pas être utilisé. qu'en pensent les développeurs ?

et un autre bug: lorsque mon algorithme génétique est allé au-delà de 10496, le graphique a commencé à s'afficher de manière incorrecte - verticalement, il a été mis à l'échelle correctement, vous pouvez comprendre que des résultats plus élevés ont été trouvés, mais horizontalement, il n'a pas été mis à jour. les points comme s'ils ont été ajoutés quelque part sur la droite, déjà en dehors du graphique.

Veuillez écrire à servicedesk. Et dans le point 2 est intéressé par l'information complète. EA, construction du terminal, paramètres d'optimisation...
 
Code :
int symbols = SymbolsTotal(false);
for (int i=0; i<symbols; i++) {
   Print("Символ №"+i+" значение="+SymbolName(i,false));
}

Dans le terminal, le résultat

2010.12.06 13:18:49   Expert (EURUSD,H1)    Символ №11 значение=GBPJPY
2010.12.06 13:18:49   Expert (EURUSD,H1)    Символ №10 значение=GBPCHF
2010.12.06 13:18:49   Expert (EURUSD,H1)    Символ №9 значение=EURJPY
2010.12.06 13:18:49   Expert (EURUSD,H1)    Символ №8 значение=EURCHF
2010.12.06 13:18:49   Expert (EURUSD,H1)    Символ №7 значение=EURAUD
2010.12.06 13:18:49   Expert (EURUSD,H1)    Символ №6 значение=EURGBP
2010.12.06 13:18:49   Expert (EURUSD,H1)    Символ №5 значение=AUDUSD
2010.12.06 13:18:49   Expert (EURUSD,H1)    Символ №4 значение=USDCAD
2010.12.06 13:18:49   Expert (EURUSD,H1)    Символ №3 значение=USDJPY
2010.12.06 13:18:49   Expert (EURUSD,H1)    Символ №2 значение=USDCHF
2010.12.06 13:18:49   Expert (EURUSD,H1)    Символ №1 значение=GBPUSD
2010.12.06 13:18:49   Expert (EURUSD,H1)    Символ №0 значение=EURUSD

Résultat dans le testeur :

2010.12.06 13:21:20     Core 1  2010.11.01 00:00:00   Символ №11 значение=USDJPY
2010.12.06 13:21:20     Core 1  2010.11.01 00:00:00   Символ №10 значение=USDCHF
2010.12.06 13:21:20     Core 1  2010.11.01 00:00:00   Символ №9 значение=USDCAD
2010.12.06 13:21:20     Core 1  2010.11.01 00:00:00   Символ №8 значение=GBPUSD
2010.12.06 13:21:20     Core 1  2010.11.01 00:00:00   Символ №7 значение=GBPJPY
2010.12.06 13:21:20     Core 1  2010.11.01 00:00:00   Символ №6 значение=GBPCHF
2010.12.06 13:21:20     Core 1  2010.11.01 00:00:00   Символ №5 значение=EURUSD
2010.12.06 13:21:20     Core 1  2010.11.01 00:00:00   Символ №4 значение=EURJPY
2010.12.06 13:21:20     Core 1  2010.11.01 00:00:00   Символ №3 значение=EURGBP
2010.12.06 13:21:20     Core 1  2010.11.01 00:00:00   Символ №2 значение=EURCHF
2010.12.06 13:21:20     Core 1  2010.11.01 00:00:00   Символ №1 значение=EURAUD
2010.12.06 13:21:20     Core 1  2010.11.01 00:00:00   Символ №0 значение=AUDUSD

Toute la beauté de la fonction SymbolName(i) est perdue.

 
vyv:

Une demande aux développeurs. Bien que le travail sur MT5 soit en pleine ébullition et que des modifications soient encore apportées, il serait très agréable d'augmenter le nombre de passes d'optimisation.

D'après ce que j'ai compris, la solution pour un si grand nombre de tâches est trouvée pour environ 10 000 variantes ; peut-être un peu plus ou un peu moins. Quelques heures de recherche sur un processeur et les meilleures variantes ont été trouvées.

La polyvalence des tests MQL5+OP+Multicore nous permet d'envisager de nouveaux horizons de tâches (par exemple, la recherche de modèles) qui peuvent être résolues à l'aide des outils MT5.

Mais voilà le problème :

L'article publié sur votre site présente un exemple d'algorithme génétique https://www.mql5.com/ru/articles/55 où il a fallu 3^100 avances par force brute pour résoudre un problème de recherche sur 100 barres - eh bien c'est un peu plus que LongInt :) alors que la solution a été trouvée en 17 000 itérations. L'algorithme génétique peut trouver des solutions pour beaucoup plus de variantes que LongInt. Et cette limitation est totalement infondée et obsolète. Eh bien, sauf qu'à ce stade final de MT5, il sera difficile de le faire.

Une très grande demande aux développeurs, si ce n'est pas trop difficile, faites en sorte que le nombre de passes soit au moins 2^LongInt (2 à la puissance).

Quelqu'un peut-il me donner une réponse ?
 

Code :

//+------------------------------------------------------------------+
//|                                                      testInd.mq5 |
//|                                                                  |
//|                                              https://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright ""
#property link      "https://www.mql5.com"
#property version   "1.00"
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
//---
   
   int handle1 = iMA(NULL,0,17,0,MODE_LWMA, PRICE_CLOSE); //
   int handle2 = iMA(NULL,0,17,0,MODE_LWMA, PRICE_CLOSE); //абсолютно идентичные параметры
   if(handle1 == INVALID_HANDLE) {
                Print("Error Creating Handles for indicators",GetLastError());
        } else {
                Print("Handle1 ="+handle1);
        }
        if(handle2 == INVALID_HANDLE) {
                Print("Error Creating Handles for indicators",GetLastError());
        } else {
                Print("Handle2 ="+handle2);
        }
        
   IndicatorRelease(handle2);
   handle2 = INVALID_HANDLE; //добавил для "надежности"
   handle2 = iMA(NULL,0,33,0,MODE_LWMA, PRICE_CLOSE); //другой период
        if(handle2 == INVALID_HANDLE) {
                Print("Error Creating Handles for indicators",GetLastError());
        } else {
                Print("Измененный? Handle2 ="+handle2); //все обращения к данным handle2 возвращают данные с handle1
        }
   
   
//---
   return(0);
  }

Journal :

2010.12.06 18:07:52:52 testInd (EURUSD,H1) Modifié ? Handle2 =10
2010.12.06 18:07:52 testInd (EURUSD,H1) Handle2 =10
2010.12.06 18:07:52 testInd (EURUSD,H1) Handle1 =10

Par conséquent, tous les appels de données à handle2 sont équivalents aux appels à handle1, malgré la période modifiée.

Lorsque l'Expert Advisor est en cours d'exécution, il est possible de créer des indicateurs avec les mêmes caractéristiques et une telle optimisation pour une poignée est raisonnable, mais un tel "collage" d'une poignée à une variable est très ennuyeux.

P.S. J'ai trouvé la raison. Ce bogue est une conséquence de l'optimisation à un seul numéro de manche.

IndicatorRelease(handle2); //уменьшает счетчик хендлов на единицу и в итоге следующий созданный хэндл(с любой переменной) - опять 10
 
Vigor:

Code :

Journal :

2010.12.06 18:07:52 testInd (EURUSD,H1) Modifié ? Poignée2 =10
2010.12.06 18:07:52 testInd (EURUSD,H1) Handle2 =10
2010.12.06 18:07:52 testInd (EURUSD,H1) Poignée1 =10

Par conséquent, tous les appels à la poignée 2 sont égaux aux appels à la poignée 1, bien que la période soit modifiée.

Lors du fonctionnement d'un EA, on ne peut pas exclure la création d'indicateurs ayant les mêmes caractéristiques, et une telle optimisation pour une poignée est raisonnable, mais un tel "collage" d'une poignée à une variable est très gênant.

P.S. J'ai trouvé la raison. Il s'agit d'un bogue - la conséquence de l'optimisation à un seul numéro de manche.

Qu'est-ce qui vous fait penser que c'est un bug ?

 
alexvd:

Qu'est-ce qui vous fait penser que c'est un bug ?

Bien. Il s'agit d'une fonctionnalité. Mais un que vous devriez connaître mieux.

Si un utilisateur saisit des valeurs de période pour MA à partir de l'interface, crée des handles pour les indicateurs et utilise les valeurs des buffers d'indicateurs, puis ayant créé (par exemple, j'ai des paramètres par défaut dans ce formulaire) 2 indicateurs avec les mêmes caractéristiques (leurs handles sont stockés dans le wrapper d'objet), il/elle reçoit le numéro de handle du premier indicateur, grâce à cette fonctionnalité.

Voici un enchaînement possible des événements.

Situation 1. Il supprime le premier indicateur (et le programme effectue IndicatorRelease) ; en conséquence, le deuxième indicateur ne fonctionne pas automatiquement - erreur de copie de tampon.

Situation 2. Il enlève le deuxième indicateur (et le programme fait IndicatorRelease), le compteur de longueur de main diminue. Le premier se porte bien. Il crée un troisième indicateur avec une période différente. Il reçoit le handle count+1, c'est-à-dire le numéro du handle de l'indicateur qui vient d'être supprimé. Finalement, le pire est que le troisième indicateur avec une période différente, créé avec succès, donne les valeurs du premier indicateur, toujours non supprimé, au tampon.

La fonction de collage des numéros de manche entraîne des situations ambiguës lorsque l'on supprime l'un des deux numéros collés pour en créer de nouveaux.

//+------------------------------------------------------------------+
//|                                                      testInd.mq5 |
//|                                                                  |
//|                                              http://www.mql5.com |
//+------------------------------------------------------------------+
#property copyright ""
#property link      "http://www.mql5.com"
#property version   "1.00"
//+------------------------------------------------------------------+
//| Expert initialization function                                   |
//+------------------------------------------------------------------+
int OnInit()
  {
//---
   
   int handle1 = iMA(NULL,0,17,0,MODE_LWMA, PRICE_CLOSE); //
   int handle2 = iMA(NULL,0,17,0,MODE_LWMA, PRICE_CLOSE); //абсолютно идентичные параметры
   if(handle1 == INVALID_HANDLE) {
                Print("Error Creating Handles for indicators",GetLastError());
        } else {
                Print("Handle1 ="+handle1);
        }
        if(handle2 == INVALID_HANDLE) {
                Print("Error Creating Handles for indicators",GetLastError());
        } else {
                Print("Handle2 ="+handle2);
        }
        
   IndicatorRelease(handle2);

   handle3 = iMA(NULL,0,33,0,MODE_LWMA, PRICE_CLOSE); //другой период
        if(handle3 == INVALID_HANDLE) {
                Print("Error Creating Handles for indicators",GetLastError());
        } else {
                Print("Новый handle3 ="+handle3); //все обращения к данным handle3 возвращают данные с handle1
        }
   
   
//---
   return(0);
  }
 
vyv:
Quelqu'un peut-il répondre à cette question pour moi ?

On en a déjà parlé ici.https://www.mql5.com/ru/forum/1997/page6/#comment_31644

Il serait peut-être préférable de déplacer la question à cet endroit - une suggestion.

Оптимизация в Тестере стратегий
Оптимизация в Тестере стратегий
  • www.mql5.com
из которых ТОЛЬКО 546 ms было затрачено именно на тестирование эксперта.
1...214215216217218219220221222223224225226227228...3184
Nouveau commentaire