Précédence des opérateurs

Bonjour,
Je suis débutante en programmation. et je viens d'avoir affaire au cours concernant la priorité relative aux opérateurs. Bref en mathématiques c'est simple:
n°1/ ()
n°2/ ** alias ^
n°3/ *, /
n°4) +,-
Mais en informatique il y a quelques nouveaux intrus: par exemple \ et mod qui viennent s'insérer respectivement entre le n° 3 et le 4. Aussi, le problème qui se pose encore pour moi, et que je n'arrive pas à saisir l'ordre que prennent les fonctions[abs(), sqrt(), sin(), tan()...], est-ce qu'elles sont exécutées au même temps que les parenthèses ou après celles-ci. D'autant plus que les avis divergent (sur un polycopier dédié au Visual Basic, on les classe avec le (), et sur un autre traitant du matlab on les classe priorité n°2, il faut dire que je m'emmêle les pinceaux avec tout ça...8O

Je vous serai reconnaissante si vous pouviez m'offrir un peu de votre attention et m'éclairer sur ce point.:oops:

http://en.wikipedia.org/wiki/Order_o...ming_languages ?

Merci beaucoup pour votre réponse. mais je ne vois pas le classement des fonctions dans tout cela.
Par exemple si on a l'expression suivante:
A= abs(x)+(v+z)/(x+y)

Le compilateur considère t-il que la priorité est aux parenthèses et commece alors par calculer:
R1: v+z .... puis:
R2: x+y
R3: abs(x)
R4: R1/R2
R5: R3+R4

ou bien considère t-il que les fonctions ont la même priorité que les parenthèses et effectue donc le calcul de la façon suivante:
R1: abs(x)
R2: v+z
R3: x+y
R4:R2/R3
R5: R1+R4
...

Veuillez tolérer mes jeunes connaissances en cette captivante discipline qui est l'informatique. Et encore MERCI de bien vouloir m'accepter dans votre communauté de professionnels :oops: en espérant que je puisse très vite partager avec vous des sujets d'un plus grand interêt.

Bien vu ! Je pensais qu'il aurait quelque part sur la page wiki un mot sur l'évaluation des fonctions (function evaluation), apparemment ce n'est pas le cas. Mais avoir la page wiki en tête est bien pour pouvoir s'attaquer ensuite aux problèmes de l'ordre de l'évaluation des fonctions, laquelle varie selon les différents langages de programmation (et parfois, selon les compilateurs !), e.g. http://stackoverflow.com/questions/1...valuation-vs-c :

Citation:

---

In C# it is left to right: http://blogs.msdn.com/oldnewthing/ar...4/4374222.aspx

In C++, any particular compiler can guarantee the order. The problem is that the language spec does not specify an order, so each compiler can do whatever it wants. This means you have to add a sequence point between the two method calls if you want to guarantee ordering.

---

Malheureusement je n'ai pas sous la main de lien recensant un grand nombre de langages de programmation et de compilateurs pour montrer leur politique en matière d'ordre d'évaluation des fonctions. Essaie de Googler "Order of function evaluation", il y aura sûrement d'autres liens intéressants.

Donc comme tu le vois, ce n'est pas du tout un problème aussi trivial qu'il n'y paraît :-)

Citation:

---

Envoyé par Franck Dernoncourt

Donc comme tu le vois, ce n'est pas du tout un problème aussi trivial qu'il n'y paraît :-)

---

Absolument :D:

Ce pourquoi je recommande systématiquement de :

• primo, mettre systématiquement des parenthèses autour de chaque bloc, ce que beaucoup de programeurs ne font pas.
  
  
• secondo, "réfléchir" un tantinet avant d'écrire.

Ainsi, dans l'exemple donné :

Citation:

---

Envoyé par oceane36

A= abs(x)+(v+z)/(x+y)

---

Pour obtenir de manière répétive et sûre le résultat attendu, il faut écrire :

A = ((v+z)/(x+y)) + abs(x)

Dans tous les cas de figure, n'obtenir que des opérations à 2 opérandes.

