[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

Nouveau commentaire
 
Roman.:
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...
L'EA négocie un % de lot spécifique d'ekvit, c'est-à-dire que je ne peux entrer que des pourcentages comme 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.
 
MeTrade:
MaxZ:
Avez-vous fait des tests en semaine ? Le spread est-il flottant ?
Optimisé toute la semaine, testé ce soir et ce matin. Est-ce un problème ?
Vous n'avez pas répondu à ma question sur la répartition.
 
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 ! Quels sont ces problèmes ? Ou pas des pépins ?
      if (1.3320 == 1.3320)
         Alert("Ku!");
 
ScioMe:
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 ?
Quels sont les problèmes rencontrés ? Ces constantes sont égales. La condition est satisfaite.
 
MeTrade:
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.
ce problème ne se produit que chez les courtiers à 4 chiffres : "...je ne peux entrer qu'un pourcentage, par exemple 10, 5" - donc votre calcul est fait sans normalisation du volume avant l'ouverture d'un ordre, c'est-à-dire qu'au final, votre 10 ou 5 pour cent donne 0,123 ou 1,548 lots, ce qui provoque l'erreur numéro 131, veuillez corriger la fonction de calcul des lots ou demander à un télépathe, car il n'y a pas assez de données "d'entrée" (brutes) sur le sujet ...
 
ScioMe:
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 ?

 
MaxZ:
Vous n'avez pas répondu à ma question sur la répartition.
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.
 
MeTrade:
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.
Je dois m'asseoir ici et essayer de deviner ! :))) Je suis sûr que vous résoudrez aussi les autres problèmes.
 

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 ?

 
MaxZ :

""""...
Я очень удивлён был Вашему вопросу, так как не могу понять как можно два эти числа (две записи) воспринять не равными??""""


Je me débats avec ce problème depuis un moment maintenant. Ça m'a presque cassé le cerveau ! Le problème était le suivant : j'avais besoin d'effectuer une condition d'égalité dans le if (). Nous comparions des chiffres réels. Je ne pouvais pas recevoir d'alerte, je me demandais ce qui se passait. Ces chiffres, vous pouvez voir à l'œil nu qu'ils sont égaux ! Mais le terminal n'a pas voulu l'imprimer. J'ai fini par soupçonner que quelque chose n'allait pas, mais je n'arrivais pas à savoir ce qui n'allait pas. J'ai besoin de l'aide de la communauté mql4. J'ai posé une question ici, et merci, les experts (il semble que Roman et d'autres bonnes personnes) ont répondu que lorsque je compare des nombres réels, je dois les normaliser avec la fonction NormalizeDouble(). Ça a aidé. Mais aujourd'hui, je l'ai essayé et qu'est-ce qui ne va pas ? Ils sont comparés sans risque sans normalisation. Quoi qu'il en soit, j'en suis arrivé à la conclusion que parfois ils sont comparés et parfois ils ne le sont pas, alors je ferais mieux de les normaliser pour être sûr.
1...241242243244245246247248249250251252253254255...652
Nouveau commentaire