Priorité et associativité des opérateurs

Marc Espie a écrit :

In article <4c8745cd$0$10193$ba4acef3@reader.news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:

Un code limpide avec des noms de variables bien choisies, des
parenthèses dans les expressions, etc. n'a pas besoin de commentaires.
Les commentaires sont souvent là pour exprimer de façon non formelle ce
qu'un mauvais programmeur n'a pas pu exprimer de façon clair en
formalisant dans sa programmation.
Il ne faut pas, non plus, négliger la lourdeur de la tâche de
maintenance des commentaires quand le code change.

ce que tu dis ne s'applique que si tu as des specs et une analyse independante
dont tu es sur qu'elles vont rester avec le code.

Non ça ne s'applique pas qu'à celà mais ce que tu décris est le cas idéal.

Par exemple, si tu fais du calcul numerique, tu fais comment pour ecrire
toute la preuve de ton calcul avec les marges d'erreurs directement dans
ton code ? tu mets des tonnes d'assert ? ca ne va pas suffire a expliquer
pourquoi telle valeur est < 1e-6

Si le 1e-6 est un choix du programmeur, il y a un bogue quelque part.
Cela relève d'un choix contextuel plus vaste donc est forcément
documenté dans une phase amont (conception, voire spécification, voire
aux niveaux des exigences ou contraintes.
Si cette valeur est un standard pour l'algorithme ou pour le domaine
industriel concerné, je suis d'accord que ça ne fait pas de mal
d'indiquer par un commentaire la référence à ce standard.

, par exemple. Et si tu reprends un algo

classique, tu vas le nommer algo_from_numerical_recipes_1985edition_p253 ?

Pourquoi pas ?
Dans le cas où il s'agit d'une fonction qui implémente un algorithme à
partir d'un bouquin ou d'un article, on peut, en tête de la fonction,
mettre un commentaire donnant les références et même indiquer les
correspondances des noms de variables si, pour des raisons de norme de
développement interne ou de qualité, on doit mettre des noms "parlant".

Il y a quand meme un point ou ca devient absurde et ou ecrire de vrais
commentaires va faire du sens...

Tu avoueras quand même que le pire ce sont les commentaires en fin de
ligne de code.
Grady Booch disait que le code doit se lire comme de l'anglais (ou du
français pour nous). En Ada, par exemple, comme on peut nommer les nom
des paramètres formels lors de l'appel, ça donne des choses comme ceci :
empiler(l_element=>mon_element, sur=>ma_pile)
le paramètre de type Element s'appelle l_element et le paramètre de type
Pile s'appelle... sur !
Evidemment j'ai donné un exemple trivial pour illustrer mais rien que
ça, je te garantis que ça réduit beaucoup les commentaires.

Le 08/09/2010 16:25, Wykaaa a écrit :

Marc Espie a écrit :

Si cette valeur est un standard pour l'algorithme ou pour le domaine
industriel concerné, je suis d'accord que ça ne fait pas de mal
d'indiquer par un commentaire la référence à ce standard.

Non seulement ca ne fait pas de mal, mais c'est souvent ce qui est fait
pour la tracabilité du code. Les outils de tracabilité et d'analyse
d'exigences analysent typiquement les commentaires du code et les docs
autour du code pour savoir d'où sort tel ou tel bout de code, le ce
qu'il couvre, le relier à la spec et aux exigences.

Avec ce genre d'outils tu sais parfaitement d'où sort le 1e-6, et tu
peux même savoir que si tu le changes alors tu impactera telle autre
constante dans tel autre bout de code ou de spec.

Grady Booch disait que le code doit se lire comme de l'anglais (ou du
français pour nous).

C'est une phrase de smaltalkien ca. D'ailleurs les vrais smalltalkistes
ne mettent pas de commentaires à cause de ca. Ils prétendent que leur
langage se lit comme de la littérature.

En Ada, par exemple, comme on peut nommer les nom

des paramètres formels lors de l'appel, ça donne des choses comme ceci :
empiler(l_element=>mon_element, sur=>ma_pile)
le paramètre de type Element s'appelle l_element et le paramètre de type
Pile s'appelle... sur !