Autre exemple :

x = x + z + b*(x - y)

Dans ce cas, je conseille d'écrire :

x = x + (z + (b*(x-y)))

Bien que l'écriture soit plus lourde, on est certain de l'évaluation, quelle que soit les priorités des opérations et/ou fonctions.


L'ordre d'écriture/d'évaluation n'a pas d'importance à partir du moment où les opérations sont décomposées en opérations à 2 opérandes par les parenthèses.

Bonsoir,

Merci à vous, Franck Dernoncourt ainsi que Souviron34, pour vos réponses. Bien que j'avoue que vos arguments me dépassent un peu pour l'instant. Ce que je dois comprendre d'après vos réposes et que pour:

Franck: L'ordre d'évaluation dépend des langages, où libre cours est donné au copmilateur.

Souviron34: Essayez d'obtenir des opérations à deux opérandes pour éviter toute confusion.

Deux astuces de "chercheurs praticiens" qu'on a omis de notifier sur mes manuels rigides et bien disciplinés .
Le problème qui se pose donc pour moi et comment puis-je répondre à l'exercice sus-cité de manière parfaitement scolaire. Doit-je citer que le compilateur a carte blanche?? ou effectuer des modifications sur l'expression à calculer qu'on me soumet de manière à obtenir le nombre désiré d'opérandes????!!!!
J'avoue me perdre un peu dans tout cela ...ou bien suis-je allée un peu trop loin dans ma volonté de tout comprendre au point où je m'emmêle parfaitement les pinceaux à présent....:cry:

Citation:

---

Envoyé par oceane36

Le problème qui se pose donc pour moi et comment puis-je répondre à l'exercice sus-cité de manière parfaitement scolaire. Doit-je citer que le compilateur a carte blanche??

---

Si l'énoncé ne précise pas le langage, la réponse correcte version courte concernant l'évaluation des fonctions est "Cela dépend du langage, et dans certains langages, tels le C et le C++, cela dépend du compilateur".

Re

OK. Mais le comble du problème est que je ne pense pas que la réponse courte soit de mise, vu les énoncés très scolaires des exercices auxquels je suis confrontée. Genre: Soit: x=4; y=5; v=z=2 . Donnez le résultat de la formule suivante en précisant au préalable l'ordre dans lequel elle est exécutée:

A= abs(x)+(v+z)/(x+y)

Il faut dire qu'on s'attend là à une réponse des plus précices. Donc, on me basant sur tout ce que j'ai pu apprendre de cette discussion, je vais me permettre de considérer que la fonction est traitée au moment même de son apparition dans la formule, ce qui implique la solution suivante:

R1: abs(x)
R2: v+z
R3: x+y
R4:R2/R3
R5: R1+R4

D'autant plus que l'ordre ci-dessus ne nuit pas à l'exactitude du résultat du clacul au fianal.
Encore Merci pour avoir supporté mes idées confuses et pour avoir tenté de mettre un peu d'ordre dedans.
Veuillez croire en ma reconnaissance et mon éstime, les plus sincères.

Dans ton exercice, le moment où se passe l'évaluation de abs(x) n'a pas d'importance. Cela tombe bien car, encore une fois, nonobstant le caractère académique de ta tâche, ce moment dépend du langage et potentiellement du compilateur.

Tu peux aussi présenter ta réponse sous forme d'arbre, et laisser le prof choisir l'ordre qu'il veut. :P

  ___ + ___
 |         |
abs     __ / __
 |     |       |
 x    _+_     _+_
     |   |   |   |
     v   z   x   y

Il me semble (ce qui est la raison du point sur le découpage en 2 opérandes), que , quel que soit le langage et le compilateur, les compilateurs décomposent toujours en opérations à 2 opérandes, classées par ordre de parenthèses..

La réponse courte serait donc, à mon avis :

A= abs(x)+(v+z)/(x+y)

Analyse :

opération + (R) : 2 opérandes R1 et R2

R1 = abs(x) = opération à 1 opérande
R2 = opération à 2 opérandes R3 et R4

