Priorité et associativité des opérateurs

espie

07/09/2010 à 18:03

In article <20100907131151$,
Vincent Lefevre wrote:

Oui, et cela poserait un autre problème, car il me semble que
la norme C ne garantit pas que a - b - c et (a - b) - c soient
équivalents, l'évaluation d'expressions flottantes étant largement
implementation-defined.

Je viens de verifier, difficile a retrouver, mais:
5.1.2.3 13 et 14 EXAMPLE 5 et 6

a - b - c et (a - b) - c sont equivalents.

Il y est ecrit entre autres qu'une implementation n'a le droit de reordonner
les expressions QUE s'il n'y a pas de difference de resultat.

De mon point de vue, sur des expressions simples, sur-parentheser n'a de
sens que si c'est associe aux commentaires idoines, e.g., bien expliquer
qu'on fait telle operation dans tel ordre pour eviter un debordement de
capacite...

Alexandre Bacquart

07/09/2010 à 22:27

On 09/06/2010 03:09 PM, JKB wrote:

Le Mon, 06 Sep 2010 14:51:01 +0200,
Pierre Maurette écrivait :
...

Troll detected !

...

Enfin, j'ai remarqué que:
a | b& c | d
a& b | c& d
a || b&& c || d
a&& b || c&& d
génèrent un warning, alors que:
a + b * c + d
a * b + c * d
laissent gcc muet. Est-ce logique ?

Oui. Il n'y a aucun problème là-dedans. Ce qui est litigieux, mais
aussi en mathématiques de base, ce sont des expressions comme

a - b - c

Ha bon ? Même en maths de base ? Ca fait pourtant bien ce que ça dit.

puisque le résultat est différent selon l'associativité.

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. Il n'y a aucun mystère là-dedans, même pas la
moindre petite subtilité, ni même une paire de parenthèses qui, soit dit
en passant, rajoutent une autre règle à suivre.

C'est dans ce cas qu'il faut mettre des parenthèses pour la lisibilité du
code.

Et tu parles de troll... tu dis que :

a - b - c

est moins lisible que :

a - (b + c)

C'est faux ! La deuxième expression dit, en substance, qu'il faut
"strictement faire d'abord l'opération de droite puis ensuite celle de
gauche", l'inverse de ce qu'on fait de manière naturelle.

Mais il y a des contextes où le schéma de pensée est, strictement, la
soustraction de b, puis la soustraction de c. Dans ces contextes, c'est
ce qu'on appelle du code auto-documenté. Le remplacer par ta version
soit-disant lisible, cela revient à mentir au lecteur.

Maintenant, imagine qu'on récupère ce contexte dans un autre langage
fortement typé (au hasard, C++) et qu'on veuille changer les types de
l'expression par des types dont la soustraction EST associative (au
hasard, des quaternions). Le mensonge touchera aussi le compilateur et
se transformera en erreur non détectée (pour peu qu'il implémente aussi
l'addition pour ce type, ce qui est généralement le cas si la
soustraction existe), et ça, c'est bien plus grave.

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), ensuite on apprend qu'en mathématiques, l'ordre des opérations
suit la même règle que l'ordre de lecture. Plus tard, on apprendra
l'usage des parenthèses. Enfin, on étudiera le concept d'associativité.

Quand je lis :

a - b - c

ça fait bien ce que ça dit, et ça dit :

(a - b) - c

et non pas

a - (b + c)

qui n'est équivalent que dans certains ensembles dont R (je te
l'accorde, c'est le seul ensemble dans lequel on peut travailler avec
les opérateurs de C). Mais même dans R, rien n'impose pas qu'on doive
penser "soustraire le total" plutôt que "soustraire un à un". Question
de contexte.

Que je sorte de l'école primaire ou que je sois Einstein, je sais ce que
fait a - b - c. Ca a le mérite d'être extrêmement lisible, MEME si on a
oublié les cours sur l'associativité, voire les parenthèses. Alors pour
la lisibilité, tu repasseras.

--
Alex

On 09/06/2010 03:09 PM, JKB wrote:

Le Mon, 06 Sep 2010 14:51:01 +0200,
Pierre Maurette<maurettepierre@wanadoo.fr> écrivait :

...

Troll detected !

...

Enfin, j'ai remarqué que:
a | b& c | d
a& b | c& d
a || b&& c || d
a&& b || c&& d
génèrent un warning, alors que:
a + b * c + d
a * b + c * d
laissent gcc muet. Est-ce logique ?

Oui. Il n'y a aucun problème là-dedans. Ce qui est litigieux, mais
aussi en mathématiques de base, ce sont des expressions comme

a - b - c

Ha bon ? Même en maths de base ? Ca fait pourtant bien ce que ça dit.

puisque le résultat est différent selon l'associativité.

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. Il n'y a aucun mystère là-dedans, même pas la
moindre petite subtilité, ni même une paire de parenthèses qui, soit dit
en passant, rajoutent une autre règle à suivre.

C'est dans ce cas qu'il faut mettre des parenthèses pour la lisibilité du
code.

Et tu parles de troll... tu dis que :

a - b - c

est moins lisible que :

a - (b + c)

C'est faux ! La deuxième expression dit, en substance, qu'il faut
"strictement faire d'abord l'opération de droite puis ensuite celle de
gauche", l'inverse de ce qu'on fait de manière naturelle.

Mais il y a des contextes où le schéma de pensée est, strictement, la
soustraction de b, puis la soustraction de c. Dans ces contextes, c'est
ce qu'on appelle du code auto-documenté. Le remplacer par ta version
soit-disant lisible, cela revient à mentir au lecteur.

Maintenant, imagine qu'on récupère ce contexte dans un autre langage
fortement typé (au hasard, C++) et qu'on veuille changer les types de
l'expression par des types dont la soustraction EST associative (au
hasard, des quaternions). Le mensonge touchera aussi le compilateur et
se transformera en erreur non détectée (pour peu qu'il implémente aussi
l'addition pour ce type, ce qui est généralement le cas si la
soustraction existe), et ça, c'est bien plus grave.

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), ensuite on apprend qu'en mathématiques, l'ordre des opérations
suit la même règle que l'ordre de lecture. Plus tard, on apprendra
l'usage des parenthèses. Enfin, on étudiera le concept d'associativité.

Quand je lis :

a - b - c

ça fait bien ce que ça dit, et ça dit :

(a - b) - c

et non pas

a - (b + c)

qui n'est équivalent que dans certains ensembles dont R (je te
l'accorde, c'est le seul ensemble dans lequel on peut travailler avec
les opérateurs de C). Mais même dans R, rien n'impose pas qu'on doive
penser "soustraire le total" plutôt que "soustraire un à un". Question
de contexte.

Que je sorte de l'école primaire ou que je sois Einstein, je sais ce que
fait a - b - c. Ca a le mérite d'être extrêmement lisible, MEME si on a
oublié les cours sur l'associativité, voire les parenthèses. Alors pour
la lisibilité, tu repasseras.

--
Alex

Vous avez filtré cet utilisateur ! Consultez son message

On 09/06/2010 03:09 PM, JKB wrote:

Le Mon, 06 Sep 2010 14:51:01 +0200,
Pierre Maurette écrivait :
...

Troll detected !

...

Enfin, j'ai remarqué que:
a | b& c | d
a& b | c& d
a || b&& c || d
a&& b || c&& d
génèrent un warning, alors que:
a + b * c + d
a * b + c * d
laissent gcc muet. Est-ce logique ?

Oui. Il n'y a aucun problème là-dedans. Ce qui est litigieux, mais
aussi en mathématiques de base, ce sont des expressions comme

a - b - c

Ha bon ? Même en maths de base ? Ca fait pourtant bien ce que ça dit.

puisque le résultat est différent selon l'associativité.

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. Il n'y a aucun mystère là-dedans, même pas la
moindre petite subtilité, ni même une paire de parenthèses qui, soit dit
en passant, rajoutent une autre règle à suivre.

C'est dans ce cas qu'il faut mettre des parenthèses pour la lisibilité du
code.

Et tu parles de troll... tu dis que :

a - b - c

est moins lisible que :

a - (b + c)

C'est faux ! La deuxième expression dit, en substance, qu'il faut
"strictement faire d'abord l'opération de droite puis ensuite celle de
gauche", l'inverse de ce qu'on fait de manière naturelle.

Mais il y a des contextes où le schéma de pensée est, strictement, la
soustraction de b, puis la soustraction de c. Dans ces contextes, c'est
ce qu'on appelle du code auto-documenté. Le remplacer par ta version
soit-disant lisible, cela revient à mentir au lecteur.

Maintenant, imagine qu'on récupère ce contexte dans un autre langage
fortement typé (au hasard, C++) et qu'on veuille changer les types de
l'expression par des types dont la soustraction EST associative (au
hasard, des quaternions). Le mensonge touchera aussi le compilateur et
se transformera en erreur non détectée (pour peu qu'il implémente aussi
l'addition pour ce type, ce qui est généralement le cas si la
soustraction existe), et ça, c'est bien plus grave.

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), ensuite on apprend qu'en mathématiques, l'ordre des opérations
suit la même règle que l'ordre de lecture. Plus tard, on apprendra
l'usage des parenthèses. Enfin, on étudiera le concept d'associativité.

Quand je lis :

a - b - c

ça fait bien ce que ça dit, et ça dit :

(a - b) - c

et non pas

a - (b + c)

qui n'est équivalent que dans certains ensembles dont R (je te
l'accorde, c'est le seul ensemble dans lequel on peut travailler avec
les opérateurs de C). Mais même dans R, rien n'impose pas qu'on doive
penser "soustraire le total" plutôt que "soustraire un à un". Question
de contexte.

Que je sorte de l'école primaire ou que je sois Einstein, je sais ce que
fait a - b - c. Ca a le mérite d'être extrêmement lisible, MEME si on a
oublié les cours sur l'associativité, voire les parenthèses. Alors pour
la lisibilité, tu repasseras.

--
Alex

JKB

07/09/2010 à 22:50

Le Tue, 07 Sep 2010 22:27:03 +0200,
Alexandre Bacquart écrivait :

On 09/06/2010 03:09 PM, JKB wrote:
Le Mon, 06 Sep 2010 14:51:01 +0200,
Pierre Maurette écrivait :
...

Troll detected !

...

Enfin, j'ai remarqué que:
a | b& c | d
a& b | c& d
a || b&& c || d
a&& b || c&& d
génèrent un warning, alors que:
a + b * c + d
a * b + c * d
laissent gcc muet. Est-ce logique ?

Oui. Il n'y a aucun problème là-dedans. Ce qui est litigieux, mais
aussi en mathématiques de base, ce sont des expressions comme

a - b - c

Ha bon ? Même en maths de base ? Ca fait pourtant bien ce que ça dit.

J'ai dit _litigieux_, je n'ai pas dit que ça pouvait être pris de
deux façons différentes !

puisque le résultat est différent selon l'associativité.

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. Il n'y a aucun mystère là-dedans, même pas la
moindre petite subtilité, ni même une paire de parenthèses qui, soit dit
en passant, rajoutent une autre règle à suivre.

C'est dans ce cas qu'il faut mettre des parenthèses pour la lisibilité du
code.

Et tu parles de troll... tu dis que :

a - b - c

est moins lisible que :

a - (b + c)

C'est faux ! La deuxième expression dit, en substance, qu'il faut
"strictement faire d'abord l'opération de droite puis ensuite celle de
gauche", l'inverse de ce qu'on fait de manière naturelle.

Je me contrefiche de savoir ce qu'on fait naturellement. Dans
certains langages, le choix du sens d'évaluation est laissé à la
discrétion du compilo. Si tu ne fais que du C, ça ne te posera aucun
problème. Si tu mélanges les langages, c'est une source d'erreurs. Tous
les gens que j'ai croisé et qui prétendaient le contraire ont fini
par se tirer une balle dans le pied avec des choses pareilles parce
qu'un jour où tu es un peu plus mal réveillé, tu codes en C comme tu
le fais en Fortran. Mais tu fais ce que tu veux.

Et je continue à prétendre que du point de vue de la stricte
lisibilité a-(b+c) est plus clair que a-b-c.

Mais il y a des contextes où le schéma de pensée est, strictement, la
soustraction de b, puis la soustraction de c. Dans ces contextes, c'est
ce qu'on appelle du code auto-documenté. Le remplacer par ta version
soit-disant lisible, cela revient à mentir au lecteur.

Et c'est une connerie. Si on évalue une expression dans un ordre
précis pour une raison précise, on y adjoint un commentaire. Je ne
crois pas en ce genre de code autodocumenté.

Maintenant, imagine qu'on récupère ce contexte dans un autre langage
fortement typé (au hasard, C++) et qu'on veuille changer les types de
l'expression par des types dont la soustraction EST associative (au
hasard, des quaternions). Le mensonge touchera aussi le compilateur et
se transformera en erreur non détectée (pour peu qu'il implémente aussi
l'addition pour ce type, ce qui est généralement le cas si la
soustraction existe), et ça, c'est bien plus grave.

Hors de contexte. On parle de C et d'entiers ou de flottants. Jamais
on n'a évoqué un cas où la soustraction n'était pas associative.

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), ensuite on apprend qu'en mathématiques, l'ordre des opérations
suit la même règle que l'ordre de lecture. Plus tard, on apprendra
l'usage des parenthèses. Enfin, on étudiera le concept d'associativité.

Quand je lis :

a - b - c

ça fait bien ce que ça dit, et ça dit :

(a - b) - c

et non pas

a - (b + c)

qui n'est équivalent que dans certains ensembles dont R (je te
l'accorde, c'est le seul ensemble dans lequel on peut travailler avec
les opérateurs de C). Mais même dans R, rien n'impose pas qu'on doive
penser "soustraire le total" plutôt que "soustraire un à un". Question
de contexte.

Que je sorte de l'école primaire ou que je sois Einstein, je sais ce que
fait a - b - c. Ca a le mérite d'être extrêmement lisible, MEME si on a
oublié les cours sur l'associativité, voire les parenthèses. Alors pour
la lisibilité, tu repasseras.

Tu fais ce que tu veux, personnellement, je m'en contrefiche. Je
mets toujours des parenthèses dès que les opérations ne sont pas
commutatives pour plusieurs raisons : forcer l'ordre d'évaluation et
rendre la chose plus lisible ne t'en déplaise. Parce lorsque ton
expression est un peu plus compliquée et tient sur plusieurs lignes,
les parenthèses, ça aide (surtout avec un truc comme vim, mais c'est
un autre débat).

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

Le Tue, 07 Sep 2010 22:27:03 +0200,
Alexandre Bacquart <tek512@free.DELETEME.fr> écrivait :

On 09/06/2010 03:09 PM, JKB wrote:

Le Mon, 06 Sep 2010 14:51:01 +0200,
Pierre Maurette<maurettepierre@wanadoo.fr> écrivait :

...

Troll detected !

...

Enfin, j'ai remarqué que:
a | b& c | d
a& b | c& d
a || b&& c || d
a&& b || c&& d
génèrent un warning, alors que:
a + b * c + d
a * b + c * d
laissent gcc muet. Est-ce logique ?

Oui. Il n'y a aucun problème là-dedans. Ce qui est litigieux, mais
aussi en mathématiques de base, ce sont des expressions comme

a - b - c

Ha bon ? Même en maths de base ? Ca fait pourtant bien ce que ça dit.

J'ai dit _litigieux_, je n'ai pas dit que ça pouvait être pris de
deux façons différentes !

puisque le résultat est différent selon l'associativité.

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. Il n'y a aucun mystère là-dedans, même pas la
moindre petite subtilité, ni même une paire de parenthèses qui, soit dit
en passant, rajoutent une autre règle à suivre.

C'est dans ce cas qu'il faut mettre des parenthèses pour la lisibilité du
code.

Et tu parles de troll... tu dis que :

a - b - c

est moins lisible que :

a - (b + c)

C'est faux ! La deuxième expression dit, en substance, qu'il faut
"strictement faire d'abord l'opération de droite puis ensuite celle de
gauche", l'inverse de ce qu'on fait de manière naturelle.

Je me contrefiche de savoir ce qu'on fait naturellement. Dans
certains langages, le choix du sens d'évaluation est laissé à la
discrétion du compilo. Si tu ne fais que du C, ça ne te posera aucun
problème. Si tu mélanges les langages, c'est une source d'erreurs. Tous
les gens que j'ai croisé et qui prétendaient le contraire ont fini
par se tirer une balle dans le pied avec des choses pareilles parce
qu'un jour où tu es un peu plus mal réveillé, tu codes en C comme tu
le fais en Fortran. Mais tu fais ce que tu veux.

Et je continue à prétendre que du point de vue de la stricte
lisibilité a-(b+c) est plus clair que a-b-c.

Mais il y a des contextes où le schéma de pensée est, strictement, la
soustraction de b, puis la soustraction de c. Dans ces contextes, c'est
ce qu'on appelle du code auto-documenté. Le remplacer par ta version
soit-disant lisible, cela revient à mentir au lecteur.

Et c'est une connerie. Si on évalue une expression dans un ordre
précis pour une raison précise, on y adjoint un commentaire. Je ne
crois pas en ce genre de code autodocumenté.

Maintenant, imagine qu'on récupère ce contexte dans un autre langage
fortement typé (au hasard, C++) et qu'on veuille changer les types de
l'expression par des types dont la soustraction EST associative (au
hasard, des quaternions). Le mensonge touchera aussi le compilateur et
se transformera en erreur non détectée (pour peu qu'il implémente aussi
l'addition pour ce type, ce qui est généralement le cas si la
soustraction existe), et ça, c'est bien plus grave.

Hors de contexte. On parle de C et d'entiers ou de flottants. Jamais
on n'a évoqué un cas où la soustraction n'était pas associative.

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), ensuite on apprend qu'en mathématiques, l'ordre des opérations
suit la même règle que l'ordre de lecture. Plus tard, on apprendra
l'usage des parenthèses. Enfin, on étudiera le concept d'associativité.

Quand je lis :

a - b - c

ça fait bien ce que ça dit, et ça dit :

(a - b) - c

et non pas

a - (b + c)

qui n'est équivalent que dans certains ensembles dont R (je te
l'accorde, c'est le seul ensemble dans lequel on peut travailler avec
les opérateurs de C). Mais même dans R, rien n'impose pas qu'on doive
penser "soustraire le total" plutôt que "soustraire un à un". Question
de contexte.

Que je sorte de l'école primaire ou que je sois Einstein, je sais ce que
fait a - b - c. Ca a le mérite d'être extrêmement lisible, MEME si on a
oublié les cours sur l'associativité, voire les parenthèses. Alors pour
la lisibilité, tu repasseras.

Tu fais ce que tu veux, personnellement, je m'en contrefiche. Je
mets toujours des parenthèses dès que les opérations ne sont pas
commutatives pour plusieurs raisons : forcer l'ordre d'évaluation et
rendre la chose plus lisible ne t'en déplaise. Parce lorsque ton
expression est un peu plus compliquée et tient sur plusieurs lignes,
les parenthèses, ça aide (surtout avec un truc comme vim, mais c'est
un autre débat).

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

Vous avez filtré cet utilisateur ! Consultez son message

Le Tue, 07 Sep 2010 22:27:03 +0200,
Alexandre Bacquart écrivait :

On 09/06/2010 03:09 PM, JKB wrote:
Le Mon, 06 Sep 2010 14:51:01 +0200,
Pierre Maurette écrivait :
...

Troll detected !

...

Enfin, j'ai remarqué que:
a | b& c | d
a& b | c& d
a || b&& c || d
a&& b || c&& d
génèrent un warning, alors que:
a + b * c + d
a * b + c * d
laissent gcc muet. Est-ce logique ?

Oui. Il n'y a aucun problème là-dedans. Ce qui est litigieux, mais
aussi en mathématiques de base, ce sont des expressions comme

a - b - c

Ha bon ? Même en maths de base ? Ca fait pourtant bien ce que ça dit.

J'ai dit _litigieux_, je n'ai pas dit que ça pouvait être pris de
deux façons différentes !

puisque le résultat est différent selon l'associativité.

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. Il n'y a aucun mystère là-dedans, même pas la
moindre petite subtilité, ni même une paire de parenthèses qui, soit dit
en passant, rajoutent une autre règle à suivre.

C'est dans ce cas qu'il faut mettre des parenthèses pour la lisibilité du
code.

Et tu parles de troll... tu dis que :

a - b - c

est moins lisible que :

a - (b + c)

C'est faux ! La deuxième expression dit, en substance, qu'il faut
"strictement faire d'abord l'opération de droite puis ensuite celle de
gauche", l'inverse de ce qu'on fait de manière naturelle.

Je me contrefiche de savoir ce qu'on fait naturellement. Dans
certains langages, le choix du sens d'évaluation est laissé à la
discrétion du compilo. Si tu ne fais que du C, ça ne te posera aucun
problème. Si tu mélanges les langages, c'est une source d'erreurs. Tous
les gens que j'ai croisé et qui prétendaient le contraire ont fini
par se tirer une balle dans le pied avec des choses pareilles parce
qu'un jour où tu es un peu plus mal réveillé, tu codes en C comme tu
le fais en Fortran. Mais tu fais ce que tu veux.

Et je continue à prétendre que du point de vue de la stricte
lisibilité a-(b+c) est plus clair que a-b-c.

Mais il y a des contextes où le schéma de pensée est, strictement, la
soustraction de b, puis la soustraction de c. Dans ces contextes, c'est
ce qu'on appelle du code auto-documenté. Le remplacer par ta version
soit-disant lisible, cela revient à mentir au lecteur.

Et c'est une connerie. Si on évalue une expression dans un ordre
précis pour une raison précise, on y adjoint un commentaire. Je ne
crois pas en ce genre de code autodocumenté.

Maintenant, imagine qu'on récupère ce contexte dans un autre langage
fortement typé (au hasard, C++) et qu'on veuille changer les types de
l'expression par des types dont la soustraction EST associative (au
hasard, des quaternions). Le mensonge touchera aussi le compilateur et
se transformera en erreur non détectée (pour peu qu'il implémente aussi
l'addition pour ce type, ce qui est généralement le cas si la
soustraction existe), et ça, c'est bien plus grave.

Hors de contexte. On parle de C et d'entiers ou de flottants. Jamais
on n'a évoqué un cas où la soustraction n'était pas associative.

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), ensuite on apprend qu'en mathématiques, l'ordre des opérations
suit la même règle que l'ordre de lecture. Plus tard, on apprendra
l'usage des parenthèses. Enfin, on étudiera le concept d'associativité.

Quand je lis :

a - b - c

ça fait bien ce que ça dit, et ça dit :

(a - b) - c

et non pas

a - (b + c)

qui n'est équivalent que dans certains ensembles dont R (je te
l'accorde, c'est le seul ensemble dans lequel on peut travailler avec
les opérateurs de C). Mais même dans R, rien n'impose pas qu'on doive
penser "soustraire le total" plutôt que "soustraire un à un". Question
de contexte.

Que je sorte de l'école primaire ou que je sois Einstein, je sais ce que
fait a - b - c. Ca a le mérite d'être extrêmement lisible, MEME si on a
oublié les cours sur l'associativité, voire les parenthèses. Alors pour
la lisibilité, tu repasseras.

Tu fais ce que tu veux, personnellement, je m'en contrefiche. Je
mets toujours des parenthèses dès que les opérations ne sont pas
commutatives pour plusieurs raisons : forcer l'ordre d'évaluation et
rendre la chose plus lisible ne t'en déplaise. Parce lorsque ton
expression est un peu plus compliquée et tient sur plusieurs lignes,
les parenthèses, ça aide (surtout avec un truc comme vim, mais c'est
un autre débat).

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

Samuel DEVULDER

07/09/2010 à 23:59

Le 07/09/2010 01:53, Marc Espie a écrit :

Justement, il n'y a rien de naturel ni de canonique dans tes surjections
(au sens theorie des categories),

Ca je ne connais pas. Il y a de vrais théorèmes utiles et pratiques la
dedans?

Un peu, oui. Toute la theorie du typage est basee dessus. Et toutes les
histoires de covariance/contravariance viennent aussi de la.

ah? Il faut bien baser les types sur une théorie, ca fait plus sérieux,
quitte à ce que la théorie soit celle du "grand tout et n'importe quoi" :)

Plus sérieusement, cela a l'air d'avoir rapport avec l'inférence de
types des compilo scala, camel et consors. C'est donc plus vraiment des
maths, mais du formalisme informatique trop puissant pour le commun des
programmeurs. En tout cas ca nous éloigne complètement du C et des
évaluations booléennes.

Tout ca pour demander: est-ce que l'aspect canonique est un truc
réellement important et utile dans les surjections que j'ai exhibé?

Oui, c'est important et utile. Si tu arrives a mettre deux structures
en correspondance, c'est souvent utile de savoir si ta correspondance
est totalement artificielle, ou si c'est quelque chose de plus profond.

Ah ok.. je comprends mieux. Ca dit juste que "c'est la même chose" et ca
permet aussi de le démontrer formellement. A contrario, j'imagine que ca
permet aussi de dire "pourquoi c'est différent" et par exemple exhiber
un contre exemple qui explique que les deux structures sont distinctes.

A mon avis ca ne doit pas être la même "symétrie" donc tu veux parler.
Est-ce que tu peux m'exhiber de quoi il s'agit au juste quand on parle
de ces symétrie?

Dans une algebre de Boole,& et | obeissent exactement aux memes regles.

Heu? je suis largué. Quelles règles?

En arithmetique classique, la distributivite "separe" + et *.

Heu (bis)? Il me semble que "|" se distribue par rapport à "&" de la
même façon que "+" par rapport à "*":
(a | b) & c = (a & c) | (b & c)
(a + b) * c = (a * c) + (b * c)

Les deux jeux d'opérations ont l'air vraiment très similaires.

Il n'y a pas un argument qui tue issu de la théorie des catégorie qui
montre que c'est vraiment pas la même chose? Car pour l'instant plus on
avance, et plus je trouve (bool, |, &) similaire à "(N, +, *) modulo
'n'est pas nul'".

PS: y a t'il un cours, une présentation succincte, qui explique les
catégories pour les nuls? J'ai tenté de lire:

ca je ne sais pas. On recommande souvent Dana Scott pour la partie typage.

Et "categories for the working mathematician" pour les gens interesses
par le cote mathematique.

