Erreurs, bugs, questions - page 432

[Renat Fatkhullin]

gumgum:

290 au total et... sur)

La surenchère totale fait 290.

Je suppose qu'il n'y a pas de passe (course réelle) mais qu'elle est fixée (s'il y a des matchs) ?

Puisque vous avez choisi un algorithme génétique, il construit son propre plan de croisement et sa propre population de sortie. L'algorithme d'optimisation génétique est décrit dans l'article correspondant.

Il est déraisonnable de faire de la génétique avec si peu (290) de passes. L'algorithme génétique doit être utilisé avec une énumération initiale d'au moins des dizaines de milliers, de préférence des millions/billions/trillions, de variantes.

[Andrew Petras]

Manuel de référence MQL5 - Bibliothèque standard - Classes pour l'organisation des données - CArrayObj (sur le site web et dans l'aide) :

2. Le mécanisme de gestion de la mémoire est désactivé.

Dans ce cas, CArrayObj n'est pas responsable de la libération de la mémoire.

[Andrey Vasiliev]

Renat:

Oui, il n'est pas nécessaire de tester à la date existante la plus récente.

Choisissez une date de fin fixe raisonnable sous la forme de 00:00 du jour ouvrable précédent, ou même la fin de la semaine ouvrable précédente. Si vous utilisez le dernier jour tout le temps, la fin du planning va flotter périodiquement, surtout si le processus de test est long en utilisant des agents distants ou clauds.

J'ai utilisé le dimanche comme date de fin. Où d'autre est-il raisonnable ? Il n'y a pas de commerce le dimanche. Qu'est-ce qui pourrait flotter là ?

[Vladimir Gomonov]

MoneyJinn:
J'ai utilisé le dimanche comme date de fin. Où d'autre cela aurait-il un sens ? Il n'y a pas de commerce le dimanche. Qu'est-ce qui pourrait flotter là ?

Alors peut-être que le problème se situe à l'autre bout de l'histoire. De quelle longueur d'historique avez-vous besoin pour que les indicateurs fonctionnent ? Au début des essais, il est garanti, si j'ai bien compris, une centaine de barres précédentes.

Si vous avez besoin de plus, vous devez sauter une partie de l'historique après le début du conseiller expert avec une longueur supérieure à[nombre_de_barres_nécessaire - 100]. Cela a résolu mes problèmes de corrélation entre les résultats du testeur et de l'optimiseur.

[Andrey Vasiliev]

MetaDriver:

Alors peut-être que le problème se situe à l'autre bout de l'histoire. De quelle longueur d'historique avez-vous besoin pour que les indicateurs fonctionnent ? Au début des essais, il est garanti, si j'ai bien compris, une centaine de barres précédentes.

Si vous avez besoin de plus, sautez un morceau d'histoire après le début du conseiller expert avec une longueur supérieure à[nombre_nécessaire_de_barres - 100]. Cela a résolu mes problèmes de correspondance entre les résultats du testeur et de l'optimiseur.

Merci, mais d'après les captures d'écran, nous pouvons voir que l'historique du vendredi (24.06.11) est perdu lors de l'optimisation par le réseau.

[[Supprimé]]

Pas une question cruciale, mais quand même. Concaténation de chaînes de caractères. La documentation décrit deux fonctions StringAdd et StringConcatenate.

La première dit :"La fonction StringAdd() est plus rapide et plus économe en mémoire que la concaténation de chaînes de caractères au moyen d'opérations d'addition.

Le second indique :" La fonction StringConcatenate() fonctionneplus rapidement et plus économiquement que la liaison de chaînes de caractères utilisant des opérations d'addition, du fait que les variables temporaires de type chaîne de caractères ne sont pas utilisées.

void OnStart() {
  string string1 = "sdfdsfjssdfads";
  string string2 = "bsadfasdfaaa";
  string string3 = "ssdfsdgasgsaggsda";
  string result;
  uint i, start, stop, length = 10000000;

  start = GetTickCount();
  for(i = 0; i < length; i++)
    result = string1 + string2 + string3;
  stop = GetTickCount();
  Print("№1 ", (stop-start), " milliseconds, i = ", i);
 
  start = GetTickCount();
  for(i = 0; i < length; i++) {
    StringAdd(result, string1);
    StringAdd(result, string2);
    StringAdd(result, string3);
  }
  stop = GetTickCount();
  Print("№2 ", (stop-start), " milliseconds, i = ", i);

  start = GetTickCount();
  for(i = 0; i < length; i++)
    StringConcatenate(result, string1, string2, string3);
  stop = GetTickCount();
  Print("№3 ", (stop-start), " milliseconds, i = ", i);
}

Résultat :

2011.06.26 19:10:55 test (EURUSD,H1)№1 2012 millisecondes, i = 10000000
2011.06.26 19:11:04 test (EURUSD,H1)#2 8269 millisecondes, i = 10000000
2011.06.26 19:11:10 test (EURUSD,H1)#3 6661 millisecondes, i = 10000000

Il s'avère cependant que l'addition habituelle est plus rapide.

[Yedelkin]

voix_kas:

Il s'avère cependant que l'addition normale est plus rapide.

La question s'est déjà posée : https://www.mql5.com/ru/forum/58/page13#comment_59630 Consultez la discussion plus loin dans le texte. Aux développeurs : la conclusion à tirer est qu'il y a un manque de couverture de cette question dans les matériaux de référence.

[Renat Fatkhullin]

MoneyJinn:
J'ai utilisé le dimanche comme date limite. Où d'autre est-il raisonnable ? Il n'y a pas de Torg le dimanche. Qu'est-ce qui pourrait flotter là-bas ?

Comme ce type de question nécessite des détails, créez un ticket dans le bureau de service avec plus de détails - nous essaierons de résoudre le problème.

Le problème, bien sûr, c'est l'histoire et sa synchronicité.

[Renat Fatkhullin]

voix_kas:

Pas une question cruciale, mais quand même. Concaténation de chaînes de caractères. La documentation décrit deux fonctions StringAdd et StringConcatenate.

La première dit :"La fonction StringAdd() est plus rapide et plus économe en mémoire que la concaténation de chaînes de caractères au moyen d'opérations d'addition.

Le second indique :" La fonction StringConcatenate() estplus rapide et plus économe en mémoire que la liaison de chaînes de caractères utilisant des opérations d'addition, car aucune variable temporaire de type chaîne de caractères n'est utilisée.

Résultat :

2011.06.26 19:10:55 test (EURUSD,H1)№1 2012 millisecondes, i = 10000000
2011.06.26 19:11:04 test (EURUSD,H1)#2 8269 millisecondes, i = 10000000
2011.06.26 19:11:10 test (EURUSD,H1)#3 6661 millisecondes, i = 10000000

Il s'avère cependant que l'addition normale est plus rapide.

Il semble s'agir d'une optimisation de la concaténation de chaînes de caractères avec +.

Le compilateur subit actuellement de sérieuses modifications concernant l'inclusion des modes d'optimisation attendus depuis longtemps. Nous montrerons les résultats dans quelque temps.

[[Supprimé]]

Renat:

Il semble que ce soit l'optimisation de la concaténation des chaînes avec + qui fonctionne.

Nous sommes en train de modifier sérieusement le compilateur afin d'activer les modes d'optimisation tant attendus. Nous vous montrerons les résultats dans un moment.

Je vois. Eh bien, si c'est possible vous le décrirez explicitement dans le forum (j'essaie de suivre tous les fils).

Jusqu'à présent, dans l'algorithme, j'ai laissé le travail "+".