R3 = v+z = opération à 2 opérandes R5 et R6
R4 = x+y = opération à 2 opérandes R7 et R8

R5 = v
R6 = z

R7 = x
R8 = y

donc, l'ordre du calcul de abs(x) n'a pas d'importance
Par contre, ensuite, le calcul est fait par odre de parenthèse décroissant

calculer R4
calculer R3

puis calculer R2

Finalement calculer R


Et c'est d'ailleurs assez facile à modéliser mathématiquement (et informatiquement). Il y a de base 2 types d'opérations :

• des opérations à 1 opérande : abs, sqrt, etc...
• des opérations à 2 opérandes : +, -, /, *, pow, mod, etc..

• les opérations à 1 opérande sont "autonomes", donc la "précédence" n'a pas d'importance.
• Les opérations à 2 opérandes nécessitent d'avoir les 2 opérandes pour pouvoir être éxécutées. Chaque opérande est évalué suivant l'ordre des parenthèses. L'opération finale ne peut être éxcutée que lorsque les 2opérandes sont calculés.

Si donc on analyse une expression quelquonque, on peut , comme l'a montré pseudocode, faire un arbre.

Les compilateurs, ce me semble, analysent toujours cet arbre du bas vers le haut (comme indiqué plus haut, pour calculer R il faut avoir calculé R3 et R4).

Si donc on a écrit correctement avec les parenthèses bien placées, on a "mâché" le travail pour le compilateur, et on a un résultat reproductible.

Alors, ou bien j'ai raté quelque chose, ou bien il n'y a qu'un ensemble (fini) de permutations poissibles dans l'ordre :

1. Premier cas :
   
   
   
   • abs(x)
   • v+z
   • x+y
   • (v+z)/(x+y)
   • somme
   
   
   
2. Second cas :
   
   
   
   • abs(x)
   • x+y
   • v+z
   • (v+z)/(x+y)
   • somme
   
   
   
3. Troisème cas :
   
   
   
   • v+z
   • x+y
   • (v+z)/(x+y)
   • abs(x)
   • somme
   
   
   
4. Quatrième cas :
   
   
   
   • x+y
   • v+z
   • (v+z)/(x+y)
   • abs(x)
   • somme

On devrait pouvoir trouver une formailisation du nombre de permutations possibles en fontion du nombre d'opérations à 2 opérandes et de la prodondeur..

http://blogs.msdn.com/b/oldnewthing/...4/4374222.aspx :

Citation:

---

Note that order of evaluation is not the same as associativity and operator precedence. Given the expression f() + g() * h(), operator precedence says that it should be evaluated as if it were written f() + (g() * h()), but that doesn't say what order the three functions will be evaluated. It merely describes how the results of the three functions will be combined.

In the C# language, the order of evaluation is spelled out more explicitly. The order of evaluation for operators is left to right. if you write f() + g() in C#, the language guarantees that f() will be evaluated first. The example in the linked-to page is even clearer. The expression F(i) + G(i++) * H(i) is evaluated as if it were written like this:

temp1 = F(i);
temp2 = i++;
temp3 = G(temp2);
temp4 = H(i);
return temp1 + temp3 * temp4;
The side effects of each part of the expression take effect in left-to-right order. Even the order of evaluation of function arguments is strictly left-to-right.

---

Citation:

---

Envoyé par Franck Dernoncourt

The expression F(i) + G(i++) * H(i)

---

:ccool:

C'est aussi la raison pour laquelle je déconseille très très très fortement d'utiliser des "shortcuts" telles que celle-ci :

• d'une part de toute façons le compilo finit toujours par faire i = i +1, donc pourquoi se compliquer la lecture.
  
  
• d'autre part justement à cause de ce genre de choses, au moins on est sûr qu'on le fait au bon endroit..

Je ne sais pas en C#, mais en C, le nombre de soi-disants "gurus" qui programment des trucs soi-disant "super-efficaces" qui d'une part ressemblent plus à de l'obfuscation qu'autre chose,mais d'autre part qui amènent à ce genre de problèmes, en pariculier avec les incréments de pointeurs, sont légions (les tab[ptr++] pour éviter de faire tab[ptr] et ptr++ au bon endroit...)

