Caractéristiques du langage mql5, subtilités et techniques - page 235
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
Si cela ne fonctionne plus, il serait bon de savoir si c'est correct.
Si vous utilisez des pointeurs au lieu d'objets, l'ancienne version fonctionnera également.
S'il a cessé de fonctionner, il est bon de savoir si c'est la bonne chose à faire.
Si vous utilisez des pointeurs au lieu d'objets, l'ancienne version fonctionnera également.
Excellente remarque et merci pour l'astuce !
Oui, en effet, la situation est parfaitement résolue avec un pointeur :
Les amateurs d'algorithmes rapides. Ceux qui se battent pour les nanosecondes :)
Tâche : Trouver l'heure d'ouverture de la barre en fonction de l'heure et de la TF données, quand on sait que la barre existe à cet instant. Par exemple, en fonction de l'heure d'ouverture et de fermeture des positions.
La plupart des programmeurs utiliseront une combinaison de iTime et iBarShift. Il s'agit de l'implémentation la plus lente, en particulier parce qu'elle nécessite un historique à jour des données téléchargées ou des tableaux combinés. De plus, cette approche peut générer des erreurs si l'historique requis n'est pas disponible.
Les programmeurs plus avancés résoudront ce problème en utilisant la structure MqlDateTime et la fonction TimeToStruct(). Cette solution n'est pas mauvaise et est suffisamment rapide.
Mais il existe une troisième solution, qui est plusieurs fois plus productive que la précédente :
La principale difficulté de cet algorithme est le calcul de l'heure du début du mois (surligné en vert). Il y a là de la magie, qui est le résultat du passage du simple au complexe. Le chemin inverse, du complexe au simple, sera beaucoup plus difficile à parcourir.
Le gain de performance est également fourni par l'algorithme qui récupère les secondes d'une barre à partir du TF au lieu de la fonction standard PeriodSeconds() - surligné en jaune.
Je joins un script de test qui calcule et compare les performances des trois méthodes :
La somme de contrôle avec iBarShift ne correspondra pas, car iBarShift travaille avec des barres réelles. La somme de contrôle ne coïncidera que sur les périodes MN1 et W1, car il n'y a pas de trous dans l'historique de ces barres.
Les performances seront plus élevées si vous utilisez un petit pas de temps dans la boucle (moins d'un jour) lorsque l'algorithme commence à travailler afin de sauvegarder les calculs précédents :
Les valeurs excessives pour l'algorithme via iBarShift (surlignées en bleu) sont dues à l'absence actuelle de l'historique nécessaire ou des TF calculés par le tableau, ce qui déclenche leur téléchargement.
Après le téléchargement, le résultat sera le suivant :
Les amateurs d'algorithmes rapides. Ceux qui se battent pour les nanosecondes :)
...😮😲😳🥴🤪
...
ah...
mmm....
oooh....
gkghm... Je ne pensais pas que ma simple question sortirait comme ça.
Juste comme ça. Oh.
😮😲😳🥴🤪
...
ah...
mmm.
ohhhh....
ahem. Je ne pensais pas que ma simple question prendrait une telle tournure.
Oh.
Oui, Artem, tu m'as trompé pendant un moment.
C'était un intérêt sportif.
J'espère que cela sera utile à quelqu'un, y compris à moi. :))
Oui, Artem, tu m'as trompé pendant un moment.
J'ai travaillé sur l'intérêt sportif.
J'espère qu'il sera utile à quelqu'un, et à moi entre autres. :))
Bien sûr que oui. C'est génial. Merci encore !
S.F. Cela m'a amusé : "ne compte correctement que jusqu'au 28.02.2100 ! !!!".
Que fait-on ensuite ?
Bien sûr qu'il sera utile. C'est très bien. Je vous remercie encore une fois !
S.F. Cela m'a amusé : "ne compte correctement que jusqu'au 28.02.2100 ! !!!".
Que fait-on ensuite ?
haha.
Je doute que cet algorithme soit encore demandé dans 75 ans. Les ordinateurs quantiques domineront probablement déjà le monde, avec une programmation complètement différente.
Pour être honnête, c'était paresseux de prendre en compte le calendrier grégorien. L'année 2000 était très importante, l'année 2100 ne l'est plus.
haha.
Je doute que cet algorithme soit demandé dans 75 ans. Les ordinateurs quantiques domineront probablement déjà le monde, avec une programmation complètement différente.
Pour être honnête, c'était paresseux de prendre en compte le calendrier grégorien dans son intégralité. L'année 2000 était très importante, l'année 2100 ne l'est plus.
Pour MN, vous pouvez utiliser un tableau pré-calculé, il n'y a presque rien dedans
Ln2(12 mois * cent ans)...11 if`s et comparaisons en recherche binaire, mais sans autres calculs.
Vous pouvez utiliser un tableau précalculé pour MN, il n'y a pratiquement pas de données.
Ln2(12 mois * cent ans)...11 if`s et comparaisons en recherche binaire, mais sans autres calculs.
Vous pouvez utiliser un tableau précalculé pour MN, il n'y a pratiquement pas de données.
Ln2(12 mois * cent ans)...11 if`s et comparaisons en recherche binaire, mais sans autres calculs.
Ah, j'ai mal lu au début.
Non, vous vous trompez. L'augmentation des performances ne fonctionnera pas. Vous serez toujours bloqué dans les calculs. Et l'accès aux éléments du tableau ralentit considérablement l'algorithme.