héhé... on peut faire pareil en C avec le passage d'argument dans une
struct et les initialisateurs de champs. Cf un fil de cet été la dessus.

Evidemment j'ai donné un exemple trivial pour illustrer mais rien que
ça, je te garantis que ça réduit beaucoup les commentaires.

sam (self halt.)

In article <4c879cc1$0$10222$ba4acef3@reader.news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> wrote:

Grady Booch disait que le code doit se lire comme de l'anglais (ou du
français pour nous). En Ada, par exemple, comme on peut nommer les nom
des paramètres formels lors de l'appel, ça donne des choses comme ceci :
empiler(l_element=>mon_element, sur=>ma_pile)
le paramètre de type Element s'appelle l_element et le paramètre de type
Pile s'appelle... sur !
Evidemment j'ai donné un exemple trivial pour illustrer mais rien que
ça, je te garantis que ça réduit beaucoup les commentaires.

Je suis bien evidemment d'accord avec le nommage pertinent des variables
et des fonctions. Je repete a l'envi a mes etudiants "apres avoir ecrit
un commentaire, relisez votre code, et posez-vous la question: est-ce
que ce commentaire sert a quelque chose ? est-ce que je ne peux le supprimer
en nommant mieux ma fonction/mes variables ?"

En general, ca leur fait aussi un choc la premiere fois que je leur montre
du "vrai" code. En particulier, ils sont toujours surpris du fait qu'il y
a tres peu de commentaires, et que je leur explique:
- d'une part, qu'on ne commente pas des evidences pour des gens qui ne sont
pas totalement debutants.
- d'autre part, quand je leur detaille et que je leur montre que le code se
lit tres bien en l'absence de commentaires, tant que la structure est claire,
et que les identifiants sont choisis judicieusement.

Bonjour,

Le 08/09/2010 17:55, Marc Espie a écrit :

En general, ca leur fait aussi un choc la premiere fois que je leur montre
du "vrai" code. En particulier, ils sont toujours surpris du fait qu'il y
a tres peu de commentaires, [...]

Est-ce possible d'avoir un lien url (ou un copié-collé) correspondant à
un exemple de "vrai" code commenté dans les proportions que vous
décrivez ? Je serais tout simplement curieux de voir dans quelle mesure,
c'est "peu" commenté.


--
François Lafont

On 09/08/2010 11:20 AM, Antoine Leca wrote:

Alexandre Bacquart écrivit :

a - b - c

L'expression en tant que telle n'a rien à voir avec l'associativité, que
ce soit en maths ou en C. La seule règle à suivre est que ça s'applique
de gauche à droite.

Mmmm. Et le fait que lire de gauche à droite puisse donner le même
résultat que lire de droite à gauche, cela s'appelle comment, en maths ?

Autrement dit, parce que - n'est évidemment pas une opération
associative, tu as besoin d'une règle _conventionnelle_, en l'occurrence
qu'il faille lire de gauche à droite.

moindre petite subtilité, ni même une paire de parenthèses qui, soit dit
en passant, rajoutent une autre règle à suivre.

La position de JKB, c'est justement le rejet de la règle de la lecture
de gauche à droite, et son corrolaire, l'utilisation d'une _autre_
règle, celle des parenthèses : mais il ne s'agit pas d'une règle
supplémentaire, elle remplace.

Oui, c'est vrai, mais c'est a-(b+c) que je critique, pas (a-b)-c.

ce qu'on appelle du code auto-documenté.

Pour moi, le « code auto-documenté » à base de constructions implicites
est une lubie qui cache beaucoup de paresse de la part des programmeurs
et induit beaucoup de perte de temps pour des questions existentielles
au moment de la phase débogage ; là où c'est drôle, c'est quand il se
trouve que la même personne est à la fois le programmeur auto-
documentant et celui qui se pose des questions au débogage ;-)

Par contre, je crois que des formulation comme (a-b)-c ou a-(b+c) sont
effectivement auto-documentées, rajoutant explicitement une information
C'est surtout vrai lorsque, comme dans le premier cas, elles sont
syntaxiquement inutiles, donc n'ont de portée sémantique qu'à
destination de celui qui lit, comme n'importe quel commentaire.