Note: le problème posé était général, non ?

Citation:

---

Envoyé par souviron34

Je ne sais pas en C#, mais en C, le nombre de soi-disants "gurus" qui programment des trucs soi-disant "super-efficaces" qui d'une part ressemblent plus à de l'obfuscation qu'autre chose,mais d'autre part qui amènent à ce genre de problèmes, en pariculier avec les incréments de pointeurs, sont légions (les tab[ptr++] pour éviter de faire tab[ptr] et ptr++ au bon endroit...)

---

100% d'accord. KISS !

Citation:

---

Envoyé par souviron34

en pariculier avec les incréments de pointeurs, sont légions (les tab[ptr++] pour éviter de faire tab[ptr] et ptr++ au bon endroit...)

---

Ce qui est amusant, c'est que cette écriture est le reflet en C du mode d'adressage indexé pre/post-incrémenté de l'assembleur Motorola et ARM. C'était un mode d'adressage extrêmement puissant pour parcourir une liste.

L'avantage en l'assembleur c'est que l'écriture n'était pas ambigüe de part la simplicité des combinaisons opérations/opérandes possibles. :D

Citation:

---

Envoyé par pseudocode

Ce qui est amusant, c'est que cette écriture est le reflet en C du mode d'adressage indexé pre/post-incrémenté de l'assembleur Motorola et ARM. C'était un mode d'adressage extrêmement puissant pour parcourir une liste.

L'avantage en l'assembleur c'est que l'écriture n'était pas ambigüe de part la simplicité des combinaisons opérations/opérandes possibles. :D

---

Oui, mais quand tu as des expressions contenant des trucs comme :

*ptr1[ptr2++] += ....

ça devient vite..... le b.rdel... :aie:

Citation:

---

Envoyé par souviron34

ça devient vite..... le b.rdel... :aie:

---

mais non... pas du tout. Suffit de voir le code de strcpy :aie:

Code:

---

1 2 3 4

strcpy(char *s1,char *s2) { while (*s1++ = *s2++); }

---

Je me souviens que la première fois que j'ai vu ce code, je me suis dit que les codeurs C étaient soit des dieux, soit des fous. :D

Vous me voyez fascinée par la tournure que prend cette discussion :ccool:
Moi qui croyais avoir posé une question complètement anodine, je constate qu'elle est plus complexe qu'elle n'y paraît.

Comme j'aimerais assimiler toutes vos réponses et participer efficacement à la discussion!!!!! mais bon, je n'ai pas encore le bagage nécessaire:(
Donc pour l'instant, je me contenterai de bien intégrer la réponse de Souviron34:

Tous les cas de figure sont corrects

1er cas:

abs(x)
v+z
x+y
(v+z)/(x+y)
somme

Second cas :

abs(x)
x+y
v+z
(v+z)/(x+y)
somme

Troisème cas :

v+z
x+y
(v+z)/(x+y)
abs(x)
somme

Quatrième cas :

x+y
v+z
(v+z)/(x+y)
abs(x)
somme

Ce que je retiens aussi de cette discussion, est que le C est un langage de programmation vraiment enrichissant, vu que vous y faîtes à chaque fois référence. Je m'y mets alors:D

Encore Merci à Franck, Souviron34, pseudocode, pour votre amitié.

De rien :D

ça fait du bien un peu de faire remuer ces neurones .. :D

Citation:

---

Envoyé par pseudocode

soit des fous. :D

---

c'était la bonne réponse :mrgreen:

Je me souviens avoir eu un stagiaire qui m'avait programmé une convolution d'image par un laplacien sur une lgine.. et dont il était très fier.. Je lui ai fait remarquer que le gars du SAV ou de la maintenance (sans parler de lui-même 6 mois plus tard) mettrait environ 3h à décoder cette ligne... et le maudirait pendant quelques mois après... :aie: