Visual Studio et priorités d'opérations

Bonjour, je ne sais pas si je post dans la bonne section. Si ce n'est pas le cas dites le moi S.V.P. Bref je me demande si visual studio respecte vraiment l'ordre des priorité d'opération. Aujourd'hui j'ai vu passé un calcul simple sur le web qui est 8/ 2(2+2) officiellement la réponse est 1. Lorsque je le calcul manuellement, j'ai effectivement 1 comme réponse ainsi que sur ma calculatrice de comptabilité. Mais parcontre en vérifiant en c# avec visual studio 2017, la réponse donne 16 ... Je me demande donc si il est normal que certains calculs soit erroné dans certains code ??

Bonjour

Sauf horreur de ma part en VS les parenthèses passent en premier donc 2+2 = 4

Ensuite, il y a deux opérations une division et une multiplication qu'il considère être du même niveau de priorité (même chose pour l'addition et la soustraction). Alors ce qui l'emporte c'est l'orde de gauche à droite. Donc 8/2 = 4 puis 4 multiplié par 4 donne 16

Citation:

---

Envoyé par azhek

Bonjour, je ne sais pas si je post dans la bonne section. Si ce n'est pas le cas dites le moi S.V.P. Bref je me demande si visual studio respecte vraiment l'ordre des priorité d'opération. Aujourd'hui j'ai vu passé un calcul simple sur le web qui est 8/ 2(2+2) officiellement la réponse est 1. Lorsque je le calcul manuellement, j'ai effectivement 1 comme réponse ainsi que sur ma calculatrice de comptabilité. Mais parcontre en vérifiant en c# avec visual studio 2017, la réponse donne 16 ... Je me demande donc si il est normal que certains calculs soit erroné dans certains code ??

---

Est-ce-que tu ne confondrais pas l'écriture sous forme de fraction et l'écriture sous forme d'une suite d'opération ? Parce-que 8 "sur" 2 x (2+2) se traduit en ligne par 8 / (2 * (2 + 2)) et non 8 / 2 * (2 + 2), car dans ce cas la priorité des opérateurs s'applique telle que clementmarcotte l'a décrite.

Infos prises dans divers articles de presse :

Citation:

---

Dans les pays anglo-saxons deux règles existent. Celle de l’acronyme BODMAS, qui donne la priorité aux parenthèses, puissances, divisions, multiplications, additions et enfin soustractions, et mène donc à la réponse 16. Mais on trouve aussi la méthode PEMDAS qui suit le même ordre de priorité... mais inverse divisions et multiplications et donne donc la réponse 1.

---

Citation:

---

Le New York Times ne cherche pas à trancher ce conflit entre les deux acronymes, mais se range sans problème du côté de la réponse 16.

Tout en reconnaissant qu’aucun mathématicien qui se respecte n’irait écrire une opération de la sorte et indiquerait clairement la priorité qu’il faut donner en ajoutant une autre paire de parenthèse, le journal explique que généralement la convention veut de toute façon que lorsque deux opérations d’égale priorité s’affrontent (addition et soustraction ou multiplication et division) on calcule tout simplement dans le sens de lecture, donc de gauche à droite.

---

Bonjour,

Pour l'arrondi, Microsoft respecte le standard de l'IEEE, essentiellement le 5 est arrondi en plus ou en moins, toujours vers le nombre pair. Je ne serais pas surpris qu'ils suivent les standards de l'IEEE pour l'ensemble des calculs. Mais, rien de mieux que les parenthèses.

Citation:

---

Envoyé par Noxen

Est-ce-que tu ne confondrais pas l'écriture sous forme de fraction et l'écriture sous forme d'une suite d'opération ? Parce-que 8 "sur" 2 x (2+2) se traduit en ligne par 8 / (2 * (2 + 2)) et non 8 / 2 * (2 + 2), car dans ce cas la priorité des opérateurs s'applique telle que clementmarcotte l'a décrite.

---

Comme l'explique Noxen, le résultat dépendra de comment est posée l'opération sur papier.
Soit le 8 est au dessus de la barre de division et le 2 est en dessous, laissant l'opération (2+2) à coté, et la réponse est 16.

Code:

---

1 2 3 4

8 --- (2+2) 2

---

Soit le 8 est seul au dessus de la barre de division et tout le reste au dessous et le résultat est 1.
Mais dans ce cas l'opération à plat doit être posé de cette façon : 8/(2(2+2))

Code:

---

1 2 3 4

8 -------- 2(2+2)

---

Donc la réponse officielle de l'opération à plat telle que tu la posée est 16 et non pas 1.

Citation:

---

Envoyé par joKED

Infos prises dans divers articles de presse :

Citation:

---

Le New York Times ne cherche pas à trancher ce conflit entre les deux acronymes, mais se range sans problème du côté de la réponse 16.

Tout en reconnaissant qu’aucun mathématicien qui se respecte n’irait écrire une opération de la sorte et indiquerait clairement la priorité qu’il faut donner en ajoutant une autre paire de parenthèse, le journal explique que généralement la convention veut de toute façon que lorsque deux opérations d’égale priorité s’affrontent (addition et soustraction ou multiplication et division) on calcule tout simplement dans le sens de lecture, donc de gauche à droite.

---

---

En effet. Et le débat ayant été largement débattu et pour ainsi dire tranché par ailleurs la semaine dernière.
Pourquoi le ramener ici ?

Le Dr en mathématique interrogé et qui souligne qu'aucun mathématicien n'irait écrire un truc aussi ambigu est une bonne leçon pour les développeurs.

Il n'est pas rare, sur les forums, de se faire reprendre pour une parenthèse ou une accolade inutile.
Mais personnellement, si ces affirmation sont techniquement exactes, je trouve qu'elles manquent totalement de pragmatisme.
Une parenthèse inutile ne ralentira ni le compilateur et encore moins l'exécution, alors qu'elle facilitera la lecture.