Erreurs, bugs, questions - page 1998
Vous manquez des opportunités de trading :
- Applications de trading gratuites
- Plus de 8 000 signaux à copier
- Actualités économiques pour explorer les marchés financiers
Inscription
Se connecter
Vous acceptez la politique du site Web et les conditions d'utilisation
Si vous n'avez pas de compte, veuillez vous inscrire
Mais un tableau personnalisé... Le tableau est déclaré pour des données autres que zéro et EMPTY_VALUE. Alors quel est le but de l'initialiser de force avec quelque chose ?
Pour avoir moins de "les résultats du testeur ne correspondent pas".
Pour que ce soit moins "les résultats des testeurs ne correspondent pas".
Qui en a besoin ?
Ecrivez un article qui dit dans chaque paragraphe qu'il ne faut pas commander des EAs à n'importe qui. Vous devez écrire vos EAs correctement.
Qui en a besoin ?
Moi et, j'en suis presque sûr, les développeurs.
Pour moi et, j'en suis sûr, pour les développeurs.
Je doute fort qu'une telle bagatelle vous mette dans l'embarras. Soit ça, soit il y a une autre raison.
Je doute fort qu'une chose aussi triviale puisse vous laisser de marbre. Soit la raison est autre.
Même si j'ai écrit parfaitement (sans faire de fautes - ce qui n'est pas le cas), il est normal de prendre la bibliothèque de quelqu'un (parfois sans code source - sur le Marché) et de l'utiliser, en espérant qu'elle soit écrite de manière compétente. Et il n'y a aucune assurance qu'après cela, vous obtiendrez des résultats différents dans le testeur. Et trouver la véritable cause sera TRÈS difficile. Et le réparer est parfois impossible.
L'objectif est que, d'une exécution à l'autre, le résultat soit reproductible - identique, même en cas d'erreur.
La solution idéale serait probablement de forcer l'initialisation de tous les programmes par défaut + un commutateur de compilation pour la désactiver (pour ceux qui sont confiants et veulent accélérer de quelques pourcents).
L'initialisation prend vraiment beaucoup de ressources. J'ai jeté un morceau de code avec initialisation forcée et j'ai obtenu presque 2 fois plus vite en optimisation)
Et je suis tombé sur une chose intéressante. Comment est-il possible que le drawdown soit de 120% et qu'en même temps le résultat soit dans le haut et le plus ?
Lorsque je teste la stratégie, j'obtiens un drawdown de 109% et aucun appel de marge, alors que le solde continue de croître.L'initialisation prend vraiment beaucoup de ressources. J'ai jeté un morceau de code avec initialisation forcée - cela a accéléré l'optimisation de presque 2 fois)
Quelque chose que vous avez mal écrit.
Une initialisation complète n'est pas toujours nécessaire. Par exemple, pour un indicateur qui remplit la valeur du tampon pour chaque barre dans la boucle (et le fait indépendamment du fait que le tampon de l'indicateur soit initialisé ou non).
Dans ce cas, il sera plus économique sans mise à zéro forcée.
Et pourquoi inventer des scénarios aussi irréalistes, en fait des erreurs de programmeur MQL ? Évidemment, l'initialisation complète n'est effectuée qu'une seule fois, ou lorsque le pompage des données est détecté. Dans ce cas, il serait plus efficace que ce soit le noyau qui s'en charge.
Prenons l'exemple du tableau tampon de l'indicateur : lors de l'initialisation d'un indicateur, le tampon a une longueur nulle. Qu'y a-t-il à initialiser avec des zéros ? Lorsqu'un autre indice est ajouté, est-il obligé d'être mis à zéro puis rempli avec une valeur quelconque ? À quoi sert cette mise à zéro ou ce remplissage avec EMPTY_VALUE? Et s'il y a un besoin d'assigner PLOT_EMPTY_VALUE et non 0 ou EMPTY_VALUE ou de forcer un, mais nous avons besoin d'un autre... Peu importe comment on le découpe, on finit par perdre son temps...
Et un tableau personnalisé... Le tableau est déclaré pour des données différentes de zéro et EMPTY_VALUE. Alors quel est le but de l'initialiser de force avec quelque chose ?
Il s'avère donc que les performances sont affectées dans la plupart des cas.
Je suis manifestement déconnecté de la vie. À mon avis, le tampon de l'indicateur a toujours une longueur égale au nombre de barres. Et le refus de son initialisation dans MT5 entraîne l'affichage de déchets à l'écran. Il s'avère que l'initialisation explicite est obligatoire. Et il n'est pas clair pourquoi il est simplement transféré du noyau (comme il l'était dans MT4) au programmeur MQL. Je n'ai pas vu d'arguments concrets pour dire qu'il est possible d'accélérer sans initialisation et d'obtenir quand même l'affichage dégoûtant.
Je ne dis rien à propos d'un tableau dynamique personnalisé - il y a vraiment une règle : celui qui l'a alloué, est responsable de son nettoyage correct. ArrayInitialize est utile dans de nombreux cas. Ce n'est pas une question de vitesse, mais de justesse du programme. Priorité : rapide et/ou correcte. En général, certains contrôles d'exactitude et de préparation des données nécessitent un temps supplémentaire (même s'il est minime), mais vous ne pouvez pas vous en passer - les miracles n'arrivent jamais.