Je partage ton avis sur le premier cas, mais pour le deuxième, c'est le
changement d'expression qui est susceptible de me gêner dans certains
contextes. J'ai bien dit "susceptible".

Maintenant, imagine qu'on récupère ce contexte dans un autre langage
fortement typé (au hasard, C++)

On est pas dans le bon groupe donc on est HS, mais bon, on a toujours le
droit de s'amuser en passant.

et qu'on veuille changer les types de
l'expression par des types dont la soustraction EST associative (au
hasard, des quaternions).

Euh, là je crois que tu dérapes.

On dérive toujours un peu, en toute franchise j'ai même hésité à le
mettre dans des balises HS. Mais JKB défendant son propos par le biais
de sa pratique d'autres langages, il me paraissait légitime de faire de
même. Ca avait le mérite d'approfondir ma réflexion sur la lisibilité
des expressions (et à défaut d'autre exemple concret, j'ai pris a-b-c,
car il n'a franchement pas les dents pointues celui-là et il était
justement cité par JKB). Mais même sans sortir de C, je peux très bien
vouloir exprimer "partant de a, ote b, puis ote c" et non pas "partant
de a, ote la somme de b et c".

Oui, le résultat est le même puisqu'on est dans R (passons le fait que
strictement, l'équivalence est fausse et qu'on est pas totalement dans
R, inutile d'alourdir le débat ici avec des UB de magnitudes ou de
débordements), mais à mes yeux, l'expression est *différente* avant
d'être *formelle et préférable*.

Mon propos, c'est l'expressivité, pas seulement la lisibilité. Si les
parenthèses permettent de virer l'âge du capitaine d'une équation, c'est
très bien (me gênent pas les parenthèses, je fais aussi parfois du Lisp,
je suis blindé) du moment que l'expression reste la même.

Les opérations des ordinateurs ne
peuvent pas opérer sur des ensembles infinis (enfin, pas dans des
conditions habituelles) ; et le fait que les ensembles soient finis fait
qu'il y a beaucoup moins d'associativité que tu ne sembles le penser ;

Tu te méprends, j'ai moi-même développé ce point ailleurs en disant que
C ne travaille que dans des sous-ensembles finis de R qui dépendent même
de l'implémentation.

ainsi l'addition des flottants n'est clairement pas associative
(a=grand, b=-grand, c=petit, résultat petit dans un sens et 0 dans
l'autre) ; idem pour les entiers signés dans certains cas de débordement.

Et je sais tout cela depuis longtemps. Je suis précisément, en ce
moment, dans ce bain là, notamment en ce qui concerne les flottants car
j'ai justement besoin de représenter des quantités astronomiques (de
l'ordre de l'année-lumière par rapport au centimètre) et étant donné mes
pré-requis, je vais devoir tricher (les doubles ne résolvent pas le
problème). Non, je n'envoie pas un fou sur Mars, mais ça doit quand même
marcher :)

On a beau jeu de dire que l'associativité se fait de gauche à droite.

C'est toi qui le dit ! Ne t'en déplaise, la clé, c'est qu'on apprend
d'abord à lire de gauche à droite (en occident du moins c'est très
répandu),

Intéressant. Tu as des références, s'il te plait ?

