Erreurs, bugs, questions - page 891

[A100]

Il est clair que la mise à zéro a été faite pour des raisons de compatibilité, mais il n'est pas clair pourquoi lorsque l'enum = WRONG_VALUE inutilisé est initialisé correctement , il ne fonctionne pas correctement. Cette approche manque de portabilité et augmente considérablement la probabilité d'erreurs cachées.

[Yedelkin]

A100: il n'est pas clair pourquoi lorsque l'enum = WRONG_VALUE non utilisé est initialisé correctement, il ne fonctionne pas correctement.

Vous vous souvenez de cette règle ?

Règle: Si une constante nommée - membre d'une énumération n'est pas explicitement assignée à une valeur spécifique, sa valeur sera générée automatiquement. S'il s'agit du premier membre de l'énumération, la valeur 0 sera attribuée. Pour tous les membres suivants, les valeurs seront calculées sur la base de la valeur du membre précédent en ajoutant un.

Très probablement, la vérification de l'exactitude des champs de la requête suppose que la valeur d'un membre de l'énumération ne peut pas être négative. La possibilité d'assigner WRONG_VALUE à un membre de l'énumération n' est pas prise en compte.

[A100]

Yedelkin:

Cependant, la possibilité d'attribuer WRONG_VALUE à un membre de l'énumération n' est pas prise en compte.

Je pense que c'est exactement l'erreur ici. Si un enum concret n'est pas utilisé, il est logique que sa valeur soit WRONG_VALUE au lieu de, par exemple, ORDER_TYPE_BUY qui est en fait = 0.

et surtout, rien ne vous empêche de modifier la logique de OrderCheck() et de OrderSend() tout en maintenant la compatibilité.

[Yedelkin]

A100: Je pense que c'est exactement l'erreur ici. Si un enum concret n'est pas utilisé, il est logique que sa valeur soit WRONG_VALUE au lieu de ORDER_TYPE_BUY qui en fait = 0.

et surtout, rien ne vous empêche de modifier la logique de OrderCheck() et OrderSend() tout en maintenant la compatibilité.

Il existe un moyen de comprendre l'opinion des développeurs : écrivez au Service Desk à propos de l'erreur.

[Lev Ilyukov]

J'ai découvert un étrange "bug".

J'utilise ce code dans mon EA :

void OnTradeTransaction(const MqlTradeTransaction &trans, const MqlTradeRequest &request, const MqlTradeResult &result)
  {
   if(trans.type == TRADE_TRANSACTION_DEAL_ADD)
    {
     if(trans.symbol == "EURUSD") EURUSD_K = 1;
    }    
  }

Une seule exécution dans le testeur passe sans problème, mais dès que je choisis des paramètres avec une recherche complète, le testeur commence à fonctionner dix ou dix fois plus lentement. Je ne comprends pas pourquoi la vitesse est adéquate lors d'une exécution et chute sensiblement lors de l'optimisation. De plus, elle diminue géométriquement. Vous pouvez voir par le pourcentage que tout va bien au début, mais que vers la fin, la vitesse diminue de plus en plus. J'ai cherché des problèmes dans mon code et j'ai cherché des boucles ou autre chose, mais je ne les ai pas trouvés. Après cela, j'ai remplacé le code mentionné ci-dessus par mon propre algorithme et oh mon dieu ! L'optimisation fonctionne maintenant à une vitesse normale et uniforme. Cela m'amène à la conclusion que le problème se situe dans MQL5, quelque part dans le corps de la fonction OnTradeTransaction. Je demanderai aux développeurs de faire attention à cela.

p.s. Je ne peux pas afficher le code du conseiller expert. Essayez d'utiliser le code ci-dessus dans l'un de vos EA et regardez la vitesse d'optimisation dans OHLC M5 pour la période de 2000 à aujourd'hui.

[Konstantin Chernov]

lordlev:

J'ai découvert un étrange "bug".

J'utilise ce code dans mon EA :

Une seule exécution dans le testeur passe sans problème, mais dès que je choisis des paramètres avec une recherche complète, le testeur commence à fonctionner dix ou dix fois plus lentement. Je ne comprends pas pourquoi la vitesse est adéquate lors d'une exécution et chute sensiblement lors de l'optimisation. De plus, elle diminue géométriquement. Vous pouvez voir par le pourcentage que tout va bien au début, mais que vers la fin, la vitesse diminue de plus en plus. J'ai cherché des problèmes dans mon code et j'ai cherché des boucles ou autre chose, mais je ne les ai pas trouvés. Après cela, j'ai remplacé le code mentionné ci-dessus par mon propre algorithme et oh mon dieu ! L'optimisation fonctionne maintenant à une vitesse normale et uniforme. Cela m'amène à la conclusion que le problème se situe dans MQL5, quelque part dans le corps de la fonction OnTradeTransaction. Je demanderai aux développeurs de faire attention à cela.

p.s. Je ne peux pas afficher le code du conseiller expert. Essayez d'utiliser le code ci-dessus dans l'un de vos EA et regardez la vitesse d'optimisation dans OHLC M5 pour la période de 2000 à aujourd'hui.

Avec différents paramètres, le conseiller expert peut fonctionner pendant une durée différente.

[Lev Ilyukov]

Konstantin83:
Pour différents paramètres, l'EE peut fonctionner pendant des durées différentes

Dans ce cas, le problème ne vient pas du conseiller expert ou des paramètres. Le problème se trouve dans MQL5 lui-même.

[A100]

lordlev:

Après avoir remplacé le code ci-dessus par votre algorithme

C'est-à-dire qu'ils ont renoncé à utiliser OnTradeTransaction()? - alors il est logique que la vitesse ait augmenté - elle est appelée à chaque occasion

[Lev Ilyukov]

A100:
C'est-à-dire qu'ils ont renoncé à utiliser OnTradeTransaction() ? - alors il est logique que la vitesse ait augmenté - elle est appelée à chaque occasion

Il est naturel de refuser de l'utiliser. Il est clair qu'il est appelé en toute occasion. Il n'est pas clair pourquoi la vitesse est adéquate lors d'une seule exécution, alors qu'elle chute dramatiquement lors de l'optimisation. Cela n'a rien à voir avec les paramètres eux-mêmes, comme un autre ami l'a écrit plus haut, je l'ai vérifié minutieusement dix fois. Cela m'amène à la conclusion que les développeurs ont fait une erreur quelque part.

[TheXpert]

lordlev:

Qu'est-ce qui vous empêche de réaliser un cas de test minimal et de faire un rapport au service d'assistance ?