Priorité et associativité des opérateurs

Dans l'article <i65nol$rl6$1@saria.nerim.net>,
Marc Espie <espie@lain.home> écrit:

In article <20100907131151$22f3@prunille.vinc17.org>,
Vincent Lefevre <vincent-news@vinc17.net> 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.

sauf que les exemples ne sont pas normatifs.

Pour l'exemple 6, pas de problème, il y a équivalence car il est sur
des entiers, sauf en cas de comportement indéfini, mais je suppose
que la norme exclut ce cas-là (en cas de comportement indéfini, une
implémentation est en droit de faire absolument ce qu'elle veut).

L'exemple 5 parle de réarrangement, terme qui n'est défini nulle
pas dans la norme. Moi je n'ai pas parlé de réarrangement. :)
Je faisais en fait référence à la contraction d'expressions
flottantes, et d'après moi, une implémentation qui traduirait

a - b - c

avec un seul arrondi (typiquement le cas voulu par la contraction)
mais qui traduirait

(a - b) - c

avec un arrondi sur a - b puis un arrondi sur la seconde soustraction
serait conforme.

--
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)

Le 08/09/2010 01:34, Samuel DEVULDER a écrit :

Ben si je compare:
(a & b) | c = (a | c) & (b | c)
((a * b) + c)' = ((a + c) * (b + c))'
et:
(a | b) & c = (a & c) | (b & c)
((a + b) * c)' = ((a * c) + (b * c))'

Il me semble que c'est clair. "|" se map sur "+" et "&" sur "*" de façon
évidente, je dirais naturelle.

TILT! Ok je viens de réaliser: J'aurais pu aussi écrire:

Ben si je compare:

(a & b) | c = (a | c) & (b | c)
((a + b) * c)' = ((a * c) + (b * c))'

et:

(a | b) & c = (a & c) | (b & c)
((a * b) + c)' = ((a + c) * (b + c))'

Et alors "|" pourrait se mapper syntaxiquement sur "*" et "&" sur "+".

Pour trancher entre les deux mapping, il faut étudier laquelle de ces
associations préserve les éléments neutres et absorbants je suppose.

Tout ca devient effectivement de moins en moins "naturel" ;-)

sam (merci pour la discussion).

Vincent Lefevre écrivit :

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

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

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é...


Antoine

Le Wed, 08 Sep 2010 02:49:52 +0200,
Alexandre Bacquart <tek512@free.DELETEME.fr> écrivait :

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

Ce n'est _pas_ ce que j'ai écrit. Tu parlais de la différence entre
a - b - c et a - (b + c). Je te laisse conclure.

Mon boulot, c'est entre autre de l'analyse numérique et je dois être
déformé par ça (et par des langages RPN qui se contrefichent de ces
problèmes). Si un type écrit dans un algorithme abscons a - b - c,
tu ne sauras jamais si c'est juste (en précision finie, hein, parce
qu'en mathématiques, on est d'accord). Dans ce contexte, le code
autodocumenté, c'est de la foutaise.

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.

Sors un peu du C. Lorsque tu jongles avec plusieurs langages qui ne
se comportent pas de la même façon, c'est le meilleur moyen de te
tirer une balle dans le pied. Tous ceux qui m'ont dit ça un jour se
sont pris les pieds dans le tapis. Mais tu as parfaitement le droit
de te prétendre meilleur que les autres.

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.

Belle pirouette. Je te rappelle qu'on causait du C, donc a priori
de variables entières ou réelles.

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

C'est ton point de vue. On commence par écrire des choses comme a -
b - c - d parce que le compilo le permet et on finit par écrire des
trucs incompréhensibles parce que le compilateur le permet aussi. Un
code source doit être lisible (et commenté lorsqu'il y a des
expressions qui prêtent à confusion) et a - b - c ne l'est pas, que
tu le veuilles ou non parce que tu ne sauras _jamais_ si c'est fait
sciemment ou non.

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 ?!

C'est exactement la même chose mathématiquement parlant.
Informatiquement, il y a de fortes chances que le type qui a écrit
ça l'a fait en pleine connaissance de cause. Je ne sais pas si tu
vois bien la différence.

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)

Mais on s'en contrefiche, le débat portait sur l'utilisation des
parenthèses. De toute façon, dans l'immense majorité des cas, les
gens qui écrivent a - b - c pour reprendre ton exemple ne pipent pas
un mot sur la différence entre (a - b) - a et a - (b + c).

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.

EOT.

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

Antoine Leca a écrit :

JKB écrivit :

Le 06 Sep 2010 11:06:02 +0200, Jean-Marc Bourguet écrivait :

a - b - c ?
a / b / c ?

Je suis plutot de l'avis de Marc, un programmeur qui a besoin de
parentheses sur ces expressions est incompetant dans ce langage. Ce n'est
pas une subtilite.

Ouaips. Sauf que lorsque tu travailles dans plusieurs langages qui
sont orthogonaux, tu vas très vite dans le mur.

Un programmeur qui programme simultanément sur plusieurs langages, ce
n'est pas courant.

Ah bon ?
C'est pourtant ce que j'ai fait durant toute ma période (15 ans) de
développeur et tous mes collègues étaient dans ce cas.

[couic]

Antoine Leca a écrit :

JKB écrivit :

Ça ne change rien au fait que des parenthèses dans le cas

a - b - c

pour avoir

a - (b + c)

est largement plus clair.

... et, comme tu l'as toi-même (fort justement) fait remarquer
précédemment, un comportement légèrement différent aux limites
(genre b proche de a, et c très inférieur en magnitude).


Notez que je ne fais qu'insister sur le contenu de mon précédent message
: si le code dépend de la première forme et ne passe pas avec la seconde
(ou vice-versa), il faut rajouter des commentaires pour éviter de se
poser des questions existentielles.


Antoine

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.

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.

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.

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. 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 ;
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.

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'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).

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).

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.


Antoine

Marc Espie a écrit :

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

Le 06/09/2010 23:32, Marc Espie a écrit :

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

Dans les deux cas les surjections sont naturelles au sens où elles
préservent les propriétés et les structures des deux algèbres.

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.

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.

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.
En arithmetique classique, la distributivite "separe" + et *.

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.

La lecture de Dana Scott est absolument indispensable concernant le typage.

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

Samuel DEVULDER a écrit :

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.

Ce n'est pas du "formalisme trop puissant", tu entres simplement dans le
domaine de la sémantique des types qui restera, effectivement, à tout
jamais inaccessible au programmeur lambda (mais c'est bien dommage,
tellement c'est beau !)

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.

C'est un euphémisme !

Samuel DEVULDER écrivit :

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

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.

Poses en société la question « Mais comment fonctionne ... » (la
vaccination, la pasteurisation, un antibiotique, mais aussi un
thermostat, la comptabilité, la philosophie) et tu verras la différence
entre culture générale et culture scientifique.

Le fait que tu saches que quelque chose existe ou même à quoi cela peut
servir, ne signifie pas que tu as compris comment cela marche.
Et en fait, c'est exactement pour cela qu'existent les scientifiques (et
les techniciens en général) : parce que le grand public N'a PAS besoin
de savoir comment cela marche pour faire opérer un concept ou utiliser
une technique ; mais par contre il est nécessaire que certains, peu, le
sache, pour que le concept continue à être opérant, ou la technique
reste utilisable ou s'améliore. Pour le plus grand bien de la Société.


Antoine