Désolé, mais non :-( Je ne fais que véhiculer une idée qui me semble
admise. Une idée reçue peut-être, mais dans ce cas, j'exprimerai ma
gratitude à quiconque me remet la tête à l'endroit.

D'abord, si effectivement nous lisons et écrivons les lettres de gauche
à droite, en ce qui concerne les nombres écrits en chiffres, c'est le
contraire, nous écrivons de droite à gauche (on rajoute le chiffre
supplémentaire à gauche) ; de plus, cet ordre qui vient du sanscrit (la
langue, qui fonctionne comme l'allemand, dvâ-trimçat et zwei-und-dreißig
au lieu de trente-deux) est le même pour les Indiens, les Arabes et les
Européens, alors même que le sens d'écriture des lettres (différent) a
fait modifier la forme des chiffres ; le sens de lecture des nombres lui
dépend complètement des langues, cf. supra.

En ce qui concerne les opérateurs, la seule chose que cela évoque pour
moi, c'est qu'en (ancien) français, on disait « b ôté de a » (ou
soustrait, ou /restado/ en espagnol), avant que la lecture mathématique
« a moins b » ne s'impose (?) récemment.

Évidemment, cela correspond surtout au mot utilisé, en français et en
espagnol nous utilisons un verbe (ôter, soustraire, /restar/) dont le
c.o.d. est la petite quantité qui est ôtée du tas, c.o.i., ce qui donc
influence directement la lecture.

Tous ces ordres sont donc millénaires.
L'ordre de lecture d'expressions algébriques complexes est lui
probablement nettement plus récent, mais je n'ai pas de sources claires.
Par exemple, je ne sais pas comment les Indiens (qui avaient une culture
essentiellement orale) groupaient les opérations multiples, et je ne
sais pas plus comment faisaient les Arabes, qui en mathématiques ont
beaucoup hérités des Indiens (sens flou, donc) et des Grecs (qui
écrivaient au départ en boustrophédon, ce qui fixe encore moins).

Donc, as-tu des références sur le phénomène de fixation de cet ordre de
lecture ? (et ses possibles variations au cours des siècles, ce qui
serait encore plus probant).

Non, je ne me posais même pas ces questions et je suis visiblement loin
de connaître le sujet aussi bien que toi (et au passage merci, car même
HS, c'est intéressant). Je suis même intimement convaincu que tu me
dépasses de plusieurs têtes dans tous les sujets dont il est question
ici (C, maths ou histoire de l'écriture...) et j'aurais sans doute de la
chance si je t'apprenais quelque-chose.

Maintenant, si mon introduction était peut-être maladroite, on est
quand-même au 21ème siècle, j'ai précisé "en occident" et j'ai même
rajouté "très répandu". Je ne sais pas vraiment dans quel bain de
culture tu te trouves, mais chez moi, j'applique toujours une expression
dans le sens de lecture (99% de gauche à droite) en l'absence de
parenthèses et avec des opérateurs aux priorités égales. Qui ne le fait
pas naturellement à part quelques mathématiciens spécialisés consacrant
leur vie à l'étude des super-hyper-shmilbliks ou je ne sais quelle
bizarrerie jusqu'à en oublier l'algèbre ? Je me rend bien compte de mon
inculture et ce serait intéressant pour moi de connaître l'existence
d'un domaine des maths où je dois, en l'absence de formalités, appliquer
les expressions dans le sens inverse de l'apparition de leur arguments.

Bien sûr qu'un type qui debug le code C d'un autre préfère tomber sur un
a-(b+c). J'apprécie même la chose à sa juste valeur en ajoutant qu'il
est *souvent* plus intuitif de considérer l'expression de cette manière
(ie. soustraire un total). Mais pas forcément, même dans R, et encore
moins dans un résidu de R.

Alors j'adorerais pouvoir t'éclairer à coup de références si j'en avais
sous la main. Je me console en me disant que de toutes façons, ça ne me
permettrait pas de faire tourner le moulin dans le bon sens car ça ne
concerne qu'une petite partie de mon propos.

Que je sorte de l'école primaire [...], je sais ce que fait a - b - c.

Dans ce cas, le fait est que tu le sais parce que tu viens juste
d'apprendre la convention ! Au milieu de l'école primaire, les élèves ne
savent pas comment traiter une expression comme a-b-c ; et c'est au
programme du dernier cours de primaire que l'on commence à leur
apprendre qu'il faut le lire de cette manière, en leur expliquant bien
qu'il s'agit d'une convention... qui a le grand mérite de bien
fonctionner avec les machines à calculer.
Le truc rigolo, c'est que les parenthèses, par contre, leur sont
expliquées plus tôt, et donc que la convention de lecture leur est
expliqué grâce aux parenthèses (du moins ici en Espagne).

Il ne me semble pas avoir appris les choses dans cet ordre en France il
y a plus de 25 ans, mais je peux me tromper.

Ah, et de plus la notion de variables ou d'inconnues (a, b et c), cela
n'est pas à la portée des élèves sortant de l'école primaire, il faut
que ce soit des vrais nombres pour qu'ils l'appréhendent.

Je crois bien, oui.


--
Alex

In article <4c87c4ab$0$23901$426a34cc@news.free.fr>,
Francois Lafont <francois.lafont@nospam.invalid> wrote:

Bonjour,

Le 08/09/2010 17:55, Marc Espie a écrit :

En general, ca leur fait aussi un choc la premiere fois que je leur montre
du "vrai" code. En particulier, ils sont toujours surpris du fait qu'il y
a tres peu de commentaires, [...]

Est-ce possible d'avoir un lien url (ou un copié-collé) correspondant à
un exemple de "vrai" code commenté dans les proportions que vous
décrivez ? Je serais tout simplement curieux de voir dans quelle mesure,
c'est "peu" commenté.

www.openbsd.org, source by web. Gratouillez dans des trucs maintenus par
le projet.

Il y a des cas ou il traine encore des commentaires, c'est juste qu'on n'a
pas pris le temps de faire plus propre. ;-)

Le 09/09/2010 00:29, Marc Espie a écrit :

Est-ce possible d'avoir un lien url (ou un copié-collé) correspondant à
un exemple de "vrai" code commenté dans les proportions que vous
décrivez ? Je serais tout simplement curieux de voir dans quelle mesure,
c'est "peu" commenté.

www.openbsd.org, source by web. Gratouillez dans des trucs maintenus par
le projet.

Il y a des cas ou il traine encore des commentaires, c'est juste qu'on n'a
pas pris le temps de faire plus propre. ;-)

Parfait, merci.



--
François Lafont

Le Thu, 09 Sep 2010 00:07:16 +0200,
Alexandre Bacquart <tek512@free.DELETEME.fr> écrivait :

On dérive toujours un peu, en toute franchise j'ai même hésité à le
mettre dans des balises HS. Mais JKB défendant son propos par le biais
de sa pratique d'autres langages, il me paraissait légitime de faire de
même. Ca avait le mérite d'approfondir ma réflexion sur la lisibilité
des expressions (et à défaut d'autre exemple concret, j'ai pris a-b-c,
car il n'a franchement pas les dents pointues celui-là et il était
justement cité par JKB). Mais même sans sortir de C, je peux très bien
vouloir exprimer "partant de a, ote b, puis ote c" et non pas "partant
de a, ote la somme de b et c".

Oui, et ? Va jusqu'au bout de ton raisonnement.

Lorsque tu écris a - b - c, tu ne sauras _jamais_ si le type qui a
codé ça l'a fait en toute connaissance de cause alors que si tu
avais (a - b) - c ou a - (b + c), tu n'aurais plus aucun doute.

Oui, le résultat est le même puisqu'on est dans R (passons le fait que
strictement, l'équivalence est fausse et qu'on est pas totalement dans
R, inutile d'alourdir le débat ici avec des UB de magnitudes ou de
débordements), mais à mes yeux, l'expression est *différente* avant
d'être *formelle et préférable*.

