Par contre, je crois que des formulation comme (a-b)-c ou a-(b+c) sont
effectivement auto-documentées, rajoutant explicitement une information
C'est surtout vrai lorsque, comme dans le premier cas, elles sont
syntaxiquement inutiles, donc n'ont de portée sémantique qu'à
destination de celui qui lit, comme n'importe quel commentaire.
Je partage ton avis sur le premier cas, mais pour le deuxième, c'est le
changement d'expression qui est susceptible de me gêner dans certains
contextes. J'ai bien dit "susceptible".
Oui, le résultat est le même puisqu'on est dans R (passons le fait que
strictement, l'équivalence est fausse et qu'on est pas totalement dans R,
inutile d'alourdir le débat ici avec des UB de magnitudes ou de
débordements), mais à mes yeux, l'expression est *différente* avant d'être
*formelle et préférable*.
Et je sais tout cela depuis longtemps. Je suis précisément, en ce moment,
dans ce bain là, notamment en ce qui concerne les flottants car j'ai
justement besoin de représenter des quantités astronomiques (de l'ordre de
l'année-lumière par rapport au centimètre) et étant donné mes pré-requis, je
vais devoir tricher (les doubles ne résolvent pas le problème).
Par contre, je crois que des formulation comme (a-b)-c ou a-(b+c) sont
effectivement auto-documentées, rajoutant explicitement une information
C'est surtout vrai lorsque, comme dans le premier cas, elles sont
syntaxiquement inutiles, donc n'ont de portée sémantique qu'à
destination de celui qui lit, comme n'importe quel commentaire.
Je partage ton avis sur le premier cas, mais pour le deuxième, c'est le
changement d'expression qui est susceptible de me gêner dans certains
contextes. J'ai bien dit "susceptible".
Oui, le résultat est le même puisqu'on est dans R (passons le fait que
strictement, l'équivalence est fausse et qu'on est pas totalement dans R,
inutile d'alourdir le débat ici avec des UB de magnitudes ou de
débordements), mais à mes yeux, l'expression est *différente* avant d'être
*formelle et préférable*.
Et je sais tout cela depuis longtemps. Je suis précisément, en ce moment,
dans ce bain là, notamment en ce qui concerne les flottants car j'ai
justement besoin de représenter des quantités astronomiques (de l'ordre de
l'année-lumière par rapport au centimètre) et étant donné mes pré-requis, je
vais devoir tricher (les doubles ne résolvent pas le problème).
Par contre, je crois que des formulation comme (a-b)-c ou a-(b+c) sont
effectivement auto-documentées, rajoutant explicitement une information
C'est surtout vrai lorsque, comme dans le premier cas, elles sont
syntaxiquement inutiles, donc n'ont de portée sémantique qu'à
destination de celui qui lit, comme n'importe quel commentaire.
Je partage ton avis sur le premier cas, mais pour le deuxième, c'est le
changement d'expression qui est susceptible de me gêner dans certains
contextes. J'ai bien dit "susceptible".
Oui, le résultat est le même puisqu'on est dans R (passons le fait que
strictement, l'équivalence est fausse et qu'on est pas totalement dans R,
inutile d'alourdir le débat ici avec des UB de magnitudes ou de
débordements), mais à mes yeux, l'expression est *différente* avant d'être
*formelle et préférable*.
Et je sais tout cela depuis longtemps. Je suis précisément, en ce moment,
dans ce bain là, notamment en ce qui concerne les flottants car j'ai
justement besoin de représenter des quantités astronomiques (de l'ordre de
l'année-lumière par rapport au centimètre) et étant donné mes pré-requis, je
vais devoir tricher (les doubles ne résolvent pas le problème).
Lorsque tu écris a - b - c, tu ne sauras _jamais_ si le type qui a
codé ça l'a fait en toute connaissance de cause alors que si tu
avais (a - b) - c ou a - (b + c), tu n'aurais plus aucun doute.
Lorsque tu écris a - b - c, tu ne sauras _jamais_ si le type qui a
codé ça l'a fait en toute connaissance de cause alors que si tu
avais (a - b) - c ou a - (b + c), tu n'aurais plus aucun doute.
Lorsque tu écris a - b - c, tu ne sauras _jamais_ si le type qui a
codé ça l'a fait en toute connaissance de cause alors que si tu
avais (a - b) - c ou a - (b + c), tu n'aurais plus aucun doute.
Le 9 septembre 2010, Alexandre Bacquart a écrit :Par contre, je crois que des formulation comme (a-b)-c ou a-(b+c) sont
effectivement auto-documentées, rajoutant explicitement une information
C'est surtout vrai lorsque, comme dans le premier cas, elles sont
syntaxiquement inutiles, donc n'ont de portée sémantique qu'à
destination de celui qui lit, comme n'importe quel commentaire.
Je partage ton avis sur le premier cas, mais pour le deuxième, c'est
le changement d'expression qui est susceptible de me gêner dans
certains contextes. J'ai bien dit "susceptible".
Il me semble que le point de vue de JKB est : a-b-c montre que le
programmeur ne s'est pas posé la question des cas limites, contrairement
à a-(b+c) ou (a-b)-c. Les deux dernières sont donc préférables à la
première, mais (et il me semble que c'est ce sur quoi tu insistes) un
mainteneur ne devrait pas remplacer a-b-c par a-(b+c) *uniquement* pour
améliorer la lisibilité, il ne peut pas se passer de scruter les cas
limites.Oui, le résultat est le même puisqu'on est dans R (passons le fait que
strictement, l'équivalence est fausse et qu'on est pas totalement dans
R, inutile d'alourdir le débat ici avec des UB de magnitudes ou de
débordements), mais à mes yeux, l'expression est *différente* avant
d'être *formelle et préférable*.
Dans R, a-b-c=a-(b+c) et quelqu'un qui utilise couramment les maths
n'interprétera pas différemment les deux formes.
La différence cruciale apparaît en analyse numérique avec les cas
limites, qui ne sont absolument pas des /undefined behaviours/ soit dit
en passant !Et je sais tout cela depuis longtemps. Je suis précisément, en ce
moment, dans ce bain là, notamment en ce qui concerne les flottants
car j'ai justement besoin de représenter des quantités astronomiques
(de l'ordre de l'année-lumière par rapport au centimètre) et étant
donné mes pré-requis, je vais devoir tricher (les doubles ne résolvent
pas le problème).
Et les long double ? Sur mon système LDBL_DIG=.
Le 9 septembre 2010, Alexandre Bacquart a écrit :
Par contre, je crois que des formulation comme (a-b)-c ou a-(b+c) sont
effectivement auto-documentées, rajoutant explicitement une information
C'est surtout vrai lorsque, comme dans le premier cas, elles sont
syntaxiquement inutiles, donc n'ont de portée sémantique qu'à
destination de celui qui lit, comme n'importe quel commentaire.
Je partage ton avis sur le premier cas, mais pour le deuxième, c'est
le changement d'expression qui est susceptible de me gêner dans
certains contextes. J'ai bien dit "susceptible".
Il me semble que le point de vue de JKB est : a-b-c montre que le
programmeur ne s'est pas posé la question des cas limites, contrairement
à a-(b+c) ou (a-b)-c. Les deux dernières sont donc préférables à la
première, mais (et il me semble que c'est ce sur quoi tu insistes) un
mainteneur ne devrait pas remplacer a-b-c par a-(b+c) *uniquement* pour
améliorer la lisibilité, il ne peut pas se passer de scruter les cas
limites.
Oui, le résultat est le même puisqu'on est dans R (passons le fait que
strictement, l'équivalence est fausse et qu'on est pas totalement dans
R, inutile d'alourdir le débat ici avec des UB de magnitudes ou de
débordements), mais à mes yeux, l'expression est *différente* avant
d'être *formelle et préférable*.
Dans R, a-b-c=a-(b+c) et quelqu'un qui utilise couramment les maths
n'interprétera pas différemment les deux formes.
La différence cruciale apparaît en analyse numérique avec les cas
limites, qui ne sont absolument pas des /undefined behaviours/ soit dit
en passant !
Et je sais tout cela depuis longtemps. Je suis précisément, en ce
moment, dans ce bain là, notamment en ce qui concerne les flottants
car j'ai justement besoin de représenter des quantités astronomiques
(de l'ordre de l'année-lumière par rapport au centimètre) et étant
donné mes pré-requis, je vais devoir tricher (les doubles ne résolvent
pas le problème).
Et les long double ? Sur mon système LDBL_DIG=.
Le 9 septembre 2010, Alexandre Bacquart a écrit :Par contre, je crois que des formulation comme (a-b)-c ou a-(b+c) sont
effectivement auto-documentées, rajoutant explicitement une information
C'est surtout vrai lorsque, comme dans le premier cas, elles sont
syntaxiquement inutiles, donc n'ont de portée sémantique qu'à
destination de celui qui lit, comme n'importe quel commentaire.
Je partage ton avis sur le premier cas, mais pour le deuxième, c'est
le changement d'expression qui est susceptible de me gêner dans
certains contextes. J'ai bien dit "susceptible".
Il me semble que le point de vue de JKB est : a-b-c montre que le
programmeur ne s'est pas posé la question des cas limites, contrairement
à a-(b+c) ou (a-b)-c. Les deux dernières sont donc préférables à la
première, mais (et il me semble que c'est ce sur quoi tu insistes) un
mainteneur ne devrait pas remplacer a-b-c par a-(b+c) *uniquement* pour
améliorer la lisibilité, il ne peut pas se passer de scruter les cas
limites.Oui, le résultat est le même puisqu'on est dans R (passons le fait que
strictement, l'équivalence est fausse et qu'on est pas totalement dans
R, inutile d'alourdir le débat ici avec des UB de magnitudes ou de
débordements), mais à mes yeux, l'expression est *différente* avant
d'être *formelle et préférable*.
Dans R, a-b-c=a-(b+c) et quelqu'un qui utilise couramment les maths
n'interprétera pas différemment les deux formes.
La différence cruciale apparaît en analyse numérique avec les cas
limites, qui ne sont absolument pas des /undefined behaviours/ soit dit
en passant !Et je sais tout cela depuis longtemps. Je suis précisément, en ce
moment, dans ce bain là, notamment en ce qui concerne les flottants
car j'ai justement besoin de représenter des quantités astronomiques
(de l'ordre de l'année-lumière par rapport au centimètre) et étant
donné mes pré-requis, je vais devoir tricher (les doubles ne résolvent
pas le problème).
Et les long double ? Sur mon système LDBL_DIG=.
Cela dépend complètement des gens : beaucoup de programmeurs C se
plaignent et préféreraient le contraire, que & (et aussi << et >>)
soient plus prioritaires qu'ils ne le sont en C. En particulier plus
prioritaires que les opérateurs de comparaison, comme dans
if (a&mask == b&mask) /* effet surprenant en C... */
Cela dépend complètement des gens : beaucoup de programmeurs C se
plaignent et préféreraient le contraire, que & (et aussi << et >>)
soient plus prioritaires qu'ils ne le sont en C. En particulier plus
prioritaires que les opérateurs de comparaison, comme dans
if (a&mask == b&mask) /* effet surprenant en C... */
Cela dépend complètement des gens : beaucoup de programmeurs C se
plaignent et préféreraient le contraire, que & (et aussi << et >>)
soient plus prioritaires qu'ils ne le sont en C. En particulier plus
prioritaires que les opérateurs de comparaison, comme dans
if (a&mask == b&mask) /* effet surprenant en C... */
JKB, le 09/09/2010 a écrit :
[...]Lorsque tu écris a - b - c, tu ne sauras _jamais_ si le type qui a
codé ça l'a fait en toute connaissance de cause alors que si tu
avais (a - b) - c ou a - (b + c), tu n'aurais plus aucun doute.
Et si /le type/ code (a - b - c), vous en déduisez que logiquement:
- /le type/ a codé /en toute connaissance de cause/.
- /le type/ est un peu tordu, ou simplement mutin.
?
JKB, le 09/09/2010 a écrit :
[...]
Lorsque tu écris a - b - c, tu ne sauras _jamais_ si le type qui a
codé ça l'a fait en toute connaissance de cause alors que si tu
avais (a - b) - c ou a - (b + c), tu n'aurais plus aucun doute.
Et si /le type/ code (a - b - c), vous en déduisez que logiquement:
- /le type/ a codé /en toute connaissance de cause/.
- /le type/ est un peu tordu, ou simplement mutin.
?
JKB, le 09/09/2010 a écrit :
[...]Lorsque tu écris a - b - c, tu ne sauras _jamais_ si le type qui a
codé ça l'a fait en toute connaissance de cause alors que si tu
avais (a - b) - c ou a - (b + c), tu n'aurais plus aucun doute.
Et si /le type/ code (a - b - c), vous en déduisez que logiquement:
- /le type/ a codé /en toute connaissance de cause/.
- /le type/ est un peu tordu, ou simplement mutin.
?
Dans l'article <i682vb$98r$,
Antoine Leca écrit:Cela dépend complètement des gens : beaucoup de programmeurs C se
plaignent et préféreraient le contraire, que & (et aussi << et >>)
soient plus prioritaires qu'ils ne le sont en C. En particulier plus
prioritaires que les opérateurs de comparaison, comme dans
if (a&mask == b&mask) /* effet surprenant en C... */
Oui, et heureusement que le C n'a pas d'opérateur puissance.
Mais la précédence du - unaire sur * et / est aussi surprenante.
Dans l'article <i682vb$98r$1@shakotay.alphanet.ch>,
Antoine Leca <root@localhost.invalid> écrit:
Cela dépend complètement des gens : beaucoup de programmeurs C se
plaignent et préféreraient le contraire, que & (et aussi << et >>)
soient plus prioritaires qu'ils ne le sont en C. En particulier plus
prioritaires que les opérateurs de comparaison, comme dans
if (a&mask == b&mask) /* effet surprenant en C... */
Oui, et heureusement que le C n'a pas d'opérateur puissance.
Mais la précédence du - unaire sur * et / est aussi surprenante.
Dans l'article <i682vb$98r$,
Antoine Leca écrit:Cela dépend complètement des gens : beaucoup de programmeurs C se
plaignent et préféreraient le contraire, que & (et aussi << et >>)
soient plus prioritaires qu'ils ne le sont en C. En particulier plus
prioritaires que les opérateurs de comparaison, comme dans
if (a&mask == b&mask) /* effet surprenant en C... */
Oui, et heureusement que le C n'a pas d'opérateur puissance.
Mais la précédence du - unaire sur * et / est aussi surprenante.
Il ne faut pas confondre l'ensemble R des réels en mathématique et les
nombres flottants en programmation. Les deux domaines n'ont pas
grand-chose en commun. La première chose que nous a dite le prof
d'informatique, à la première heure de cours (c'était en 1970 pour ce
qui me concerne) c'est : "vous pouvez demander beaucoup de choses à un
ordinateur mais pas de stocker racine carrée de 2". Il n'y a pas de
nombres irrationnels en informatique !
Il ne faut pas confondre l'ensemble R des réels en mathématique et les
nombres flottants en programmation. Les deux domaines n'ont pas
grand-chose en commun. La première chose que nous a dite le prof
d'informatique, à la première heure de cours (c'était en 1970 pour ce
qui me concerne) c'est : "vous pouvez demander beaucoup de choses à un
ordinateur mais pas de stocker racine carrée de 2". Il n'y a pas de
nombres irrationnels en informatique !
Il ne faut pas confondre l'ensemble R des réels en mathématique et les
nombres flottants en programmation. Les deux domaines n'ont pas
grand-chose en commun. La première chose que nous a dite le prof
d'informatique, à la première heure de cours (c'était en 1970 pour ce
qui me concerne) c'est : "vous pouvez demander beaucoup de choses à un
ordinateur mais pas de stocker racine carrée de 2". Il n'y a pas de
nombres irrationnels en informatique !
La première chose que nous a dite le prof
d'informatique, à la première heure de cours (c'était en 1970 pour ce
qui me concerne) c'est : "vous pouvez demander beaucoup de choses à un
ordinateur mais pas de stocker racine carrée de 2". Il n'y a pas de
nombres irrationnels en informatique !
La première chose que nous a dite le prof
d'informatique, à la première heure de cours (c'était en 1970 pour ce
qui me concerne) c'est : "vous pouvez demander beaucoup de choses à un
ordinateur mais pas de stocker racine carrée de 2". Il n'y a pas de
nombres irrationnels en informatique !
La première chose que nous a dite le prof
d'informatique, à la première heure de cours (c'était en 1970 pour ce
qui me concerne) c'est : "vous pouvez demander beaucoup de choses à un
ordinateur mais pas de stocker racine carrée de 2". Il n'y a pas de
nombres irrationnels en informatique !
Dans quasiment tous les langages de programmation les opérateurs unaires
sont plus prioritaires que les opérateurs d'arité supérieure.
Quoi qu'il en soit, je ne comprends pas pourquoi tu dis que c'est
"surprenant".
Dans quasiment tous les langages de programmation les opérateurs unaires
sont plus prioritaires que les opérateurs d'arité supérieure.
Quoi qu'il en soit, je ne comprends pas pourquoi tu dis que c'est
"surprenant".
Dans quasiment tous les langages de programmation les opérateurs unaires
sont plus prioritaires que les opérateurs d'arité supérieure.
Quoi qu'il en soit, je ne comprends pas pourquoi tu dis que c'est
"surprenant".
Dans l'article <4c88b292$0$5433$,
Wykaaa écrit:Dans quasiment tous les langages de programmation les opérateurs unaires
sont plus prioritaires que les opérateurs d'arité supérieure.
Quoi qu'il en soit, je ne comprends pas pourquoi tu dis que c'est
"surprenant".
Parce que c'est contraire à l'écriture mathématique. En C, le problème
est peu visible, car il n'y a pas d'opérateur puissance, mais dans un
langage avec ^ qui signifie puissance, je m'attends à ce que -3^2
donne -9 et non 9 (surtout dans les logiciels de calcul formel), car
c'est la règle mathématique.
En C, je m'attendrais à ce que - a * b et 0 - a * b donnent la même
chose (en supposant a * b non nul), mais si le mode d'arrondi est
vers -inf ou +inf, il peut y avoir une différence.
Dans l'article <4c88b292$0$5433$ba4acef3@reader.news.orange.fr>,
Wykaaa <wykaaa@yahoo.fr> écrit:
Dans quasiment tous les langages de programmation les opérateurs unaires
sont plus prioritaires que les opérateurs d'arité supérieure.
Quoi qu'il en soit, je ne comprends pas pourquoi tu dis que c'est
"surprenant".
Parce que c'est contraire à l'écriture mathématique. En C, le problème
est peu visible, car il n'y a pas d'opérateur puissance, mais dans un
langage avec ^ qui signifie puissance, je m'attends à ce que -3^2
donne -9 et non 9 (surtout dans les logiciels de calcul formel), car
c'est la règle mathématique.
En C, je m'attendrais à ce que - a * b et 0 - a * b donnent la même
chose (en supposant a * b non nul), mais si le mode d'arrondi est
vers -inf ou +inf, il peut y avoir une différence.
Dans l'article <4c88b292$0$5433$,
Wykaaa écrit:Dans quasiment tous les langages de programmation les opérateurs unaires
sont plus prioritaires que les opérateurs d'arité supérieure.
Quoi qu'il en soit, je ne comprends pas pourquoi tu dis que c'est
"surprenant".
Parce que c'est contraire à l'écriture mathématique. En C, le problème
est peu visible, car il n'y a pas d'opérateur puissance, mais dans un
langage avec ^ qui signifie puissance, je m'attends à ce que -3^2
donne -9 et non 9 (surtout dans les logiciels de calcul formel), car
c'est la règle mathématique.
En C, je m'attendrais à ce que - a * b et 0 - a * b donnent la même
chose (en supposant a * b non nul), mais si le mode d'arrondi est
vers -inf ou +inf, il peut y avoir une différence.