Taille de la position retournant une valeur négative - page 3
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
Ce qui précède était une réponse spécifique à votre post spécifique"MathRound retourne un double ; nombre infini de décimales."
Encore une fois, selon la page de documentation.
"Valeur de retour
Valeur arrondie au nombre entier le plus proche."
Maintenant, une réponse spécifique à cette partie de votre post.
"Ce que la page dit, c'est ce qu'il fait. Elle arrondit. Rien à voir avec la question des décimales multiples."
Encore une fois, relisez la citation, elle dit qu'elle retourne "Valeur arrondie à l'entier le plus proche". Un entier, par définition, est un nombre entier, c'est-à-dire sans décimales. Et encore une fois, si ce n'est pas ce qu'elle fait réellement, alors le code ou la description est cassé, et l'un ou l'autre ou les deux doivent être corrigés par MQ, ou bien une étiquette d'avertissement indiquant que ces fonctions ne fonctionnent pas comme annoncé.
S'il retourne effectivement le type qui lui est donné, mais à l'équivalent mathématique de la valeur de l'entier le plus proche (comme dans retourne 1.00000 à partir de 1.23456, et 1 == 1.00000) mais ne retourne pas un type d'entier réel, alors la page de référence doit spécifier quelque chose comme "ne change pas le type de données sous-jacent" ou une autre manière qui est clairement indiquée.
La documentation de MetaQuotes est faible, au mieux.
Cependant, ceci étant dit, MathRound() retourne un double par définition :
Si la valeur retournée était : "Valeur divisée par 2", ce serait toujours un double.
De la même manière que "Valeur arrondie à l'entier le plus proche" est toujours un double.
J'espère que cela vous aidera.
La documentation de MetaQuotes est faible au mieux.
Cependant, ceci étant dit, MathRound() renvoie un double par définition :
Si la valeur renvoyée était : "Valeur divisée par 2", ce serait toujours un double.
De la même manière que "Valeur arrondie à l'entier le plus proche" est toujours un double.
J'espère que cela vous aidera.
Pour moi, "Valeur arrondie à l'entier le plus proche" n'est pas clair sur le fait qu'il renvoie autre chose qu'un entier à cause de la définition de l'entier. Je comprends que c'est effectivement la façon dont cela fonctionne, mais cela souligne mon point que le code et/ou la formulation de la page officielle est cassé et doit être corrigé. Soit le code doit être ajusté pour qu'il renvoie un type int, soit la formulation de la page doit être modifiée. En tant qu'utilisateurs, nous n'avons aucun moyen de le faire.La valeur que vous obtenez du nombre à arrondir ne change pas, à moins que vous ne la réassigniez à cette variable. Par exemple, si vous arrondissez y avec une valeur de 1,3 et que vous le placez dans x, en utilisant la formulation ci-dessus, une fois la fonction terminée, vous vous attendez à ce que y contienne toujours 1.3, et que x contienne 1, et non 1.0. Dans mon esprit, et la façon dont je l'interprète, arrondir signifie que vous arrondissez à l'élément le plus proche auquel vous essayez d'arrondir, et non à une valeur équivalente à cet élément. Peut-être que l'expression "quelque chose se perd dans la traduction" est très appropriée ici.
Je ne suis pas un fan de la documentation, mais je dois dire que je pense qu'ils ont été cohérents à cet égard. Toute la documentation liste le type de données retournées (int, double, bool etc) en haut de la page, la section valeur retournée plus loin ne répète jamais ce type de données. De plus, dans ce cas, ils renvoient exactement le même type de données que celui qui est entré.
Dans tous les cas, si vous utilisez la directive de compilation #property strict, vous devriez recevoir un avertissement :
Je ne suis pas un fan de la documentation, mais je dois dire que je pense qu'ils ont été cohérents à cet égard. Toute la documentation liste le type de données retournées (int, double, bool etc) en haut de la page, la section valeur retournée plus loin ne répète jamais ce type de données. De plus, dans ce cas, ils renvoient exactement le même type de données que celui qui est entré.
Dans tous les cas, si vous utilisez la directive de compilation #property strict, vous devriez recevoir un avertissement :
J'ai lancé un fil de discussion sur le forum MQL5.com à l'adresse https://www.mql5.com/en/forum/61394 qui, je l'espère, permettra de résoudre ce problème de documentation. Peut-être que si suffisamment de personnes soutiennent l'idée, MQ nous laissera tous aider à résoudre ce qui, jusqu'à présent, a été un problème pour de nombreuses personnes. J'espère que MQ acceptera l'idée, car nous, en tant qu'utilisateurs, ne pouvons rien changer.
knave & WH - Je suis tout à fait d'accord avec vos exemples, mais je vois toujours un problème ici, que je n'explique pas clairement, ou alors je suis l'une des rares personnes qui voient cela comme un problème. Pour moi, vos exemples prouvent mon côté de ce sujet plus que vous pensez qu'ils prouvent votre côté.
knave, votre exemple renverra une erreur parce qu'il ne renvoie pas le type de données qu'il est censé renvoyer, un int. Le fait que vous coulez votre variable en tant qu'int permet simplement de voir plus facilement le problème de la fonction qui ne fonctionne pas correctement.
WH, vous pointez cette ligne (de la page de documentation) et elle dit fondamentalement la même chose que la ligne que je mets en évidence. L'exemple utilise uniquement un double comme valeur envoyée à la fonction. Aucun de vos messages n'indique de manière 100% définitive que le type de données renvoyé par la fonction est un double, mais seulement que l'exemple envoie un double.
L'arrondi est généralement accepté pour changer la valeur d'un nombre spécifique à une précision inférieure. Je pense que nous sommes tous d'accord sur ce point.
Dans ce cas, ce n'est pas différent. La page spécifie "arrondi à l'entier le plus proche de la valeur numérique spécifiée". Elle indique qu'elle va arrondir à une précision inférieure (int) à partir d'une autre valeur. Dans l'exemple utilisé, un double est envoyé. C'est tout ce qui est clair à 100%.
Je suis désolé JD4, vous m'avez complètement perdu...
Aucun de vos posts n'indique de manière 100% définitive que le type de données retourné par la fonction est un double, seulement que l'exemple envoie un double.
C'est exactement ce que j'ai marqué d'une flèche. La fonction renvoie un double (grosse flèche rouge) et le paramètre passé est également un double (sous ma flèche). Jetez un coup d'œil à n'importe quelle fonction. OrderSend() renvoie un int... OrderClose() renvoie un bool.... et MathRound() renvoie un double...
knave, votre exemple renverra une erreur parce qu'il ne renvoie pas le type de données qu'il est censé renvoyer, un int. Le fait que vous coulez votre variable en tant qu'int permet simplement de voir plus facilement le problème de la fonction qui ne fonctionne pas correctement.
La fonction fonctionne exactement comme prévu.
Si vous pensez que c'est un int (faux), vous obtenez ceci :
Si vous le tapez comme un int, vous reconnaissez que vous utilisez le mauvais type de données :
Si vous le traitez comme un double (ce qu'il est), vous n'avez aucun avertissement :
Je suis désolé JD4, tu m'as complètement perdu...
C'est exactement ce que j'ai marqué d'une flèche. Elle renvoie un double (grosse flèche rouge) et le paramètre passé est également un double (sous ma flèche). Jetez un coup d'oeil à n'importe quelle fonction. OrderSend() renvoie un int... OrderClose() renvoie un bool.... et MathRound() renvoie un double...
La fonction fonctionne exactement comme annoncé.
Si vous pensez que c'est un int (faux), vous obtenez ceci :
Si vous le considérez comme un int, vous reconnaissez que vous utilisez le mauvais type de données :
Si vous le traitez comme un double (ce qu'il est), vous n'avez aucun avertissement :
L'exemple est un typecasting pour retourner un double. Dans votre exemple de code de int RoundedNumber, vous êtes un type casting pour retourner un int comme type de retour. Cela ne devrait pas être nécessaire car il est censé retourner un int, sur la base de ce que la page vous dit. La ligne en haut et celle dans la valeur de retour dit qu'il arrondit à un entier de la valeur spécifiée.Un nombre entier, peu importe combien de fois nous le disons différemment, n'a pas de décimales, de fractions, ou toute autre façon de représenter les nombres entre les nombres entiers, zéro, et les nombres entiers négatifs. Comme l'exemple que j'ai posté ci-dessus, basé sur la documentation donnée, l'envoi de la fonction MathRound "1.3" devrait retourner "1", et non "1.0", car "1.0" n'est pas un nombre entier, mais "1" l'est. (les guillemets ne servent qu'à clarifier)
Si vous le considérez comme un int, il y a une erreur parce que la fonction sous-jacente fonctionne à l'encontre de ce que la page indique, et non parce qu'elle est censée renvoyer autre chose qu'un int. Si vous le traitez comme un double (ce qu'il peut être mais n'est pas censé être), alors vous laissez la fonction incorrecte continuer à fonctionner à l'encontre de ce qu'elle est censée faire, à savoir renvoyer un entier qui a été arrondi à partir de la valeur qui lui a été envoyée, qui est un double.
L'envoi d'un double à arrondir (de la manière dont le code est documenté actuellement) vers un entier et ensuite le casting ou le stockage de la valeur retournée vers un type double ne génère pas d'erreurs parce qu'il est censé retourner un int, et si vous stockez un int vers un double, vous ne perdez aucune précision dans la conversion. Les erreurs sont là pour avertir le programmeur d'une perte potentielle de précision dans les calculs.Les erreurs sont là pour avertir le programmeur d'une perte potentielle de précision dans les calculs. Si vous stockez un double dans un int, vous vous attendrez à une erreur comme celle que vous montrez parce que vous le forcez à prendre une autre forme avec moins de précision qu'auparavant.
Si la fonction MathRound n'est pas censée renvoyer un entier, alors la formulation de la page doit être modifiée de manière à ce qu'elle ne dise pas qu'elle est censée renvoyer un entier. Mon problème n'a jamais été que la fonction fasse autre chose que ce qu'elle fait, si ce n'est qu'elle va à l'encontre de ce que la page dit qu'elle est censée faire.Ils doivent soit corriger le code de la fonction pour qu'elle retourne un int comme le dit la page de documentation, soit modifier la page de documentation pour refléter le fait qu'elle ne retourne pas nécessairement un int. "Arrondi à l'entier le plus proche" est exactement cela, un entier.
Edit : J'ai fait des recherches plus approfondies à travers les références C++ et Java, puisque MQL est quelque peu basé sur C++, et est syntaxiquement similaire à Java et C++. C++ montre sur une partie de la doc(http://www.cplusplus.com/reference/cmath/round/)"Round to nearest Returns the integral value that is nearest to x, with halfway cases rounded away from zero." Mais plus loin sur la page il est dit"Return Value The value of x rounded to the nearest integral (as a floating-point value)."Vous pourriez dire que cela confirme votre point de vue, alors qu'en fait, ce n'est pas le cas, car le C++ spécifie qu'il renvoie un flottant. La documentation Java sur http://docs.oracle.com/javase/7/docs/api/java/lang/Math.html montre ce qui suit sur les 2 méthodes nommées round. Les deux (Java et C++) sont fonctionnellement équivalentes dans leur langage aux fonctions MathRound et/ou round dans MQL.
MQL MathRound renvoie une valeur entière dans un type de données float. Ce que les fonctions d' arrondi C++ ou Java font n'est pas pertinent. Il est trivial d'écrire votre propre fonction 'int round(double a)' dans MQL si vous en voulez une.
Les flottants (32 bits) peuvent contenir des entiers (16 bits) sans perte de précision. Le problème est que le PO veut une valeur arrondie à deux décimales et s'attend à ce qu'elle soit exacte. Ce n'est pas le cas.
MQL MathRound renvoie une valeur entière dans un type de données float. Ce que font les fonctions d'arrondi C++ ou Java n'est pas pertinent. Il est trivial d'écrire votre propre fonction 'int round(double a)' dans MQL si vous en voulez une.
Les flottants (32 bits) peuvent contenir des entiers (16 bits) sans perte de précision. Le problème est que le PO veut une valeur arrondie à deux décimales et s'attend à ce qu'elle soit exacte. Ce n'est pas le cas.
Je me suis éloigné du sujet avec mes messages concernant spécifiquement la fonction fonctionnant d'une certaine manière, et j'ai fini de poster cette discussion hors sujet. Si cette discussion sur la fonction finit par se déplacer ailleurs, cela me convient.
Edit : J'ai commencé un fil de discussion pour continuer la discussion sur cette page de doc contradictoire à https://www.mql5.com/en/forum/156174. Gum, j'ai répondu à votre post ci-dessous ici sur ce fil.JD4, vous semblez être la seule personne à être confuse par ceci
HonestKnave a fait remarquer que la documentation montre clairement que la fonction renvoie un double. Un entier représenté comme un double.
"arrondi à l'entier le plus proche" ne signifie pas qu'il est converti en entier.
Si je vous dis de couper un morceau de bois à la même longueur qu'un morceau de ficelle. Le bois reste toujours du bois, il ne se transforme pas soudainement en un morceau de ficelle.
La ligne du haut et celle de la valeur de retour disent qu'elle arrondit à un entier de la valeur spécifiée.
Il faut soit corriger le code de la fonction pour qu'elle renvoie un entier comme le dit la page de documentation, soit modifier la page de documentation pour refléter le fait qu'elle ne renvoie pas nécessairement un entier. "Arrondi à l'entier le plus proche" est exactement cela, un entier.
Eh bien, je ne suis pas sûr de ce qui va vous convaincre JD4. La documentation indique clairement et à 100% que la fonction renvoie un double. Vous lisez quelque chose d'autre dans la description de la valeur renvoyée - il n'est jamais dit qu'elle renvoie un nombre entier.
Lorsque vous regardez OrderSend(), il est indiqué "Returned value : Renvoie le numéro du ticket attribué à l'ordre par le serveur commercial ou -1 en cas d'échec. Pour obtenir des informations supplémentaires sur les erreurs, il faut appeler la fonction GetLastError()."
Alors, qu'est-ce que cela signifie par numéro ? C'est un peu vague, vous ne trouvez pas ? Est-ce qu'ils veulent dire double ? float ? char ? short ? int ? long ? La réponse se trouve en haut de la page, comme la grande flèche que j'ai postée plus tôt. C'est leur format standard pour savoir où regarder pour voir le type de données retournées. (notez que je n'ai pas dit valeur des données retournées). Je ne peux vraiment pas penser à un seul exemple dans la documentation où la section "valeur retournée" mentionne le type de données.