Mon propos, c'est l'expressivité, pas seulement la lisibilité. Si les
parenthèses permettent de virer l'âge du capitaine d'une équation, c'est
très bien (me gênent pas les parenthèses, je fais aussi parfois du Lisp,
je suis blindé) du moment que l'expression reste la même.

Mon discours n'est pas du tout de savoir si l'expression est la même
ou pas, mais de savoir si le type qui l'a écrite l'a fait en pleine
connaissance de cause (et aussi d'éviter les bugs surnuméraires
lorsque quelqu'un d'autre reprend le code). Dans les vieilleries que
je touche parfois tu ne peux même pas imaginer le nombre de ses
expressions à la noix qui posent problème dès qu'on change de
compilo !

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Alexandre Bacquart écrivit :

On 09/08/2010 11:20 AM, Antoine Leca wrote:

Par contre, je crois que des formulation comme (a-b)-c ou a-(b+c) sont
effectivement auto-documentées, rajoutant explicitement une information
C'est surtout vrai lorsque, comme dans le premier cas, elles sont
syntaxiquement inutiles, donc n'ont de portée sémantique qu'à
destination de celui qui lit, comme n'importe quel commentaire.

changement d'expression qui est susceptible de me gêner dans certains
contextes. J'ai bien dit "susceptible".

