[ARCHIVE] Toute question de débutant, afin de ne pas encombrer le forum. Professionnels, ne passez pas à côté. Nulle part sans toi - 3. - page 248
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
ERR_INVALID_TRADE_VOLUME 131 Volume incorrect - apprenez à connaître ce formulaire et réglez le volume "correctement" en fonction de votre type de compte, par exemple dans les micro comptes le volume est généralement de 0,01 lot, dans les comptes "classiques" 0,1 lot... Entrez une valeur constante de 0,1 lot dans votre fonction d'ouverture d'ordre et vérifiez si le volume...
Avez-vous fait des tests en semaine ? Le spread est-il flottant ?
Pourquoi cette alerte apparaît-elle ? J'ai fait beaucoup d'efforts pour découvrir que lorsque je compare un chiffre avec une partie fractionnaire, je dois le normaliser avec NormalizeDouble(). Mais j'ai décidé de l'essayer pour le plaisir aujourd'hui et l'alerte est apparue ! Quel genre de problèmes ? Ou pas des pépins ?
L'EA trade avec un certain % de l'ekvit, c'est-à-dire que je ne peux entrer qu'un pourcentage, par exemple 10, 5, il n'y a pas d'option pour entrer un lot de 0.1 ou 0.01. Ce problème ne s'est produit qu'avec un courtier à 4 chiffres.
Pourquoi cette alerte apparaît-elle ? J'ai passé beaucoup de temps à essayer de comprendre que lorsque je compare un chiffre avec une partie fractionnaire, je dois le normaliser en utilisant la fonction NormalizeDouble(). Mais j'ai décidé de l'essayer pour le plaisir aujourd'hui et l'alerte est apparue ! Quel genre de problèmes ? Ou pas des pépins ?
1). Le compilateur peut simplement ignorer cette condition (instruction if).
2). Si, toutefois, le compilateur n'ignore pas cette condition, il écrira chaque nombre en mémoire et allouera 8 bits pour chaque nombre. Il compare les chiffres, non pas comme nous le faisons avec nos yeux, mais petit à petit. Les chiffres en mémoire sont les mêmes et la condition sera maintenue.
Je suis très surpris par votre question, car je n'arrive pas à comprendre comment ces deux nombres (deux enregistrements) ne sont pas perçus comme égaux ?
Vous n'avez pas répondu à ma question sur la répartition.
Suite à votre commentaire, je l'ai essayé sur un terminal à 4 chiffres avec un écart fixe, tout est OK. Mais un autre problème est apparu, l'erreur numéro 131, qui ne s'est pas produite sur le terminal à 5 chiffres.
Ma fonction de calcul MM est complexe et dans une de ses parties, lors du calcul du lot, la fonction renvoie par exemple le lot maximum possible 0,18 et vous pouvez ouvrir soit 0,1, 0,2 ou 0,3, c'est-à-dire que le pas est de 0,1.
Si je normalise le lot, il est arrondi à 0,2 et l'ordre n'est plus autorisé, bien que le lot maximum autorisé soit de 0,18. Quelle est la bonne façon d'arrondir ou de normaliser correctement le lot ?
""""...
Я очень удивлён был Вашему вопросу, так как не могу понять как можно два эти числа (две записи) воспринять не равными??""""