Ah oui.. Bon je vais voir déjà si je peux trouver des trucs simples qui
montrent en quoi la théorie des catégorie sert. Quels sont ses grands
théorèmes et ce qu'ils traduisent des vérités du mode logique.

Une chose est sure, les théorèmes de cette théorie ne sont pas encore
dans la culture générale.

sam.

Le 07/09/2010 01:53, Marc Espie a écrit :

Justement, il n'y a rien de naturel ni de canonique dans tes surjections
(au sens theorie des categories),

Ca je ne connais pas. Il y a de vrais théorèmes utiles et pratiques la
dedans?

Un peu, oui. Toute la theorie du typage est basee dessus. Et toutes les
histoires de covariance/contravariance viennent aussi de la.

ah? Il faut bien baser les types sur une théorie, ca fait plus sérieux,
quitte à ce que la théorie soit celle du "grand tout et n'importe quoi" :)

Plus sérieusement, cela a l'air d'avoir rapport avec l'inférence de
types des compilo scala, camel et consors. C'est donc plus vraiment des
maths, mais du formalisme informatique trop puissant pour le commun des
programmeurs. En tout cas ca nous éloigne complètement du C et des
évaluations booléennes.

Tout ca pour demander: est-ce que l'aspect canonique est un truc
réellement important et utile dans les surjections que j'ai exhibé?

Oui, c'est important et utile. Si tu arrives a mettre deux structures
en correspondance, c'est souvent utile de savoir si ta correspondance
est totalement artificielle, ou si c'est quelque chose de plus profond.

Ah ok.. je comprends mieux. Ca dit juste que "c'est la même chose" et ca
permet aussi de le démontrer formellement. A contrario, j'imagine que ca
permet aussi de dire "pourquoi c'est différent" et par exemple exhiber
un contre exemple qui explique que les deux structures sont distinctes.

A mon avis ca ne doit pas être la même "symétrie" donc tu veux parler.
Est-ce que tu peux m'exhiber de quoi il s'agit au juste quand on parle
de ces symétrie?

Dans une algebre de Boole,& et | obeissent exactement aux memes regles.

Heu? je suis largué. Quelles règles?

En arithmetique classique, la distributivite "separe" + et *.

Heu (bis)? Il me semble que "|" se distribue par rapport à "&" de la
même façon que "+" par rapport à "*":
(a | b) & c = (a & c) | (b & c)
(a + b) * c = (a * c) + (b * c)

Les deux jeux d'opérations ont l'air vraiment très similaires.

Il n'y a pas un argument qui tue issu de la théorie des catégorie qui
montre que c'est vraiment pas la même chose? Car pour l'instant plus on
avance, et plus je trouve (bool, |, &) similaire à "(N, +, *) modulo
'n'est pas nul'".

PS: y a t'il un cours, une présentation succincte, qui explique les
catégories pour les nuls? J'ai tenté de lire:

ca je ne sais pas. On recommande souvent Dana Scott pour la partie typage.

Et "categories for the working mathematician" pour les gens interesses
par le cote mathematique.

Ah oui.. Bon je vais voir déjà si je peux trouver des trucs simples qui
montrent en quoi la théorie des catégorie sert. Quels sont ses grands
théorèmes et ce qu'ils traduisent des vérités du mode logique.

Une chose est sure, les théorèmes de cette théorie ne sont pas encore
dans la culture générale.

sam.

Vous avez filtré cet utilisateur ! Consultez son message

Le 07/09/2010 01:53, Marc Espie a écrit :

Justement, il n'y a rien de naturel ni de canonique dans tes surjections
(au sens theorie des categories),

Ca je ne connais pas. Il y a de vrais théorèmes utiles et pratiques la
dedans?

Un peu, oui. Toute la theorie du typage est basee dessus. Et toutes les
histoires de covariance/contravariance viennent aussi de la.

ah? Il faut bien baser les types sur une théorie, ca fait plus sérieux,
quitte à ce que la théorie soit celle du "grand tout et n'importe quoi" :)

Plus sérieusement, cela a l'air d'avoir rapport avec l'inférence de
types des compilo scala, camel et consors. C'est donc plus vraiment des
maths, mais du formalisme informatique trop puissant pour le commun des
programmeurs. En tout cas ca nous éloigne complètement du C et des
évaluations booléennes.

Tout ca pour demander: est-ce que l'aspect canonique est un truc
réellement important et utile dans les surjections que j'ai exhibé?

Oui, c'est important et utile. Si tu arrives a mettre deux structures
en correspondance, c'est souvent utile de savoir si ta correspondance
est totalement artificielle, ou si c'est quelque chose de plus profond.

Ah ok.. je comprends mieux. Ca dit juste que "c'est la même chose" et ca
permet aussi de le démontrer formellement. A contrario, j'imagine que ca
permet aussi de dire "pourquoi c'est différent" et par exemple exhiber
un contre exemple qui explique que les deux structures sont distinctes.

A mon avis ca ne doit pas être la même "symétrie" donc tu veux parler.
Est-ce que tu peux m'exhiber de quoi il s'agit au juste quand on parle
de ces symétrie?

Dans une algebre de Boole,& et | obeissent exactement aux memes regles.

Heu? je suis largué. Quelles règles?

En arithmetique classique, la distributivite "separe" + et *.

Heu (bis)? Il me semble que "|" se distribue par rapport à "&" de la
même façon que "+" par rapport à "*":
(a | b) & c = (a & c) | (b & c)
(a + b) * c = (a * c) + (b * c)

Les deux jeux d'opérations ont l'air vraiment très similaires.

Il n'y a pas un argument qui tue issu de la théorie des catégorie qui
montre que c'est vraiment pas la même chose? Car pour l'instant plus on
avance, et plus je trouve (bool, |, &) similaire à "(N, +, *) modulo
'n'est pas nul'".

PS: y a t'il un cours, une présentation succincte, qui explique les
catégories pour les nuls? J'ai tenté de lire:

ca je ne sais pas. On recommande souvent Dana Scott pour la partie typage.

Et "categories for the working mathematician" pour les gens interesses
par le cote mathematique.

Ah oui.. Bon je vais voir déjà si je peux trouver des trucs simples qui
montrent en quoi la théorie des catégorie sert. Quels sont ses grands
théorèmes et ce qu'ils traduisent des vérités du mode logique.

Une chose est sure, les théorèmes de cette théorie ne sont pas encore
dans la culture générale.

sam.

Marc

08/09/2010 à 00:10

Samuel DEVULDER wrote:

Le 07/09/2010 01:53, Marc Espie a écrit :

Dans une algebre de Boole,& et | obeissent exactement aux memes regles.

Heu? je suis largué. Quelles règles?

En arithmetique classique, la distributivite "separe" + et *.

Heu (bis)? Il me semble que "|" se distribue par rapport à "&" de la
même façon que "+" par rapport à "*":
(a | b) & c = (a & c) | (b & c)
(a + b) * c = (a * c) + (b * c)

Les deux jeux d'opérations ont l'air vraiment très similaires.

et "&" se distribue par rapport à "|" alors que pas "*" par rapport à "+".
(je garde ta formulation, même si elle me semble étrange)

Il n'y a pas un argument qui tue issu de la théorie des catégorie qui
montre que c'est vraiment pas la même chose? Car pour l'instant plus on
avance, et plus je trouve (bool, |, &) similaire à "(N, +, *) modulo
'n'est pas nul'".

et (bool,&,|) modulo "est nul".
Alors lequel choisir...

espie

08/09/2010 à 00:15

In article <4c86b5c7$0$22645$,
Samuel DEVULDER wrote:

Le 07/09/2010 01:53, Marc Espie a écrit :

Justement, il n'y a rien de naturel ni de canonique dans tes surjections
(au sens theorie des categories),

Ca je ne connais pas. Il y a de vrais théorèmes utiles et pratiques la
dedans?

Un peu, oui. Toute la theorie du typage est basee dessus. Et toutes les
histoires de covariance/contravariance viennent aussi de la.

ah? Il faut bien baser les types sur une théorie, ca fait plus sérieux,
quitte à ce que la théorie soit celle du "grand tout et n'importe quoi" :)

Justement, le jeu est d'eviter que ca soit "grand tout et n'importe quoi".
Dans ce cadre precis, les maths modernes "classiques" (la theorie des
ensembles) s'effondre completement, parce que justement, on ne parle plus
d'objets qui sont des ensembles, et le paradoxe de Cantor n'est pas bien
loin.

Plus sérieusement, cela a l'air d'avoir rapport avec l'inférence de
types des compilo scala, camel et consors. C'est donc plus vraiment des
maths, mais du formalisme informatique trop puissant pour le commun des
programmeurs. En tout cas ca nous éloigne complètement du C et des
évaluations booléennes.

On va plutot dire, incomprehensible pour le programmeur java moyen, hein...

A mon avis ca ne doit pas être la même "symétrie" donc tu veux parler.
Est-ce que tu peux m'exhiber de quoi il s'agit au juste quand on parle
de ces symétrie?

Dans une algebre de Boole,& et | obeissent exactement aux memes regles.

Heu? je suis largué. Quelles règles?

En arithmetique classique, la distributivite "separe" + et *.

Heu (bis)? Il me semble que "|" se distribue par rapport à "&" de la
même façon que "+" par rapport à "*":
(a | b) & c = (a & c) | (b & c)
(a + b) * c = (a * c) + (b * c)

Ben par exemple, (a & b) | c = (a | c) & (b | c)
(oui, c'est distributif aussi dans ce sens)
Du coup, qui de | et de & va jouer le role de l'addition.
Ton morphisme n'est pas naturel.

Une chose est sure, les théorèmes de cette théorie ne sont pas encore
dans la culture générale.

Rien de scientifique n'est vraiment dans la culture generale, jette un oeil
a un Trivial Pursuit si tu ne me crois pas ;(

In article <4c86b5c7$0$22645$426a34cc@news.free.fr>,
Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> wrote:

Le 07/09/2010 01:53, Marc Espie a écrit :

Justement, il n'y a rien de naturel ni de canonique dans tes surjections
(au sens theorie des categories),

Ca je ne connais pas. Il y a de vrais théorèmes utiles et pratiques la
dedans?

Un peu, oui. Toute la theorie du typage est basee dessus. Et toutes les
histoires de covariance/contravariance viennent aussi de la.

ah? Il faut bien baser les types sur une théorie, ca fait plus sérieux,
quitte à ce que la théorie soit celle du "grand tout et n'importe quoi" :)

Justement, le jeu est d'eviter que ca soit "grand tout et n'importe quoi".
Dans ce cadre precis, les maths modernes "classiques" (la theorie des
ensembles) s'effondre completement, parce que justement, on ne parle plus
d'objets qui sont des ensembles, et le paradoxe de Cantor n'est pas bien
loin.

Plus sérieusement, cela a l'air d'avoir rapport avec l'inférence de
types des compilo scala, camel et consors. C'est donc plus vraiment des
maths, mais du formalisme informatique trop puissant pour le commun des
programmeurs. En tout cas ca nous éloigne complètement du C et des
évaluations booléennes.

On va plutot dire, incomprehensible pour le programmeur java moyen, hein...

A mon avis ca ne doit pas être la même "symétrie" donc tu veux parler.
Est-ce que tu peux m'exhiber de quoi il s'agit au juste quand on parle
de ces symétrie?

Dans une algebre de Boole,& et | obeissent exactement aux memes regles.

Heu? je suis largué. Quelles règles?

En arithmetique classique, la distributivite "separe" + et *.

Heu (bis)? Il me semble que "|" se distribue par rapport à "&" de la
même façon que "+" par rapport à "*":
(a | b) & c = (a & c) | (b & c)
(a + b) * c = (a * c) + (b * c)

Ben par exemple, (a & b) | c = (a | c) & (b | c)
(oui, c'est distributif aussi dans ce sens)
Du coup, qui de | et de & va jouer le role de l'addition.
Ton morphisme n'est pas naturel.

Une chose est sure, les théorèmes de cette théorie ne sont pas encore
dans la culture générale.

Rien de scientifique n'est vraiment dans la culture generale, jette un oeil
a un Trivial Pursuit si tu ne me crois pas ;(

Vous avez filtré cet utilisateur ! Consultez son message

In article <4c86b5c7$0$22645$,
Samuel DEVULDER wrote:

Le 07/09/2010 01:53, Marc Espie a écrit :

Justement, il n'y a rien de naturel ni de canonique dans tes surjections
(au sens theorie des categories),

Ca je ne connais pas. Il y a de vrais théorèmes utiles et pratiques la
dedans?

Un peu, oui. Toute la theorie du typage est basee dessus. Et toutes les
histoires de covariance/contravariance viennent aussi de la.

ah? Il faut bien baser les types sur une théorie, ca fait plus sérieux,
quitte à ce que la théorie soit celle du "grand tout et n'importe quoi" :)

Justement, le jeu est d'eviter que ca soit "grand tout et n'importe quoi".
Dans ce cadre precis, les maths modernes "classiques" (la theorie des
ensembles) s'effondre completement, parce que justement, on ne parle plus
d'objets qui sont des ensembles, et le paradoxe de Cantor n'est pas bien
loin.

Plus sérieusement, cela a l'air d'avoir rapport avec l'inférence de
types des compilo scala, camel et consors. C'est donc plus vraiment des
maths, mais du formalisme informatique trop puissant pour le commun des
programmeurs. En tout cas ca nous éloigne complètement du C et des
évaluations booléennes.

On va plutot dire, incomprehensible pour le programmeur java moyen, hein...

A mon avis ca ne doit pas être la même "symétrie" donc tu veux parler.
Est-ce que tu peux m'exhiber de quoi il s'agit au juste quand on parle
de ces symétrie?

Dans une algebre de Boole,& et | obeissent exactement aux memes regles.

Heu? je suis largué. Quelles règles?

En arithmetique classique, la distributivite "separe" + et *.

Heu (bis)? Il me semble que "|" se distribue par rapport à "&" de la
même façon que "+" par rapport à "*":
(a | b) & c = (a & c) | (b & c)
(a + b) * c = (a * c) + (b * c)

Ben par exemple, (a & b) | c = (a | c) & (b | c)
(oui, c'est distributif aussi dans ce sens)
Du coup, qui de | et de & va jouer le role de l'addition.
Ton morphisme n'est pas naturel.

Une chose est sure, les théorèmes de cette théorie ne sont pas encore
dans la culture générale.

Rien de scientifique n'est vraiment dans la culture generale, jette un oeil
a un Trivial Pursuit si tu ne me crois pas ;(

Samuel DEVULDER

08/09/2010 à 01:19

Le 08/09/2010 00:10, Marc a écrit :

Samuel DEVULDER wrote:

Le 07/09/2010 01:53, Marc Espie a écrit :

Dans une algebre de Boole,& et | obeissent exactement aux memes regles.

Heu? je suis largué. Quelles règles?

En arithmetique classique, la distributivite "separe" + et *.

Heu (bis)? Il me semble que "|" se distribue par rapport à "&" de la
même façon que "+" par rapport à "*":
(a | b)& c = (a& c) | (b& c)
(a + b) * c = (a * c) + (b * c)

Les deux jeux d'opérations ont l'air vraiment très similaires.

et "&" se distribue par rapport à "|" alors que pas "*" par rapport à "+".
(je garde ta formulation, même si elle me semble étrange)

Ah tu fais référence à

(a & b) | c == (a | c) & (b | c)

Ben elle est aussi vrai avec + et * modulo "n'est pas nul".

Si je ne me trompe pas cela se démontre formellement en 2 étapes.

Si je note x' la valeur de (x!=0), on a
(a*b)' = a' & b' (1)
(a+b)' = a' | b' (2)

par ailleurs on a besoin de
T & x = x (3)
T | x = x (4)
x & x = x (5)
ainsi que de la commutativité, distributivité et l'associativité des
différents opérateurs dans N.

donc (étape 1):

((x+c)*c)' = (x*c+c*c)' (distributivité dans N)
= (x*c)' | (c*c)' (via 2)
= (x*c)' | (c' & c') (via 1)
= (x*c)' | c' (via 5)
= (x*c + c)' (via 2)
= ((x+1)*c)' (distributivité dans N)
= (x+1)' & c' (via 1)
= (x' | 1') & c' (via 2)
= (x' | T) & c' (définition de "'")
= T & c' (via 4)
= c' (via 3) [6]

Ensuite (étape 2):

((a + c) * (b + c))' = (a*b + (a+b+c)*c)' (distrib. dans N)
= (a*b)' | ((a+b+c)*c)' (via 2)
= (a*b)' | (((a+b) + c)*c)' (associativité)
= (a*b)' | c' (via 6)

On a donc formellement la même chose entre +* et |& au niveau de la
distributivité des eux opérateurs sur leur ensemble modulo la fonction
"x n'est pas nul".

Je n'arrive pas à me figurer pourquoi on dit que la distributivité est
différente.

Il n'y a pas un argument qui tue issu de la théorie des catégorie qui
montre que c'est vraiment pas la même chose? Car pour l'instant plus on
avance, et plus je trouve (bool, |,&) similaire à "(N, +, *) modulo
'n'est pas nul'".

et (bool,&,|) modulo "est nul".
Alors lequel choisir...

Pourquoi faire un choix? On choisi ce qu'on veut. Il peut y avoir 2
interprétation tout aussi naturelle l'une que l'autre. Naturel ne veut
pas dire unique je pense.

sam.

Le 08/09/2010 00:10, Marc a écrit :

Samuel DEVULDER wrote:

Le 07/09/2010 01:53, Marc Espie a écrit :

Dans une algebre de Boole,& et | obeissent exactement aux memes regles.

Heu? je suis largué. Quelles règles?

En arithmetique classique, la distributivite "separe" + et *.

Heu (bis)? Il me semble que "|" se distribue par rapport à "&" de la
même façon que "+" par rapport à "*":
(a | b)& c = (a& c) | (b& c)
(a + b) * c = (a * c) + (b * c)

Les deux jeux d'opérations ont l'air vraiment très similaires.

et "&" se distribue par rapport à "|" alors que pas "*" par rapport à "+".
(je garde ta formulation, même si elle me semble étrange)

Ah tu fais référence à

(a & b) | c == (a | c) & (b | c)

Ben elle est aussi vrai avec + et * modulo "n'est pas nul".

Si je ne me trompe pas cela se démontre formellement en 2 étapes.

Si je note x' la valeur de (x!=0), on a
(a*b)' = a' & b' (1)
(a+b)' = a' | b' (2)

par ailleurs on a besoin de
T & x = x (3)
T | x = x (4)
x & x = x (5)
ainsi que de la commutativité, distributivité et l'associativité des
différents opérateurs dans N.

donc (étape 1):

((x+c)*c)' = (x*c+c*c)' (distributivité dans N)
= (x*c)' | (c*c)' (via 2)
= (x*c)' | (c' & c') (via 1)
= (x*c)' | c' (via 5)
= (x*c + c)' (via 2)
= ((x+1)*c)' (distributivité dans N)
= (x+1)' & c' (via 1)
= (x' | 1') & c' (via 2)
= (x' | T) & c' (définition de "'")
= T & c' (via 4)
= c' (via 3) [6]

Ensuite (étape 2):

((a + c) * (b + c))' = (a*b + (a+b+c)*c)' (distrib. dans N)
= (a*b)' | ((a+b+c)*c)' (via 2)
= (a*b)' | (((a+b) + c)*c)' (associativité)
= (a*b)' | c' (via 6)

On a donc formellement la même chose entre +* et |& au niveau de la
distributivité des eux opérateurs sur leur ensemble modulo la fonction
"x n'est pas nul".

Je n'arrive pas à me figurer pourquoi on dit que la distributivité est
différente.

Il n'y a pas un argument qui tue issu de la théorie des catégorie qui
montre que c'est vraiment pas la même chose? Car pour l'instant plus on
avance, et plus je trouve (bool, |,&) similaire à "(N, +, *) modulo
'n'est pas nul'".

et (bool,&,|) modulo "est nul".
Alors lequel choisir...

Pourquoi faire un choix? On choisi ce qu'on veut. Il peut y avoir 2
interprétation tout aussi naturelle l'une que l'autre. Naturel ne veut
pas dire unique je pense.

sam.

Vous avez filtré cet utilisateur ! Consultez son message

Le 08/09/2010 00:10, Marc a écrit :

Samuel DEVULDER wrote:

Le 07/09/2010 01:53, Marc Espie a écrit :

Dans une algebre de Boole,& et | obeissent exactement aux memes regles.

Heu? je suis largué. Quelles règles?

En arithmetique classique, la distributivite "separe" + et *.

Heu (bis)? Il me semble que "|" se distribue par rapport à "&" de la
même façon que "+" par rapport à "*":
(a | b)& c = (a& c) | (b& c)
(a + b) * c = (a * c) + (b * c)

Les deux jeux d'opérations ont l'air vraiment très similaires.

et "&" se distribue par rapport à "|" alors que pas "*" par rapport à "+".
(je garde ta formulation, même si elle me semble étrange)

Ah tu fais référence à

(a & b) | c == (a | c) & (b | c)

Ben elle est aussi vrai avec + et * modulo "n'est pas nul".

Si je ne me trompe pas cela se démontre formellement en 2 étapes.

Si je note x' la valeur de (x!=0), on a
(a*b)' = a' & b' (1)
(a+b)' = a' | b' (2)

par ailleurs on a besoin de
T & x = x (3)
T | x = x (4)
x & x = x (5)
ainsi que de la commutativité, distributivité et l'associativité des
différents opérateurs dans N.

donc (étape 1):

((x+c)*c)' = (x*c+c*c)' (distributivité dans N)
= (x*c)' | (c*c)' (via 2)
= (x*c)' | (c' & c') (via 1)
= (x*c)' | c' (via 5)
= (x*c + c)' (via 2)
= ((x+1)*c)' (distributivité dans N)
= (x+1)' & c' (via 1)
= (x' | 1') & c' (via 2)
= (x' | T) & c' (définition de "'")
= T & c' (via 4)
= c' (via 3) [6]

Ensuite (étape 2):

((a + c) * (b + c))' = (a*b + (a+b+c)*c)' (distrib. dans N)
= (a*b)' | ((a+b+c)*c)' (via 2)
= (a*b)' | (((a+b) + c)*c)' (associativité)
= (a*b)' | c' (via 6)

On a donc formellement la même chose entre +* et |& au niveau de la
distributivité des eux opérateurs sur leur ensemble modulo la fonction
"x n'est pas nul".

Je n'arrive pas à me figurer pourquoi on dit que la distributivité est
différente.

Il n'y a pas un argument qui tue issu de la théorie des catégorie qui
montre que c'est vraiment pas la même chose? Car pour l'instant plus on
avance, et plus je trouve (bool, |,&) similaire à "(N, +, *) modulo
'n'est pas nul'".

et (bool,&,|) modulo "est nul".
Alors lequel choisir...

Pourquoi faire un choix? On choisi ce qu'on veut. Il peut y avoir 2
interprétation tout aussi naturelle l'une que l'autre. Naturel ne veut
pas dire unique je pense.

sam.

Samuel DEVULDER

08/09/2010 à 01:34

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

In article<4c86b5c7$0$22645$,
Samuel DEVULDER wrote:

Heu (bis)? Il me semble que "|" se distribue par rapport à "&" de la
même façon que "+" par rapport à "*":
(a | b)& c = (a& c) | (b& c)
(a + b) * c = (a * c) + (b * c)

Ben par exemple, (a& b) | c = (a | c)& (b | c)
(oui, c'est distributif aussi dans ce sens)

Oui et + et * aussi modulo la relation "n'est pas nul" (cf ma réponse à
marc glisse):
((a * b) + c)' = ((a + c) * (b + c))'

Du coup, qui de | et de& va jouer le role de l'addition.

Ton morphisme n'est pas naturel.

Je comprends pas. Pour moi le mapping me seble naturel. Mais peut être
que ce mot a un sens dans la théorie des catégorie qui ne recoupe pas le
sens commun.

Une chose est sure, les théorèmes de cette théorie ne sont pas encore
dans la culture générale.

Rien de scientifique n'est vraiment dans la culture generale, jette un oeil
a un Trivial Pursuit si tu ne me crois pas ;(

Ca dépend. Il doit bien y avoir des questions sur Pasteur et son vaccin
ou son système de préservation des produits laitiers ou sur la
pénicilline de Flemming.

C'est sur qu'il y a 2 sciences pour le public: celle qui sert au quidam
ou à peu prés, et l'autre, celle qui sert uniquement aux scientifiques
eux-même. Pour l'instant les catégories doivent faire partie du 2eme lot
je pense.

sam.

Alexandre Bacquart

08/09/2010 à 02:49

On 09/07/2010 10:50 PM, JKB wrote:

Le Tue, 07 Sep 2010 22:27:03 +0200,
Alexandre Bacquart écrivait :
On 09/06/2010 03:09 PM, JKB wrote:
C'est dans ce cas qu'il faut mettre des parenthèses pour la lisibilité du
code.

Et tu parles de troll... tu dis que :

a - b - c

est moins lisible que :

a - (b + c)

C'est faux ! La deuxième expression dit, en substance, qu'il faut
"strictement faire d'abord l'opération de droite puis ensuite celle de
gauche", l'inverse de ce qu'on fait de manière naturelle.

Je me contrefiche de savoir ce qu'on fait naturellement. Dans
certains langages, le choix du sens d'évaluation est laissé à la
discrétion du compilo. Si tu ne fais que du C, ça ne te posera aucun
problème. Si tu mélanges les langages, c'est une source d'erreurs. Tous
les gens que j'ai croisé et qui prétendaient le contraire ont fini
par se tirer une balle dans le pied avec des choses pareilles parce
qu'un jour où tu es un peu plus mal réveillé, tu codes en C comme tu
le fais en Fortran. Mais tu fais ce que tu veux.

Et je continue à prétendre que du point de vue de la stricte
lisibilité a-(b+c) est plus clair que a-b-c.

Mais il y a des contextes où le schéma de pensée est, strictement, la
soustraction de b, puis la soustraction de c. Dans ces contextes, c'est
ce qu'on appelle du code auto-documenté. Le remplacer par ta version
soit-disant lisible, cela revient à mentir au lecteur.

Et c'est une connerie. Si on évalue une expression dans un ordre
précis pour une raison précise, on y adjoint un commentaire.

x = a - b - c; // soustraire b à a, puis soustraire c

est un commentaire aussi utile que :

if (x > 42) // si x est supérieur à 42

Je ne crois pas en ce genre de code autodocumenté.

Si je veux dire à mon compilateur C de soustraire b puis de soustraire
c, j'écris -b-c. Le lecteur C ne peut que comprendre ce que j'ai voulu
dire, c'est toi qui cherche à transformer ce que je veux exprimer en
"soustraire la somme de b et c". Me fiche de savoir que c'est équivalent
dans R, ce n'est tout simplement plus la même expression.

C'est un des principes que j'applique pour l'auto-documentation de mon
code. Et en principe, je sais toujours dans quel langage je suis quand
mon debugger affiche du code.

Maintenant, imagine qu'on récupère ce contexte dans un autre langage
fortement typé (au hasard, C++) et qu'on veuille changer les types de
l'expression par des types dont la soustraction EST associative (au
hasard, des quaternions). Le mensonge touchera aussi le compilateur et
se transformera en erreur non détectée (pour peu qu'il implémente aussi
l'addition pour ce type, ce qui est généralement le cas si la
soustraction existe), et ça, c'est bien plus grave.

Hors de contexte. On parle de C et d'entiers ou de flottants. > Jamais on n'a évoqué un cas où la soustraction n'était pas associative.

C'est très typique du troll de crier hors-sujet quand on parle de C++
pour lui donner un exemple, alors qu'il n'hésite pas à évoquer le
beaucoup plus lointain Fortran pour se justifier par ailleurs.

Mais à la base, c'est quand-même toi qui est hors-sujet avec ta
conception de la lisibilité.

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), ensuite on apprend qu'en mathématiques, l'ordre des opérations
suit la même règle que l'ordre de lecture. Plus tard, on apprendra
l'usage des parenthèses. Enfin, on étudiera le concept d'associativité.

Quand je lis :

a - b - c

ça fait bien ce que ça dit, et ça dit :

(a - b) - c

et non pas

a - (b + c)

qui n'est équivalent que dans certains ensembles dont R (je te
l'accorde, c'est le seul ensemble dans lequel on peut travailler avec
les opérateurs de C). Mais même dans R, rien n'impose pas qu'on doive
penser "soustraire le total" plutôt que "soustraire un à un". Question
de contexte.

Que je sorte de l'école primaire ou que je sois Einstein, je sais ce que
fait a - b - c. Ca a le mérite d'être extrêmement lisible, MEME si on a
oublié les cours sur l'associativité, voire les parenthèses. Alors pour
la lisibilité, tu repasseras.

Tu fais ce que tu veux, personnellement, je m'en contrefiche. Je
mets toujours des parenthèses dès que les opérations ne sont pas
commutatives pour plusieurs raisons : forcer l'ordre d'évaluation et
rendre la chose plus lisible ne t'en déplaise.

Bon sang, si ce n'était qu'une question de parenthèses, j'admettrais
volontiers être le troll, mais pourquoi alors ne pas simplement écrire :

(a - b) - c

C'est moins clair ?! Je ne serais pas intervenu si tu avais écris ça. Ca
ne mériterait même pas un débat. Moi aussi j'utilise des parenthèses
pour faciliter la lecture, mais toi tu changes carrément l'expression
(et par dessus le marché, l'équivalence est strictement fausse en C car
on est dans un sous-ensemble fini de R, pas dans R, et avec ça ce
sous-ensemble peut changer d'une implémentation à l'autre) ! Moi aussi
je fais souvent :

(a == b) && (c == d)

plutôt que :

a == b && c == d

Ou encore :

(a & b) || (c & d) || (e & f)

plutôt que :

a & b || c & d || e & f

A partir du moment où ça ne change pas l'expression et que ça clarifie
le code, je n'y vois aucun inconvénient et je le pratique même. A la
limite, je changerais l'expression si elle implique une optimisation
(comme multiplier par 1/x pour diviser par x plusieurs fois, ou mettre
ton (b + c) dans une variable pour faire la soustraction plusieurs
fois), mais pas parce-que c'est cool d'être formel combiné à une règle
d'associativité qu'on doit aux mathématiques (les vraies, avec R infini)
et non pas au langage et ses pathétiques sous-ensembles aux débordements
indéfinis. Mauvaise raison si on veut simplement dire *soustraire b puis
soustraire c*, qu'on écrira alors a-b-c ou (a-b)-c si on est un maniaque
des parenthèses. Les deux me vont. Comme tu le dis si bien, chacun fait
ce qu'il veut, ça implique donc que chacun s'exprime comme il veut.

--
Alex

On 09/07/2010 10:50 PM, JKB wrote:

Le Tue, 07 Sep 2010 22:27:03 +0200,
Alexandre Bacquart<tek512@free.DELETEME.fr> écrivait :

On 09/06/2010 03:09 PM, JKB wrote:

C'est dans ce cas qu'il faut mettre des parenthèses pour la lisibilité du
code.

Et tu parles de troll... tu dis que :

a - b - c

est moins lisible que :

a - (b + c)

C'est faux ! La deuxième expression dit, en substance, qu'il faut
"strictement faire d'abord l'opération de droite puis ensuite celle de
gauche", l'inverse de ce qu'on fait de manière naturelle.

Je me contrefiche de savoir ce qu'on fait naturellement. Dans
certains langages, le choix du sens d'évaluation est laissé à la
discrétion du compilo. Si tu ne fais que du C, ça ne te posera aucun
problème. Si tu mélanges les langages, c'est une source d'erreurs. Tous
les gens que j'ai croisé et qui prétendaient le contraire ont fini
par se tirer une balle dans le pied avec des choses pareilles parce
qu'un jour où tu es un peu plus mal réveillé, tu codes en C comme tu
le fais en Fortran. Mais tu fais ce que tu veux.

Et je continue à prétendre que du point de vue de la stricte
lisibilité a-(b+c) est plus clair que a-b-c.

Mais il y a des contextes où le schéma de pensée est, strictement, la
soustraction de b, puis la soustraction de c. Dans ces contextes, c'est
ce qu'on appelle du code auto-documenté. Le remplacer par ta version
soit-disant lisible, cela revient à mentir au lecteur.

Et c'est une connerie. Si on évalue une expression dans un ordre
précis pour une raison précise, on y adjoint un commentaire.

x = a - b - c; // soustraire b à a, puis soustraire c

est un commentaire aussi utile que :

if (x > 42) // si x est supérieur à 42

Je ne crois pas en ce genre de code autodocumenté.

Si je veux dire à mon compilateur C de soustraire b puis de soustraire
c, j'écris -b-c. Le lecteur C ne peut que comprendre ce que j'ai voulu
dire, c'est toi qui cherche à transformer ce que je veux exprimer en
"soustraire la somme de b et c". Me fiche de savoir que c'est équivalent
dans R, ce n'est tout simplement plus la même expression.

C'est un des principes que j'applique pour l'auto-documentation de mon
code. Et en principe, je sais toujours dans quel langage je suis quand
mon debugger affiche du code.

Maintenant, imagine qu'on récupère ce contexte dans un autre langage
fortement typé (au hasard, C++) et qu'on veuille changer les types de
l'expression par des types dont la soustraction EST associative (au
hasard, des quaternions). Le mensonge touchera aussi le compilateur et
se transformera en erreur non détectée (pour peu qu'il implémente aussi
l'addition pour ce type, ce qui est généralement le cas si la
soustraction existe), et ça, c'est bien plus grave.

Hors de contexte. On parle de C et d'entiers ou de flottants. > Jamais on n'a évoqué un cas où la soustraction n'était pas associative.

C'est très typique du troll de crier hors-sujet quand on parle de C++
pour lui donner un exemple, alors qu'il n'hésite pas à évoquer le
beaucoup plus lointain Fortran pour se justifier par ailleurs.

Mais à la base, c'est quand-même toi qui est hors-sujet avec ta
conception de la lisibilité.

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), ensuite on apprend qu'en mathématiques, l'ordre des opérations
suit la même règle que l'ordre de lecture. Plus tard, on apprendra
l'usage des parenthèses. Enfin, on étudiera le concept d'associativité.

Quand je lis :

a - b - c

ça fait bien ce que ça dit, et ça dit :

(a - b) - c

et non pas

a - (b + c)

qui n'est équivalent que dans certains ensembles dont R (je te
l'accorde, c'est le seul ensemble dans lequel on peut travailler avec
les opérateurs de C). Mais même dans R, rien n'impose pas qu'on doive
penser "soustraire le total" plutôt que "soustraire un à un". Question
de contexte.

Que je sorte de l'école primaire ou que je sois Einstein, je sais ce que
fait a - b - c. Ca a le mérite d'être extrêmement lisible, MEME si on a
oublié les cours sur l'associativité, voire les parenthèses. Alors pour
la lisibilité, tu repasseras.

Tu fais ce que tu veux, personnellement, je m'en contrefiche. Je
mets toujours des parenthèses dès que les opérations ne sont pas
commutatives pour plusieurs raisons : forcer l'ordre d'évaluation et
rendre la chose plus lisible ne t'en déplaise.

Bon sang, si ce n'était qu'une question de parenthèses, j'admettrais
volontiers être le troll, mais pourquoi alors ne pas simplement écrire :

(a - b) - c

C'est moins clair ?! Je ne serais pas intervenu si tu avais écris ça. Ca
ne mériterait même pas un débat. Moi aussi j'utilise des parenthèses
pour faciliter la lecture, mais toi tu changes carrément l'expression
(et par dessus le marché, l'équivalence est strictement fausse en C car
on est dans un sous-ensemble fini de R, pas dans R, et avec ça ce
sous-ensemble peut changer d'une implémentation à l'autre) ! Moi aussi
je fais souvent :

(a == b) && (c == d)

plutôt que :

a == b && c == d

Ou encore :

(a & b) || (c & d) || (e & f)

plutôt que :

a & b || c & d || e & f

A partir du moment où ça ne change pas l'expression et que ça clarifie
le code, je n'y vois aucun inconvénient et je le pratique même. A la
limite, je changerais l'expression si elle implique une optimisation
(comme multiplier par 1/x pour diviser par x plusieurs fois, ou mettre
ton (b + c) dans une variable pour faire la soustraction plusieurs
fois), mais pas parce-que c'est cool d'être formel combiné à une règle
d'associativité qu'on doit aux mathématiques (les vraies, avec R infini)
et non pas au langage et ses pathétiques sous-ensembles aux débordements
indéfinis. Mauvaise raison si on veut simplement dire *soustraire b puis
soustraire c*, qu'on écrira alors a-b-c ou (a-b)-c si on est un maniaque
des parenthèses. Les deux me vont. Comme tu le dis si bien, chacun fait
ce qu'il veut, ça implique donc que chacun s'exprime comme il veut.

--
Alex

Vous avez filtré cet utilisateur ! Consultez son message

On 09/07/2010 10:50 PM, JKB wrote:

Le Tue, 07 Sep 2010 22:27:03 +0200,
Alexandre Bacquart écrivait :
On 09/06/2010 03:09 PM, JKB wrote:
C'est dans ce cas qu'il faut mettre des parenthèses pour la lisibilité du
code.

Et tu parles de troll... tu dis que :

a - b - c

est moins lisible que :

a - (b + c)

C'est faux ! La deuxième expression dit, en substance, qu'il faut
"strictement faire d'abord l'opération de droite puis ensuite celle de
gauche", l'inverse de ce qu'on fait de manière naturelle.

Je me contrefiche de savoir ce qu'on fait naturellement. Dans
certains langages, le choix du sens d'évaluation est laissé à la
discrétion du compilo. Si tu ne fais que du C, ça ne te posera aucun
problème. Si tu mélanges les langages, c'est une source d'erreurs. Tous
les gens que j'ai croisé et qui prétendaient le contraire ont fini
par se tirer une balle dans le pied avec des choses pareilles parce
qu'un jour où tu es un peu plus mal réveillé, tu codes en C comme tu
le fais en Fortran. Mais tu fais ce que tu veux.

Et je continue à prétendre que du point de vue de la stricte
lisibilité a-(b+c) est plus clair que a-b-c.

Mais il y a des contextes où le schéma de pensée est, strictement, la
soustraction de b, puis la soustraction de c. Dans ces contextes, c'est
ce qu'on appelle du code auto-documenté. Le remplacer par ta version
soit-disant lisible, cela revient à mentir au lecteur.

Et c'est une connerie. Si on évalue une expression dans un ordre
précis pour une raison précise, on y adjoint un commentaire.

x = a - b - c; // soustraire b à a, puis soustraire c

est un commentaire aussi utile que :

if (x > 42) // si x est supérieur à 42

Je ne crois pas en ce genre de code autodocumenté.

Si je veux dire à mon compilateur C de soustraire b puis de soustraire
c, j'écris -b-c. Le lecteur C ne peut que comprendre ce que j'ai voulu
dire, c'est toi qui cherche à transformer ce que je veux exprimer en
"soustraire la somme de b et c". Me fiche de savoir que c'est équivalent
dans R, ce n'est tout simplement plus la même expression.

C'est un des principes que j'applique pour l'auto-documentation de mon
code. Et en principe, je sais toujours dans quel langage je suis quand
mon debugger affiche du code.

Maintenant, imagine qu'on récupère ce contexte dans un autre langage
fortement typé (au hasard, C++) et qu'on veuille changer les types de
l'expression par des types dont la soustraction EST associative (au
hasard, des quaternions). Le mensonge touchera aussi le compilateur et
se transformera en erreur non détectée (pour peu qu'il implémente aussi
l'addition pour ce type, ce qui est généralement le cas si la
soustraction existe), et ça, c'est bien plus grave.

Hors de contexte. On parle de C et d'entiers ou de flottants. > Jamais on n'a évoqué un cas où la soustraction n'était pas associative.

C'est très typique du troll de crier hors-sujet quand on parle de C++
pour lui donner un exemple, alors qu'il n'hésite pas à évoquer le
beaucoup plus lointain Fortran pour se justifier par ailleurs.

Mais à la base, c'est quand-même toi qui est hors-sujet avec ta
conception de la lisibilité.

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), ensuite on apprend qu'en mathématiques, l'ordre des opérations
suit la même règle que l'ordre de lecture. Plus tard, on apprendra
l'usage des parenthèses. Enfin, on étudiera le concept d'associativité.

Quand je lis :

a - b - c

ça fait bien ce que ça dit, et ça dit :

(a - b) - c

et non pas

a - (b + c)

qui n'est équivalent que dans certains ensembles dont R (je te
l'accorde, c'est le seul ensemble dans lequel on peut travailler avec
les opérateurs de C). Mais même dans R, rien n'impose pas qu'on doive
penser "soustraire le total" plutôt que "soustraire un à un". Question
de contexte.

Que je sorte de l'école primaire ou que je sois Einstein, je sais ce que
fait a - b - c. Ca a le mérite d'être extrêmement lisible, MEME si on a
oublié les cours sur l'associativité, voire les parenthèses. Alors pour
la lisibilité, tu repasseras.

Tu fais ce que tu veux, personnellement, je m'en contrefiche. Je
mets toujours des parenthèses dès que les opérations ne sont pas
commutatives pour plusieurs raisons : forcer l'ordre d'évaluation et
rendre la chose plus lisible ne t'en déplaise.

Bon sang, si ce n'était qu'une question de parenthèses, j'admettrais
volontiers être le troll, mais pourquoi alors ne pas simplement écrire :

(a - b) - c

C'est moins clair ?! Je ne serais pas intervenu si tu avais écris ça. Ca
ne mériterait même pas un débat. Moi aussi j'utilise des parenthèses
pour faciliter la lecture, mais toi tu changes carrément l'expression
(et par dessus le marché, l'équivalence est strictement fausse en C car
on est dans un sous-ensemble fini de R, pas dans R, et avec ça ce
sous-ensemble peut changer d'une implémentation à l'autre) ! Moi aussi
je fais souvent :

(a == b) && (c == d)

plutôt que :

a == b && c == d

Ou encore :

(a & b) || (c & d) || (e & f)

plutôt que :

a & b || c & d || e & f

A partir du moment où ça ne change pas l'expression et que ça clarifie
le code, je n'y vois aucun inconvénient et je le pratique même. A la
limite, je changerais l'expression si elle implique une optimisation
(comme multiplier par 1/x pour diviser par x plusieurs fois, ou mettre
ton (b + c) dans une variable pour faire la soustraction plusieurs
fois), mais pas parce-que c'est cool d'être formel combiné à une règle
d'associativité qu'on doit aux mathématiques (les vraies, avec R infini)
et non pas au langage et ses pathétiques sous-ensembles aux débordements
indéfinis. Mauvaise raison si on veut simplement dire *soustraire b puis
soustraire c*, qu'on écrira alors a-b-c ou (a-b)-c si on est un maniaque
des parenthèses. Les deux me vont. Comme tu le dis si bien, chacun fait
ce qu'il veut, ça implique donc que chacun s'exprime comme il veut.

--
Alex

Vincent Lefevre

08/09/2010 à 03:57

Dans l'article <i65skr$mva$,
Antoine Leca écrit:

Si j'ai bien compris ton idée, tu dis qu'on pourrait avoir un
compilateur qui teste le débordement entier (histoire de montrer que
cela ne s'arrête pas aux flottants ;-)) pour a-b quand on met les
parenthèses, mais qui ne le testerait pas sans les parenthèses.
Résultat, a=INT_MAX, b=-1, c00 fait sauter la banque dans le deuxième
cas mais pas dans le premier.

Sans parler de comportement indéfini, il y a aussi la contraction
d'expressions flottantes qui peut introduire des différences.

--
Vincent Lefèvre - 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)

Priorité et associativité des opérateurs

10 réponses

Veuillez sélectionner un problème