Question aux maîtres du MQL4. Encore une fois à propos de Double Comparaison. - page 2
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
Prix, lots, argent - précision fixe.
Les indicateurs sont flottants.
Cette différence est essentielle, bien que le double soit utilisé pour représenter les deux. Il détermine en fait ce que vous appelez le "style de programmation".
Encore une fois, le critère de "justesse" est différent pour chacun. À ma connaissance, par exemple, NormalizeDouble() est une fonction ridiculement inefficace et, par conséquent, absolument inutile.
ne serait-il pas préférable de le remplacer par
Ou c'est faux ?
Le problème de la comparaison des chiffres en double précision est tiré par les cheveux et provient d'une ignorance fondamentale des mathématiques.
Soit vous donnez des instructions claires sur la façon de résoudre ce "problème", soit l'un des deux =)
Mais il y aura des problèmes de performance.
Des suggestions (au niveau de l'utilisateur, pas du développeur MT) ?
Il est souvent préférable de faire tous les calculs de lots et de niveaux en nombres entiers. Beaucoup plus rapide et sans erreur d'échantillonnage en principe.
Encore une fois.
Prix, lots, argent - précision fixe.
Les indicateurs sont flottants.
Cette différence est essentielle, bien que le double soit utilisé pour représenter les deux. Il détermine en fait ce que vous appelez le "style de programmation".
Encore une fois, le critère de "justesse" est différent pour chacun. À ma connaissance, par exemple, NormalizeDouble() est une fonction ridiculement inefficace et, par conséquent, absolument inutile.
Après cela, j'ai simplement adopté NormalizeDouble() comme procédure obligatoire. Je n'ai pas encore bien compris comment le code fonctionne parfois, c'est pourquoi je m'intéresse à la façon dont cela devrait être fait.
Et quelle approche suggérez-vous à la place de NormalizeDouble() ?
Des suggestions (au niveau de l'utilisateur, pas du développeur MT) ?
Il est souvent préférable de faire tous les calculs de lots et de niveaux en nombres entiers. Beaucoup plus rapide et sans erreur d'échantillonnage en principe.
P.S. Et votre ComparePrice est une solution très intéressante, je ne l'ai même pas compris tout de suite.
Encore une fois.
Prix, lots, argent - précision fixe.
Les indicateurs sont flottants.
Cette différence est essentielle, bien que le double soit utilisé pour représenter les deux. Il détermine en fait ce que vous appelez le "style de programmation".
Encore une fois, le critère de "justesse" est différent pour chacun. À ma connaissance, par exemple, NormalizeDouble() est une fonction ridiculement inefficace et, par conséquent, absolument inutile.
Tout d'abord, écrivez plusieurs Expert Advisors sur votre propre ordre et sentez la tempête de vos clients parce que le stop loss s'est soudainement avéré être faux d'un point... Et ensuite, expliquez-leur l'absurdité de la fonction NormalizeDouble(), je me demande comment cela va se passer pour vous=)
Et il s'avère que même le prix extrait du serveur de votre commande doit encore être normalisé ! !!
Il y a eu et il y a encore beaucoup de discussions sur les performances incompréhensibles de l'EA lorsqu'il est testé sur des données historiques incompréhensibles.
Pour le prix, par exemple. Enchérit, là, demande, arrête :
Si vous comparez les prix, vous n'avez pas besoin d'une fonction aussi surchargée que la mienne.
Et sous une forme simplifiée, il fonctionne aussi rapidement que ComparePrice :
Tout d'abord, écrivez quelques Expert Advisors sur votre propre ordre, sentez la tempête des clients parce que le stop-loss s'est soudainement avéré être 1 pip faux.... Et ensuite, expliquez-leur l'absurdité de la fonction NormalizeDouble(), je me demande comment cela va se passer pour vous=)
Laissez-moi vous dire un secret.
J'ai écrit beaucoup plus de conseillers-experts personnalisés que nécessaire pour commencer. Je n'ai jamais ressenti le besoin de les acheter car je n'ai jamais eu de raison de le faire. Dans mes programmes, le stoploss est garanti (et non pas "semble") là où il devrait être. Par conséquent, je n'ai pas à expliquer quoi que ce soit de ce genre au client, surtout en ce qui concerne une fonction très spécifique. Il me semble que le but de l'écriture d'une EE est de se débarrasser de ces questions et explications pour le client.