Il est des cas où le passage de a-b-c à a-(b+c) est justifié.
Un cas qui me vient de suite à l'esprit est celui où
a est une mesure
b est un premier correctif
c est un deuxième correctif
La formulation a-(b+c) réduit l'effet des erreurs d'arrondis.

Clairement, pour moi il y a une différence sémantique entre les trois
expressions, et donc les trois expressions ont leurs utilités. De plus,
la formulation a-(b+c) est techniquement différente en C, même si la
différence n'est pas « mathématique » mais due aux représentations.

j'applique toujours une expression
dans le sens de lecture (99% de gauche à droite) en l'absence de
parenthèses et avec des opérateurs aux priorités égales. Qui ne le fait
pas naturellement à part quelques mathématiciens spécialisés consacrant
leur vie à l'étude des super-hyper-shmilbliks ou je ne sais quelle
bizarrerie jusqu'à en oublier l'algèbre ?

Comme cela a été développé dans une autre partie de l'enfilade, ne le
font que ceux qui lisent l'expression avec son sens mathématique, donc
en général les scientifiques (dans l'acceptation générale du terme).

Et comme l'introduisait très bien « caribou » lorsqu'il a lancé toute
cette discussion en demandant <news:i5vilk$k86$1@adenine.netfront.net>
: Petit quizz : comment sont évaluées :
: a - b - c ?
: a / b / c ?
il y a des gens pour qui cette écriture heurte le bon entendement.
Y compris apparemment parmi les programmeurs C.

Bon depuis, tout le monde lui est tellement tombé dessus qu'il a changé
de pseudo ou est rentré dans sa coquille, mais la réaction initiale
montre bien que pour certains, ce n'est pas aussi évident que tu sembles
le dire.

À part cela, je suis incapable de déterminer si dans la population des
programmeurs, ce cas est exceptionnel, répandu ou entre les deux.
De plus il semble que je sois entouré de programmeurs anormaux
(si la norme est de travailler simultanément dans plusieurs langages).

Alexandre Bacquart écrivit :

Que je sorte de l'école primaire [...], je sais ce que fait a - b - c.

Dans ce cas, le fait est que tu le sais parce que tu viens juste
d'apprendre la convention ! [...]
Le truc rigolo, c'est que les parenthèses, par contre, leur sont
expliquées plus tôt, et donc que la convention de lecture leur est
expliqué grâce aux parenthèses (du moins ici en Espagne).

Il ne me semble pas avoir appris les choses dans cet ordre en France il
y a plus de 25 ans, mais je peux me tromper.

Moi non plus je ne m'en souviens pas (surtout que c'était avant, en
plein boum des maths modernes), c'est d'ailleurs pour cela que j'ai
précisé la référence à l'Espagne, référence que j'ai sous la main !


Antoine

Dans l'article <i67ems$pk2$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:

Ah, alors je n'ai pas compris ton idée.
Peux-tu donner des exemples précis de ce qui pourrait se passer ?

Cf l'exemple que j'ai donné dans un autre message.

Parce que le problème de fond, c'est quand même que l'évaluation de
a-b-c est lu par le compilateur comme {a-b}-c (en utilisant {} pour
exprimer la décomposition faite par l'analyseur syntaxique) ; donc si
les résultats diffèrent pour (a-b)-c qui a la même lecture syntaxique,
c'est que le compilateur (analyseur sémantique) fait exprès de ne pas
lire normalement : chose qui est effectivement possible dans certains
cas (dans les limites posées par la norme, plus les cas de bogues dans
le compilateur, que l'on ne peut pas négliger ici et qui me paraît
largement plus probable en l'instance) ; mais c'est aussi une chose qui
va surprendre la plupart des « utilisateurs », autrement dit cela
ressemble à de la mauvaise qualité...

Je suis assez d'accord, même si c'est discutable. De la même façon,
les variables étant des double dans l'exemple ci-dessous, on pourrait
se demander si le fait que

e = (a - b) - c;

et

d = a - b;
e = d - c;

ne soivent pas équivalents (concernant la valeur de e) soit une bonne
chose.

--
Vincent Lefèvre <vincent@vinc17.net> - Web: <http://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <http://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)