Tous vos entierzs sont positifs, déclarez-les donc unsigned.
Tous vos entierzs sont positifs, déclarez-les donc unsigned.
Tous vos entierzs sont positifs, déclarez-les donc unsigned.
"Rincevent" typa:5) Pour la particules appartenant à la k-ème classe, sa couleur est
donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas forcément
un entier, on prends donc la partie entière pour être sur...
Tous vos entiers sont positifs, déclarez-les donc unsigned.
N est une constante, apparemment, ainsi que P pendant le calcul. Votre
problème esr ainsi simplifié :
int resultat = (k*N)/P; //c'est tout
ou même
int resultat = (k<<8)/P;
que devrait vous générer le compilateur si vous avez déclaré N const.
"Rincevent" <rincevent@nospam.fr> typa:
5) Pour la particules appartenant à la k-ème classe, sa couleur est
donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas forcément
un entier, on prends donc la partie entière pour être sur...
Tous vos entiers sont positifs, déclarez-les donc unsigned.
N est une constante, apparemment, ainsi que P pendant le calcul. Votre
problème esr ainsi simplifié :
int resultat = (k*N)/P; //c'est tout
ou même
int resultat = (k<<8)/P;
que devrait vous générer le compilateur si vous avez déclaré N const.
"Rincevent" typa:5) Pour la particules appartenant à la k-ème classe, sa couleur est
donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas forcément
un entier, on prends donc la partie entière pour être sur...
Tous vos entiers sont positifs, déclarez-les donc unsigned.
N est une constante, apparemment, ainsi que P pendant le calcul. Votre
problème esr ainsi simplifié :
int resultat = (k*N)/P; //c'est tout
ou même
int resultat = (k<<8)/P;
que devrait vous générer le compilateur si vous avez déclaré N const.
"Rincevent" typa:g un gros problème dans mon programme C++.
Voilà g 3 entier a,b et c
Je souhaite calculer la partie entière de (a/b)*c
J'utilise pour cela la fonction floor() de <cmath>
Or deux problèmes se présentent :
1) Le compilateur renvoie 0 lorsque je lui demande de calculer
(a/b)*c (et ce, alors que les valeurs de a,b,c ne devraient pas
donner un tel résultat)
Comment faites-vous pour mener ce calcul de tête ou avec papier-crayon
? Commencez-vous par diviser ? Avez vous besoin de flottants pour
traiter le problème ?
Si vous faites :
int resultat = (a*c)/b;
vous traitez exactement le problème tel qu'il est posé, c'est à dire
comme un problème d'entiers.
Je vous laisse, par rapport à ce que vous souhaitez, juger de
l'oportunité d'un ajustement par floor(). Personnellement, je ne
l'utiliserais pas, puisque c'est une fonction double.
Mais bon, personnellement, je trouve regrettable l'utilisation de /
pour la division entière, j'aime bien le couple div mod du Pascal.
Il est aussi rapide et plus naturel de tester le signe (et
malheureusement je pense qu'il faudra également tester le résultat
exact, le cas ou a*c est divisible par b) pour ajuster le résultat.
Mais le résultat direct correspond à l'idée que je me fais d'une
partie entière.
"Rincevent" <rincevent@nospam.fr> typa:
g un gros problème dans mon programme C++.
Voilà g 3 entier a,b et c
Je souhaite calculer la partie entière de (a/b)*c
J'utilise pour cela la fonction floor() de <cmath>
Or deux problèmes se présentent :
1) Le compilateur renvoie 0 lorsque je lui demande de calculer
(a/b)*c (et ce, alors que les valeurs de a,b,c ne devraient pas
donner un tel résultat)
Comment faites-vous pour mener ce calcul de tête ou avec papier-crayon
? Commencez-vous par diviser ? Avez vous besoin de flottants pour
traiter le problème ?
Si vous faites :
int resultat = (a*c)/b;
vous traitez exactement le problème tel qu'il est posé, c'est à dire
comme un problème d'entiers.
Je vous laisse, par rapport à ce que vous souhaitez, juger de
l'oportunité d'un ajustement par floor(). Personnellement, je ne
l'utiliserais pas, puisque c'est une fonction double.
Mais bon, personnellement, je trouve regrettable l'utilisation de /
pour la division entière, j'aime bien le couple div mod du Pascal.
Il est aussi rapide et plus naturel de tester le signe (et
malheureusement je pense qu'il faudra également tester le résultat
exact, le cas ou a*c est divisible par b) pour ajuster le résultat.
Mais le résultat direct correspond à l'idée que je me fais d'une
partie entière.
"Rincevent" typa:g un gros problème dans mon programme C++.
Voilà g 3 entier a,b et c
Je souhaite calculer la partie entière de (a/b)*c
J'utilise pour cela la fonction floor() de <cmath>
Or deux problèmes se présentent :
1) Le compilateur renvoie 0 lorsque je lui demande de calculer
(a/b)*c (et ce, alors que les valeurs de a,b,c ne devraient pas
donner un tel résultat)
Comment faites-vous pour mener ce calcul de tête ou avec papier-crayon
? Commencez-vous par diviser ? Avez vous besoin de flottants pour
traiter le problème ?
Si vous faites :
int resultat = (a*c)/b;
vous traitez exactement le problème tel qu'il est posé, c'est à dire
comme un problème d'entiers.
Je vous laisse, par rapport à ce que vous souhaitez, juger de
l'oportunité d'un ajustement par floor(). Personnellement, je ne
l'utiliserais pas, puisque c'est une fonction double.
Mais bon, personnellement, je trouve regrettable l'utilisation de /
pour la division entière, j'aime bien le couple div mod du Pascal.
Il est aussi rapide et plus naturel de tester le signe (et
malheureusement je pense qu'il faudra également tester le résultat
exact, le cas ou a*c est divisible par b) pour ajuster le résultat.
Mais le résultat direct correspond à l'idée que je me fais d'une
partie entière.
5) Pour la particules appartenant à la k-ème classe, sa couleur est donc
(canoniquement) donnée par (k/P)*N
5) Pour la particules appartenant à la k-ème classe, sa couleur est donc
(canoniquement) donnée par (k/P)*N
5) Pour la particules appartenant à la k-ème classe, sa couleur est donc
(canoniquement) donnée par (k/P)*N
Pierre Maurette writes:
[...]
Si vous faites :
int resultat = (a*c)/b;
vous traitez exactement le problème tel qu'il est posé, c'est à dire
comme un problème d'entiers.
Et qu'advient-il lorsque
a == std::numeric_limits< int >::max() ;
Oui. J'avais fait des hypothèses sur le problème qui n'étaient pas
? En fait, je suis en train de me demander s'il n'y a pas conversion
du résultat de « a * c » en un long int dans ce cas, mais je ne pense
pas ; et ce ne ferait que déplacer le problème. Tandis que
int result = static_cast< int >(
static_cast< double >( a ) / b * c
) ;
gère correctement le problème.
Je trouve dommage de passer par des double si le contexte rend cette
Pour ce qui est de la promotion en long int, je n'ai trouvé que
4.5/1. Je ne suis pas certain qu'il s'agit du bon paragraphe, mais si
c'est le cas, cette promotion en long int n'existe pas (ce que je
pense).
Il me semble également qu'il ne doit pas y avoir de promotion int ->
Pierre Maurette <maurette.pierre@free.fr> writes:
[...]
Si vous faites :
int resultat = (a*c)/b;
vous traitez exactement le problème tel qu'il est posé, c'est à dire
comme un problème d'entiers.
Et qu'advient-il lorsque
a == std::numeric_limits< int >::max() ;
Oui. J'avais fait des hypothèses sur le problème qui n'étaient pas
? En fait, je suis en train de me demander s'il n'y a pas conversion
du résultat de « a * c » en un long int dans ce cas, mais je ne pense
pas ; et ce ne ferait que déplacer le problème. Tandis que
int result = static_cast< int >(
static_cast< double >( a ) / b * c
) ;
gère correctement le problème.
Je trouve dommage de passer par des double si le contexte rend cette
Pour ce qui est de la promotion en long int, je n'ai trouvé que
4.5/1. Je ne suis pas certain qu'il s'agit du bon paragraphe, mais si
c'est le cas, cette promotion en long int n'existe pas (ce que je
pense).
Il me semble également qu'il ne doit pas y avoir de promotion int ->
Pierre Maurette writes:
[...]
Si vous faites :
int resultat = (a*c)/b;
vous traitez exactement le problème tel qu'il est posé, c'est à dire
comme un problème d'entiers.
Et qu'advient-il lorsque
a == std::numeric_limits< int >::max() ;
Oui. J'avais fait des hypothèses sur le problème qui n'étaient pas
? En fait, je suis en train de me demander s'il n'y a pas conversion
du résultat de « a * c » en un long int dans ce cas, mais je ne pense
pas ; et ce ne ferait que déplacer le problème. Tandis que
int result = static_cast< int >(
static_cast< double >( a ) / b * c
) ;
gère correctement le problème.
Je trouve dommage de passer par des double si le contexte rend cette
Pour ce qui est de la promotion en long int, je n'ai trouvé que
4.5/1. Je ne suis pas certain qu'il s'agit du bon paragraphe, mais si
c'est le cas, cette promotion en long int n'existe pas (ce que je
pense).
Il me semble également qu'il ne doit pas y avoir de promotion int ->
"Rincevent" typa:g un gros problème dans mon programme C++.
Voilà g 3 entier a,b et c
Je souhaite calculer la partie entière de (a/b)*c
J'utilise pour cela la fonction floor() de <cmath>
Or deux problèmes se présentent :
1) Le compilateur renvoie 0 lorsque je lui demande de calculer
(a/b)*c (et ce, alors que les valeurs de a,b,c ne devraient pas
donner un tel résultat)
Comment faites-vous pour mener ce calcul de tête ou avec papier-crayon
? Commencez-vous par diviser ? Avez vous besoin de flottants pour
traiter le problème ?
Si vous faites :
int resultat = (a*c)/b;
vous traitez exactement le problème tel qu'il est posé, c'est à dire
comme un problème d'entiers.
Je vous laisse, par rapport à ce que vous souhaitez, juger de
l'oportunité d'un ajustement par floor(). Personnellement, je ne
l'utiliserais pas, puisque c'est une fonction double.
Mais bon, personnellement, je trouve regrettable l'utilisation de /
pour la division entière, j'aime bien le couple div mod du Pascal.
Il est aussi rapide et plus naturel de tester le signe (et
malheureusement je pense qu'il faudra également tester le résultat
exact, le cas ou a*c est divisible par b) pour ajuster le résultat.
Mais le résultat direct correspond à l'idée que je me fais d'une
partie entière.
"Rincevent" <rincevent@nospam.fr> typa:
g un gros problème dans mon programme C++.
Voilà g 3 entier a,b et c
Je souhaite calculer la partie entière de (a/b)*c
J'utilise pour cela la fonction floor() de <cmath>
Or deux problèmes se présentent :
1) Le compilateur renvoie 0 lorsque je lui demande de calculer
(a/b)*c (et ce, alors que les valeurs de a,b,c ne devraient pas
donner un tel résultat)
Comment faites-vous pour mener ce calcul de tête ou avec papier-crayon
? Commencez-vous par diviser ? Avez vous besoin de flottants pour
traiter le problème ?
Si vous faites :
int resultat = (a*c)/b;
vous traitez exactement le problème tel qu'il est posé, c'est à dire
comme un problème d'entiers.
Je vous laisse, par rapport à ce que vous souhaitez, juger de
l'oportunité d'un ajustement par floor(). Personnellement, je ne
l'utiliserais pas, puisque c'est une fonction double.
Mais bon, personnellement, je trouve regrettable l'utilisation de /
pour la division entière, j'aime bien le couple div mod du Pascal.
Il est aussi rapide et plus naturel de tester le signe (et
malheureusement je pense qu'il faudra également tester le résultat
exact, le cas ou a*c est divisible par b) pour ajuster le résultat.
Mais le résultat direct correspond à l'idée que je me fais d'une
partie entière.
"Rincevent" typa:g un gros problème dans mon programme C++.
Voilà g 3 entier a,b et c
Je souhaite calculer la partie entière de (a/b)*c
J'utilise pour cela la fonction floor() de <cmath>
Or deux problèmes se présentent :
1) Le compilateur renvoie 0 lorsque je lui demande de calculer
(a/b)*c (et ce, alors que les valeurs de a,b,c ne devraient pas
donner un tel résultat)
Comment faites-vous pour mener ce calcul de tête ou avec papier-crayon
? Commencez-vous par diviser ? Avez vous besoin de flottants pour
traiter le problème ?
Si vous faites :
int resultat = (a*c)/b;
vous traitez exactement le problème tel qu'il est posé, c'est à dire
comme un problème d'entiers.
Je vous laisse, par rapport à ce que vous souhaitez, juger de
l'oportunité d'un ajustement par floor(). Personnellement, je ne
l'utiliserais pas, puisque c'est une fonction double.
Mais bon, personnellement, je trouve regrettable l'utilisation de /
pour la division entière, j'aime bien le couple div mod du Pascal.
Il est aussi rapide et plus naturel de tester le signe (et
malheureusement je pense qu'il faudra également tester le résultat
exact, le cas ou a*c est divisible par b) pour ajuster le résultat.
Mais le résultat direct correspond à l'idée que je me fais d'une
partie entière.
Pierre Maurette wrote in message
news:..."Rincevent" typa:5) Pour la particules appartenant à la k-ème classe, sa couleur est
donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas forcément
un entier, on prends donc la partie entière pour être sur...
Tous vos entiers sont positifs, déclarez-les donc unsigned.
Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres naturels.
Le type naturel pour les calculs entiers en C/C++, c'est int. On
n'utilise d'autres types que dans les cas exceptionnels. On n'utilise
donc unsigned que dans les cas où on a besoin d'un de ces
caractèristiques particuiliers :
- Des opérations bit-à-bit ne donne pas de résultats « bizarre », même
si on manipule le bit de poids fort. (C'est surtout important pour
les décalages à droits.)
- On a besoin d'un arithmétique modulo, par exemple dans le calcul
d'un code d'hachage.
- On a besoin de ce bit supplémentaire. Pour représenter ces niveaux
de gris, par exemple, je verrais bien un unsigned char, parce que
signé, il lui faudrait un short.
Enfin, les signé et les non signé ne font pas toujours bon mélange.
Donc, quand une interface externe impose des non-signés, il est souvent
préférable d'en faire pareil, simplement pour éviter le mélange.
OK. En fait, j'utilise souvent (par défaut) le int, en l'absence
Note aussi l'effet des promotions integrales. S'il stocke ses valeurs
dans des unsigned int, dès qu'il s'en sert dans une expression, elles
seront converties en int. Utiliser par ailleurs des unsigned int
reviendra à melanger signé et non signé. Je sais que ça semble bizarre,
mais pour éviter de melanger des signé et des non signé lorsqu'on a des
unsigned char, il faut se servir de int, et non de unsigned. (C'est
beau, le C, n'est-ce pas ?)
Effectivement, c'est bien dans C++4.5.1, mais certaines conséquences
N est une constante, apparemment, ainsi que P pendant le calcul. Votre
problème esr ainsi simplifié :
int resultat = (k*N)/P; //c'est tout
ou même
int resultat = (k<<8)/P;
Jamais. Il veut multiplier, non décaler.
Surtout que je déclare resultat en int (et non unsigned int). Laisser
que devrait vous générer le compilateur si vous avez déclaré N const.
*Si* les décalages sont plus rapide que les multiplications. Ce n'est
pas toujours le cas, et j'ai déjà travaillé sur des systèmes où le
compilateur, à titre d'optimisation, convertissait les décalages en
multiplications.
En tout cas, c'est le problème du compilateur, et non le tien.
Absolument.
Pierre Maurette <maurette.pierre@free.fr> wrote in message
news:<oaa4b0p9oquthc0m4rdj870bfpfoma32ul@4ax.com>...
"Rincevent" <rincevent@nospam.fr> typa:
5) Pour la particules appartenant à la k-ème classe, sa couleur est
donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas forcément
un entier, on prends donc la partie entière pour être sur...
Tous vos entiers sont positifs, déclarez-les donc unsigned.
Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres naturels.
Le type naturel pour les calculs entiers en C/C++, c'est int. On
n'utilise d'autres types que dans les cas exceptionnels. On n'utilise
donc unsigned que dans les cas où on a besoin d'un de ces
caractèristiques particuiliers :
- Des opérations bit-à-bit ne donne pas de résultats « bizarre », même
si on manipule le bit de poids fort. (C'est surtout important pour
les décalages à droits.)
- On a besoin d'un arithmétique modulo, par exemple dans le calcul
d'un code d'hachage.
- On a besoin de ce bit supplémentaire. Pour représenter ces niveaux
de gris, par exemple, je verrais bien un unsigned char, parce que
signé, il lui faudrait un short.
Enfin, les signé et les non signé ne font pas toujours bon mélange.
Donc, quand une interface externe impose des non-signés, il est souvent
préférable d'en faire pareil, simplement pour éviter le mélange.
OK. En fait, j'utilise souvent (par défaut) le int, en l'absence
Note aussi l'effet des promotions integrales. S'il stocke ses valeurs
dans des unsigned int, dès qu'il s'en sert dans une expression, elles
seront converties en int. Utiliser par ailleurs des unsigned int
reviendra à melanger signé et non signé. Je sais que ça semble bizarre,
mais pour éviter de melanger des signé et des non signé lorsqu'on a des
unsigned char, il faut se servir de int, et non de unsigned. (C'est
beau, le C, n'est-ce pas ?)
Effectivement, c'est bien dans C++4.5.1, mais certaines conséquences
N est une constante, apparemment, ainsi que P pendant le calcul. Votre
problème esr ainsi simplifié :
int resultat = (k*N)/P; //c'est tout
ou même
int resultat = (k<<8)/P;
Jamais. Il veut multiplier, non décaler.
Surtout que je déclare resultat en int (et non unsigned int). Laisser
que devrait vous générer le compilateur si vous avez déclaré N const.
*Si* les décalages sont plus rapide que les multiplications. Ce n'est
pas toujours le cas, et j'ai déjà travaillé sur des systèmes où le
compilateur, à titre d'optimisation, convertissait les décalages en
multiplications.
En tout cas, c'est le problème du compilateur, et non le tien.
Absolument.
Pierre Maurette wrote in message
news:..."Rincevent" typa:5) Pour la particules appartenant à la k-ème classe, sa couleur est
donc (canoniquement) donnée par (k/P)*N (k/P)*N n'est pas forcément
un entier, on prends donc la partie entière pour être sur...
Tous vos entiers sont positifs, déclarez-les donc unsigned.
Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres naturels.
Le type naturel pour les calculs entiers en C/C++, c'est int. On
n'utilise d'autres types que dans les cas exceptionnels. On n'utilise
donc unsigned que dans les cas où on a besoin d'un de ces
caractèristiques particuiliers :
- Des opérations bit-à-bit ne donne pas de résultats « bizarre », même
si on manipule le bit de poids fort. (C'est surtout important pour
les décalages à droits.)
- On a besoin d'un arithmétique modulo, par exemple dans le calcul
d'un code d'hachage.
- On a besoin de ce bit supplémentaire. Pour représenter ces niveaux
de gris, par exemple, je verrais bien un unsigned char, parce que
signé, il lui faudrait un short.
Enfin, les signé et les non signé ne font pas toujours bon mélange.
Donc, quand une interface externe impose des non-signés, il est souvent
préférable d'en faire pareil, simplement pour éviter le mélange.
OK. En fait, j'utilise souvent (par défaut) le int, en l'absence
Note aussi l'effet des promotions integrales. S'il stocke ses valeurs
dans des unsigned int, dès qu'il s'en sert dans une expression, elles
seront converties en int. Utiliser par ailleurs des unsigned int
reviendra à melanger signé et non signé. Je sais que ça semble bizarre,
mais pour éviter de melanger des signé et des non signé lorsqu'on a des
unsigned char, il faut se servir de int, et non de unsigned. (C'est
beau, le C, n'est-ce pas ?)
Effectivement, c'est bien dans C++4.5.1, mais certaines conséquences
N est une constante, apparemment, ainsi que P pendant le calcul. Votre
problème esr ainsi simplifié :
int resultat = (k*N)/P; //c'est tout
ou même
int resultat = (k<<8)/P;
Jamais. Il veut multiplier, non décaler.
Surtout que je déclare resultat en int (et non unsigned int). Laisser
que devrait vous générer le compilateur si vous avez déclaré N const.
*Si* les décalages sont plus rapide que les multiplications. Ce n'est
pas toujours le cas, et j'ai déjà travaillé sur des systèmes où le
compilateur, à titre d'optimisation, convertissait les décalages en
multiplications.
En tout cas, c'est le problème du compilateur, et non le tien.
Absolument.
Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres
naturels. Le type naturel pour les calculs entiers en C/C++,
c'est int. On n'utilise d'autres types que dans les cas
exceptionnels. On n'utilise donc unsigned que dans les cas où
on a besoin d'un de ces caractèristiques particuiliers :
- Des opérations bit-à-bit ne donne pas de résultats «
bizarre », même si on manipule le bit de poids fort. (C'est
surtout important pour les décalages à droits.)
- On a besoin d'un arithmétique modulo, par exemple dans le
calcul d'un code d'hachage.
- On a besoin de ce bit supplémentaire. Pour représenter ces
niveaux de gris, par exemple, je verrais bien un unsigned
char, parce que signé, il lui faudrait un short.
Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres
naturels. Le type naturel pour les calculs entiers en C/C++,
c'est int. On n'utilise d'autres types que dans les cas
exceptionnels. On n'utilise donc unsigned que dans les cas où
on a besoin d'un de ces caractèristiques particuiliers :
- Des opérations bit-à-bit ne donne pas de résultats «
bizarre », même si on manipule le bit de poids fort. (C'est
surtout important pour les décalages à droits.)
- On a besoin d'un arithmétique modulo, par exemple dans le
calcul d'un code d'hachage.
- On a besoin de ce bit supplémentaire. Pour représenter ces
niveaux de gris, par exemple, je verrais bien un unsigned
char, parce que signé, il lui faudrait un short.
Non. Gabi l'explique mieux que moi, mais en gros, l'abstraction
implémentée par les unsigned n'est pas un ensemble des nombres
naturels. Le type naturel pour les calculs entiers en C/C++,
c'est int. On n'utilise d'autres types que dans les cas
exceptionnels. On n'utilise donc unsigned que dans les cas où
on a besoin d'un de ces caractèristiques particuiliers :
- Des opérations bit-à-bit ne donne pas de résultats «
bizarre », même si on manipule le bit de poids fort. (C'est
surtout important pour les décalages à droits.)
- On a besoin d'un arithmétique modulo, par exemple dans le
calcul d'un code d'hachage.
- On a besoin de ce bit supplémentaire. Pour représenter ces
niveaux de gris, par exemple, je verrais bien un unsigned
char, parce que signé, il lui faudrait un short.
Pierre Maurette wrote in message
news:...Mais bon, personnellement, je trouve regrettable l'utilisation
de / pour la division entière, j'aime bien le couple div mod
du Pascal.
Tout à fait d'accord. Mais C/C++ ne sont pas seuls dans leur
choix.
Pierre Maurette <maurette.pierre@free.fr> wrote in message
news:<cat3b05qmcpdous2n731hvsfu9lobbqskq@4ax.com>...
Mais bon, personnellement, je trouve regrettable l'utilisation
de / pour la division entière, j'aime bien le couple div mod
du Pascal.
Tout à fait d'accord. Mais C/C++ ne sont pas seuls dans leur
choix.
Pierre Maurette wrote in message
news:...Mais bon, personnellement, je trouve regrettable l'utilisation
de / pour la division entière, j'aime bien le couple div mod
du Pascal.
Tout à fait d'accord. Mais C/C++ ne sont pas seuls dans leur
choix.
D'une façon plus générale, il me semble voir souvent des
erreurs dues à une utilisation abusive d'opérations "réelles"
sur une problématique d'entiers. Ce qui n'en disqualifie pas
non plus l'usage modéré.
D'une façon plus générale, il me semble voir souvent des
erreurs dues à une utilisation abusive d'opérations "réelles"
sur une problématique d'entiers. Ce qui n'en disqualifie pas
non plus l'usage modéré.
D'une façon plus générale, il me semble voir souvent des
erreurs dues à une utilisation abusive d'opérations "réelles"
sur une problématique d'entiers. Ce qui n'en disqualifie pas
non plus l'usage modéré.
