Erreurs, bugs, questions - page 1129
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
La limite pour le type datetime n'est tout simplement pas définie correctement :
Le compilateur traite le nombre 13,7 comme le type double. Mais en même temps, ce nombre peut être converti sans perte en type flottant.
et cet avertissement est inutile.
Comment savez-vous que le nombre réel 13,7 peut être converti en type flottant sans pertes ?
N'est-ce pas ? Le nombre 13,7 = 0,137*1e+2. En convertissant trois décimales en type float, y a-t-il une perte ? D'après ce que j'ai vu, la précision est perdue lorsque vous essayez de convertir
des nombres avec six décimales ou plus.
J'ai essayé d'utiliser le type float pour enregistrer des guillemets de caractères à cinq chiffres (par exemple 1,38829) dans un fichier binaire. Après les avoir lues à partir du fichier et avoir essayé de les afficher sur un graphique en tant que
L'indicateur graphique appliqué aux chandeliers du graphique lui-même présente de petites divergences. Mais après la normalisation au cinquième chiffre, ils ont disparu.
Mais il y a eu une double perte de précision : on est d'abord passé du double au flottant, puis du flottant au double.
N'est-ce pas ? Le nombre 13,7 = 0,137*1e+2. En convertissant trois décimales en type float, y a-t-il une perte ? D'après ce que j'ai vu, on perd en précision lorsqu'on essaie de convertir
des nombres avec six décimales ou plus.
J'ai essayé d'utiliser le type float pour enregistrer des guillemets de caractères à cinq chiffres (par exemple 1,38829) dans un fichier binaire. Après les avoir lues à partir du fichier et avoir essayé de les afficher sur un graphique en tant que
L'indicateur graphique appliqué aux chandeliers du graphique lui-même présente de petites divergences. Mais après la normalisation au cinquième chiffre, ils ont disparu.
Mais il y a eu une double perte de précision : d'abord du double au flottant, puis de nouveau du flottant au double.
Non. C'est une fraction sans fin. Nous avons écrit et écrit et vous ne lisez pas.
On lit! Mais la perte se produit "techniquement" (particularités du format) et dans ces fractions qui ne sont même pas nécessaires.
J'ai eu ce problème aussi. Se produit lors de l'exécution d'un script si le terminal (910) et le compilateur (921) ne correspondent pas.
Voici le code
Compilateur 930, Terminal 910. Résultat :
Voici le code
Compilateur 930, Terminal 910. Résultat :
Comment se fait-il que le terminal soit à 910 et le compilateur à 930 ?
Si les deux sont 910, alors ce script ne "plante" pas.
Pas un seul terminal (je ne sais pas exactement, mais je pense que c'est courant sur le marché).
Je peux partager l'original depuis le dossier ...\MQL5\Scripts.
Pas un seul terminal (je ne sais pas exactement, mais je pense que c'est courant sur le marché).
Je peux partager l'original depuis le dossier ...\MQL5\Scripts.
Eh bien, c'est ce que j'ai dû prouverWin XP 32 bit: