je lis partout le terme "d'associativit=E9" des op=E9rateurs ainsi que le
teme de "priorit=E9" des op=E9rateurs je pense avoir compris celui de la
priorit=E9 mais cette notion d'associativit=E9 reste tr=E8s (trop) floue
pour moi et je ne trouve rien qui l'explique clairement sur le net.
In article <4c85518e$0$23248$, Samuel DEVULDER 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), parce qu'il n'y a aucune raison d'envoyer le F sur 0 plutot que sur 1... La structure d'algebre de Boole a une symetrie que ne possede pas l'algebre arithmetique classique. Bonne chance pour trouver un morphisme naturel dans ces conditions.
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), parce qu'il n'y a aucune raison d'envoyer
le F sur 0 plutot que sur 1... La structure d'algebre de Boole a une symetrie
que ne possede pas l'algebre arithmetique classique. Bonne chance pour trouver
un morphisme naturel dans ces conditions.
In article <4c85518e$0$23248$, Samuel DEVULDER 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), parce qu'il n'y a aucune raison d'envoyer le F sur 0 plutot que sur 1... La structure d'algebre de Boole a une symetrie que ne possede pas l'algebre arithmetique classique. Bonne chance pour trouver un morphisme naturel dans ces conditions.
Erwan David
(Marc Espie) écrivait :
In article <4c85518e$0$23248$, Samuel DEVULDER 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), parce qu'il n'y a aucune raison d'envoyer le F sur 0 plutot que sur 1... La structure d'algebre de Boole a une symetrie que ne possede pas l'algebre arithmetique classique. Bonne chance pour trouver un morphisme naturel dans ces conditions.
Humm, et avec un morphisme dans Z/2Z, avec xor envoyé sur + et | envoyé sur la multiplication.
Mais pas le &...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
espie@lain.home (Marc Espie) écrivait :
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), parce qu'il n'y a aucune raison d'envoyer
le F sur 0 plutot que sur 1... La structure d'algebre de Boole a une symetrie
que ne possede pas l'algebre arithmetique classique. Bonne chance pour trouver
un morphisme naturel dans ces conditions.
Humm, et avec un morphisme dans Z/2Z, avec xor envoyé sur + et | envoyé
sur la multiplication.
Mais pas le &...
--
Le travail n'est pas une bonne chose. Si ça l'était,
les riches l'auraient accaparé
In article <4c85518e$0$23248$, Samuel DEVULDER 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), parce qu'il n'y a aucune raison d'envoyer le F sur 0 plutot que sur 1... La structure d'algebre de Boole a une symetrie que ne possede pas l'algebre arithmetique classique. Bonne chance pour trouver un morphisme naturel dans ces conditions.
Humm, et avec un morphisme dans Z/2Z, avec xor envoyé sur + et | envoyé sur la multiplication.
Mais pas le &...
-- Le travail n'est pas une bonne chose. Si ça l'était, les riches l'auraient accaparé
espie
In article <4c85775f$0$20969$, Samuel DEVULDER wrote:
Le 06/09/2010 23:32, Marc Espie a écrit :
In article<4c85518e$0$23248$, Samuel DEVULDER 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. Et "categories for the working mathematician" pour les gens interesses par le cote mathematique.
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.
Et "categories for the working mathematician" pour les gens interesses
par le cote mathematique.
In article <4c85775f$0$20969$, Samuel DEVULDER wrote:
Le 06/09/2010 23:32, Marc Espie a écrit :
In article<4c85518e$0$23248$, Samuel DEVULDER 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. Et "categories for the working mathematician" pour les gens interesses par le cote mathematique.
Damien Wyart
* Samuel DEVULDER in fr.comp.lang.c:
PS: y a t'il un cours, une présentation succincte, qui explique les catégories pour les nuls?
Queles pistes de lecture, la première étant sans doute la plus adaptée pour débuter :
_Categories for the working mathematician_ est effectivement une référence mais assez condensé, très technique et d'un niveau élevé donc pour une introduction, ça me semble peu adapté et ça ne parle pas du tout des applications informatiques de la théorie.
Est-ce que: http://www.emis.de/journals/BAMV/conten/vol9/jeanyves.pdf est mieux?
Cela semble sérieux et l'auteur a des publications dans le domaine, mais cet article est vraiment très axé sur les aspects fondations des mathématiques et histoire de ces fondations, donc ça ne correspond pas bien à ce que tu recherches.
-- DW
* Samuel DEVULDER <samuel-dot-devulder@laposte-dot-com> in fr.comp.lang.c:
PS: y a t'il un cours, une présentation succincte, qui explique les
catégories pour les nuls?
Queles pistes de lecture, la première étant sans doute la plus adaptée
pour débuter :
_Categories for the working mathematician_ est effectivement une
référence mais assez condensé, très technique et d'un niveau élevé donc
pour une introduction, ça me semble peu adapté et ça ne parle pas du
tout des applications informatiques de la théorie.
Est-ce que:
http://www.emis.de/journals/BAMV/conten/vol9/jeanyves.pdf
est mieux?
Cela semble sérieux et l'auteur a des publications dans le domaine, mais
cet article est vraiment très axé sur les aspects fondations des
mathématiques et histoire de ces fondations, donc ça ne correspond pas
bien à ce que tu recherches.
_Categories for the working mathematician_ est effectivement une référence mais assez condensé, très technique et d'un niveau élevé donc pour une introduction, ça me semble peu adapté et ça ne parle pas du tout des applications informatiques de la théorie.
Est-ce que: http://www.emis.de/journals/BAMV/conten/vol9/jeanyves.pdf est mieux?
Cela semble sérieux et l'auteur a des publications dans le domaine, mais cet article est vraiment très axé sur les aspects fondations des mathématiques et histoire de ces fondations, donc ça ne correspond pas bien à ce que tu recherches.
-- DW
Damien Wyart
> PS: y a t'il un cours, une présentation succincte, qui explique les > catégories pour les nuls?
Queles pistes de lecture, la première étant sans doute la plus adaptée pour débuter :
Egalement ceci, assez technique également mais bien présenté :
Le Mon, 6 Sep 2010 15:15:50 +0000 (UTC), Marc Boyer écrivait :
Le 06-09-2010, JKB a écrit :
Le Mon, 6 Sep 2010 14:28:54 +0000 (UTC), Marc Espie écrivait :
In article , JKB <invalid> wrote:
CC /ANSI est _ANSI_ et NULL vaut 0x0. CC tout court n'est pas _ANSI_ et NULL vaut 0x1.
Mais on pourrait faire un compilo ANSI où NULL vaut 0x1. Que CC ne sache pas le faire me semble un pb de qualité.
Il y a une raison à ça. Et dire que NULL vaut 0x1 risque de mettre le bazar dans toutes les expressions du style if (ptr) { }
Il y a une ambiguité dans "vaut 0x1".
On peut avoir une valeur binaire 0x1, et des conversions implicites qui permettent de réaliser le test.
En gros int * p= NULL; unsigned i= 0x1; assert( sizeof(int*) == sizeof(unsigned) && memcmp( &p , &i , sizeof( p ) ) == 0 && p );
De même que le compilo sait que quand il voit p+5 il doit faire un accès indexé dont le décalage dépend de la taille sizeof(*p), il devrait être capable de voir que quand un pointeur est dans un contexte numérique, il faut convertir sa représentation interne de NULL en 0.
Donc, on peut avoir une représentation interne de NULL qui soit 0x1 sans faire planter les expressions if (prt) { ...} c'est juste un pb de qualité du compilo.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Le 06-09-2010, JKB <jkb@koenigsberg.invalid> a écrit :
Le Mon, 6 Sep 2010 15:15:50 +0000 (UTC),
Marc Boyer <Marc.Boyer@cert.onera.fr.invalid> écrivait :
Le 06-09-2010, JKB <jkb@koenigsberg.invalid> a écrit :
Le Mon, 6 Sep 2010 14:28:54 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <slrni89tij.tg1.jkb@rayleigh.systella.fr>, JKB <invalid> wrote:
CC /ANSI est _ANSI_ et NULL vaut 0x0.
CC tout court n'est pas _ANSI_ et NULL vaut 0x1.
Mais on pourrait faire un compilo ANSI où NULL vaut 0x1.
Que CC ne sache pas le faire me semble un pb de qualité.
Il y a une raison à ça. Et dire que NULL vaut 0x1 risque de mettre
le bazar dans toutes les expressions du style if (ptr) { }
Il y a une ambiguité dans "vaut 0x1".
On peut avoir une valeur binaire 0x1, et des conversions implicites
qui permettent de réaliser le test.
En gros
int * p= NULL;
unsigned i= 0x1;
assert( sizeof(int*) == sizeof(unsigned)
&& memcmp( &p , &i , sizeof( p ) ) == 0
&& p );
De même que le compilo sait que quand il voit
p+5
il doit faire un accès indexé dont le décalage dépend
de la taille sizeof(*p), il devrait être capable de voir
que quand un pointeur est dans un contexte numérique,
il faut convertir sa représentation interne de NULL
en 0.
Donc, on peut avoir une représentation interne de NULL
qui soit 0x1 sans faire planter les expressions
if (prt) { ...}
c'est juste un pb de qualité du compilo.
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Le Mon, 6 Sep 2010 15:15:50 +0000 (UTC), Marc Boyer écrivait :
Le 06-09-2010, JKB a écrit :
Le Mon, 6 Sep 2010 14:28:54 +0000 (UTC), Marc Espie écrivait :
In article , JKB <invalid> wrote:
CC /ANSI est _ANSI_ et NULL vaut 0x0. CC tout court n'est pas _ANSI_ et NULL vaut 0x1.
Mais on pourrait faire un compilo ANSI où NULL vaut 0x1. Que CC ne sache pas le faire me semble un pb de qualité.
Il y a une raison à ça. Et dire que NULL vaut 0x1 risque de mettre le bazar dans toutes les expressions du style if (ptr) { }
Il y a une ambiguité dans "vaut 0x1".
On peut avoir une valeur binaire 0x1, et des conversions implicites qui permettent de réaliser le test.
En gros int * p= NULL; unsigned i= 0x1; assert( sizeof(int*) == sizeof(unsigned) && memcmp( &p , &i , sizeof( p ) ) == 0 && p );
De même que le compilo sait que quand il voit p+5 il doit faire un accès indexé dont le décalage dépend de la taille sizeof(*p), il devrait être capable de voir que quand un pointeur est dans un contexte numérique, il faut convertir sa représentation interne de NULL en 0.
Donc, on peut avoir une représentation interne de NULL qui soit 0x1 sans faire planter les expressions if (prt) { ...} c'est juste un pb de qualité du compilo.
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Marc Boyer
Le 06-09-2010, JKB a écrit :
Le Mon, 6 Sep 2010 16:12:12 +0000 (UTC), Marc Espie écrivait :
In article , JKB <invalid> wrote:
Le Mon, 06 Sep 2010 17:12:45 +0200,
Lorsque tu écris if (ptr), tu testes l'adresse pointée par ptr et tu regardes si elle est nulle, ce qui est totalement différent.
Pas en C ANSI. En C ANSI, if (prt) doit passer dans la branche "then" si prt != NULL et dans la branche else si ptr == NULL.
Et je ne vois pas comment le compilo peut s'en sortir de façon simple.
Comme dit dans un autre post, c'est pas plus compliqué que de savoir évaluer prt+8, ou sizeof( tab ) et sizeof( &tab ) quand tab est un tableau.
Bref, tant que NULL vaut 0, tout se passe pour le mieux. Lorsque ce n'est plus vrai, on commence à rigoler. Personnellement, ça fait plus de vingt ans que je me tape du C sur des systèmes bizarres et je préfère de loin une parenthèse en trop ou un test (ptr == NULL) que de rechercher des bugs à la noix dans des milliers de lignes de code.
Que DEC C ne soit pas C ANSI, et que ça t'oblige à éviter certaines contructions légales en C ANSI et pas EN DEC C, c'est tout à fait compréhensible. Mais si on programme en C ANSI, aucune raison de se priver de if (ptr).
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Le 06-09-2010, JKB <jkb@koenigsberg.invalid> a écrit :
Le Mon, 6 Sep 2010 16:12:12 +0000 (UTC),
Marc Espie <espie@lain.home> écrivait :
In article <slrni8a39n.tg1.jkb@rayleigh.systella.fr>, JKB <invalid> wrote:
Le Mon, 06 Sep 2010 17:12:45 +0200,
Lorsque tu écris if (ptr), tu testes l'adresse pointée par ptr et tu
regardes si elle est nulle, ce qui est totalement différent.
Pas en C ANSI.
En C ANSI, if (prt) doit passer dans la branche "then" si prt != NULL
et dans la branche else si ptr == NULL.
Et je ne vois pas comment le compilo peut s'en sortir de façon
simple.
Comme dit dans un autre post, c'est pas plus compliqué que de savoir évaluer
prt+8, ou sizeof( tab ) et sizeof( &tab ) quand tab est un tableau.
Bref, tant que NULL vaut 0, tout se passe pour le mieux. Lorsque ce
n'est plus vrai, on commence à rigoler. Personnellement, ça fait
plus de vingt ans que je me tape du C sur des systèmes bizarres et
je préfère de loin une parenthèse en trop ou un test (ptr == NULL)
que de rechercher des bugs à la noix dans des milliers de lignes de
code.
Que DEC C ne soit pas C ANSI, et que ça t'oblige à éviter certaines contructions
légales en C ANSI et pas EN DEC C, c'est tout à fait compréhensible.
Mais si on programme en C ANSI, aucune raison de se priver de if (ptr).
Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0
Le Mon, 6 Sep 2010 16:12:12 +0000 (UTC), Marc Espie écrivait :
In article , JKB <invalid> wrote:
Le Mon, 06 Sep 2010 17:12:45 +0200,
Lorsque tu écris if (ptr), tu testes l'adresse pointée par ptr et tu regardes si elle est nulle, ce qui est totalement différent.
Pas en C ANSI. En C ANSI, if (prt) doit passer dans la branche "then" si prt != NULL et dans la branche else si ptr == NULL.
Et je ne vois pas comment le compilo peut s'en sortir de façon simple.
Comme dit dans un autre post, c'est pas plus compliqué que de savoir évaluer prt+8, ou sizeof( tab ) et sizeof( &tab ) quand tab est un tableau.
Bref, tant que NULL vaut 0, tout se passe pour le mieux. Lorsque ce n'est plus vrai, on commence à rigoler. Personnellement, ça fait plus de vingt ans que je me tape du C sur des systèmes bizarres et je préfère de loin une parenthèse en trop ou un test (ptr == NULL) que de rechercher des bugs à la noix dans des milliers de lignes de code.
Que DEC C ne soit pas C ANSI, et que ça t'oblige à éviter certaines contructions légales en C ANSI et pas EN DEC C, c'est tout à fait compréhensible. Mais si on programme en C ANSI, aucune raison de se priver de if (ptr).
Marc Boyer -- En prenant aux 10% des francais les plus riches 12% de leurs revenus, on pourrait doubler les revenus des 10% les plus pauvres. http://www.inegalites.fr/spip.php?article1&id_mot0
Samuel DEVULDER
Le 06/09/2010 21:49, Pierre Maurette a écrit :
Samuel DEVULDER, le 06/09/2010 a écrit :
Ce que vous nommez "opération saturante", est-ce que ça correspond à: <URL: http://assembleur.maurette.free.fr/livres/livre_4061/index.php?chapitre=chap09_mmx.htm> , paragraphe 9.2.3 ?
Oui je pense: 255+1 donne 255 si on sature sur 8 bits non signés.
A ce moment là on a bien identité entre + et ||, et entre * et &&, sauf qu'il n'y a pas de short-cut dans l'évaluation: les deux cotés de l'opérateur sont évalués.
Ce que vous appelez le /short-cut/, c'est l'évaluation économique des expressions booleéennes ?
Oui aussi je pense.
sam.
Le 06/09/2010 21:49, Pierre Maurette a écrit :
Samuel DEVULDER, le 06/09/2010 a écrit :
Ce que vous nommez "opération saturante", est-ce que ça correspond à:
<URL:
http://assembleur.maurette.free.fr/livres/livre_4061/index.php?chapitre=chap09_mmx.htm>
, paragraphe 9.2.3 ?
Oui je pense: 255+1 donne 255 si on sature sur 8 bits non signés.
A ce moment là on a bien identité entre + et ||, et entre * et &&,
sauf qu'il n'y a pas de short-cut dans l'évaluation: les deux cotés de
l'opérateur sont évalués.
Ce que vous appelez le /short-cut/, c'est l'évaluation économique des
expressions booleéennes ?
Ce que vous nommez "opération saturante", est-ce que ça correspond à: <URL: http://assembleur.maurette.free.fr/livres/livre_4061/index.php?chapitre=chap09_mmx.htm> , paragraphe 9.2.3 ?
Oui je pense: 255+1 donne 255 si on sature sur 8 bits non signés.
A ce moment là on a bien identité entre + et ||, et entre * et &&, sauf qu'il n'y a pas de short-cut dans l'évaluation: les deux cotés de l'opérateur sont évalués.
Ce que vous appelez le /short-cut/, c'est l'évaluation économique des expressions booleéennes ?
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.
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 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.
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 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.
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 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.
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.
Ma comprehension de 5.1.2.3 est que a-b-c ne peut etre implemente autrement que comme (a-b)-c que si le compilateur sait que les deux manieres sont equivalentes. Antoine confirmera ou infirmera peut-etre, il me semble que c'est un changement du C normalise par rapport au C K&R.
Si j'ai bonne memoire en Fortran ce n'est pas le cas et le compilateur peut utiliser l'associativite tant qu'elle n'est pas supprimees avec des parentheses supperflues.
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
Vincent Lefevre <vincent-news@vinc17.net> writes:
Dans l'article <pxbhbi3p7gl.fsf@news.bourguet.org>,
Jean-Marc Bourguet <jm@bourguet.org> écrit:
> 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.
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.
Ma comprehension de 5.1.2.3 est que a-b-c ne peut etre implemente autrement
que comme (a-b)-c que si le compilateur sait que les deux manieres sont
equivalentes. Antoine confirmera ou infirmera peut-etre, il me semble que
c'est un changement du C normalise par rapport au C K&R.
Si j'ai bonne memoire en Fortran ce n'est pas le cas et le compilateur peut
utiliser l'associativite tant qu'elle n'est pas supprimees avec des
parentheses supperflues.
A+
--
Jean-Marc
FAQ de fclc: http://www.levenez.com/lang/c/faq
Site de usenet-fr: http://www.usenet-fr.news.eu.org
> 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.
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.
Ma comprehension de 5.1.2.3 est que a-b-c ne peut etre implemente autrement que comme (a-b)-c que si le compilateur sait que les deux manieres sont equivalentes. Antoine confirmera ou infirmera peut-etre, il me semble que c'est un changement du C normalise par rapport au C K&R.
Si j'ai bonne memoire en Fortran ce n'est pas le cas et le compilateur peut utiliser l'associativite tant qu'elle n'est pas supprimees avec des parentheses supperflues.
A+
-- Jean-Marc FAQ de fclc: http://www.levenez.com/lang/c/faq Site de usenet-fr: http://www.usenet-fr.news.eu.org
