savoir si un nombre est pair ou non

Bonjour tout le monde, j'aimerais savoir si il existe une fonction permmettant de savoir si un chiffre est pair ou non.
j'ai trouvé ceci:

Code:

---

1 2 3 4 5 6

if(chiffre% 2 == 0) { // ici c'est pair } else { // ici c'est impair }

---

mais si vous pensez qu'il y a mieux, svp faites moi signe
merci

Code:

---

1 2 3 4 5 6 7 8

if( nombreEntier & 1 ) { //Impair } else { //Pair }

---

(Attention par contre, ça ne marche qu'avec des entiers, pas des flottants. De toute façon, peut-on dire d'un nombre à virgule flottante qu'il est pair ou impair ? :? )

Il n'y a pas de fonction qui fait ça à ma connaissance.
Ta méthode marche très bien, sinon tu as aussi

Code:

---

1 2 3 4 5

bool estPair(const int i) { return ! (i&1); // le ET binaire entre num et 0x00000001 retourne 1 si le nombre est impair // return (i%2==0); // la solution avec le modulo }

---

qui est peut-être un poil plus rapide, mais honnêtement à ce niveau là ca ne change pas grand chose (si il y a bien une différence)...

edit: bah ça m'apprendra à faire autre chose pendant que je réponds, j'arrive trop tard du coup ;)

Citation:

---

Envoyé par bigquick

qui est peut-être un poil plus rapide, mais honnêtement à ce niveau là ca ne change pas grand chose

---

Un compilateur n'est pas une brèle.
Si le compilateur était effectivement une brèle, la différence serait effectivement importante (rapport d'un facteur 5, voire 10, sur x86).

Désolé d'avoir froissé les amis des compilateurs :)
Enfin j'ai pas compris ton point, désolé ... au final ça ne change rien, c'est ça ? Il optimise le modulo pour qu'il prenne le moins de cycle possible, étant donné que c'est modulo 2 et pas modulo 237 ? Ou c'est juste le modulo en général qui est opimisé ?

Un bon compilateur (même un moyen maintenant) optimise systématiquement les divisions par des constantes. Donc, oui, le modulo y'a de grande chance qu'il soit un tantinet arrangé et je pense qu'au final il ne doit pas y avoir d'écart de perf mesurable.

Citation:

---

Envoyé par VoidSeer

il ne doit pas y avoir d'écart de perf mesurable.

---

D'après moi, c'est pire que ça : que tu utilises une syntaxe ou l'autre, le résultat en code machine / assembleur sera exactement le même.

Pour gcc :

Citation:

---

Algebraic simplifications
Expressions are simplified using algebraic properties of their operators and operands. For instance, i + 1 - i is converted to 1. Other properties like associativity, commutativity, and distributivity are also used to simplify expressions.

Constant folding
Expressions for which all operands are constant can be evaluated at compile time and replaced with their values. For instance, the expression a = 4 + 3 - 8 can be replaced with a = -1.

---

Traduction :

Citation:

---

Simplifications algébriques
Les expressions sont simplifiées en utilisant les propriétés algébriques de leurs opérateurs et opérandes. Par exemple, i + 1 - i en converti en 1. D'autres propriétés comme l'associativité, la commutativité, et la distributivité sont aussi utilisées pour simplifier les expressions.

Evaluation des constantes
Les expressions dont toutes les opérandes sont des constantes peuvent être évaluées au moment de la compilation et remplacées par leur valeurs. Par exemple, l'expression a = 4 + 3 - 8 peut être remplacée par a = -1.

---

Citation:

---

Envoyé par remram44

Citation:

---

Envoyé par VoidSeer

il ne doit pas y avoir d'écart de perf mesurable.

---

D'après moi, c'est pire que ça : que tu utilises une syntaxe ou l'autre, le résultat en code machine / assembleur sera exactement le même.

---

+1
Cela fait un moment que les compilos sont censés maitriser les multiplications et divisions par des constantes. (genre *254 qui est remplacé par décalages et soustractions...)

En revanche, ça pourrait être plus intéressant le !(machin&1), non ? Pas de test, pas de saut, ...

À quoi sert-il de savoir qu'un nombre est pair si on n'utilise pas ce savoir? C'est à ca que sert la structure conditionnelle: à savoir ce qu'on fait s'il est pair ou non. Il y aura donc toujours un test et un saut...

Citation:

---

Envoyé par Miles

En revanche, ça pourrait être plus intéressant le !(machin&1), non ? Pas de test, pas de saut, ...

---

En quoi est-ce different de machin % 2 == 0 ? A part bien sur que l'utilisation de % a un comportement garanti dans le cas des nombres negatifs (je suis d'accord, les machines en complement a un ne sont pas legion).

Citation:

---

Envoyé par Médinoc

À quoi sert-il de savoir qu'un nombre est pair si on n'utilise pas ce savoir? C'est à ca que sert la structure conditionnelle: à savoir ce qu'on fait s'il est pair ou non. Il y aura donc toujours un test et un saut...

---

Non, on peut utiliser cette donnée dans d'autres opérations avec addition, genre (result * nombre) + (!result * nombre), même si ce n'est pas très propre - true a une valeur fixe valant 0xFF, non ? -

Citation:

---

Envoyé par Miles

On peut utiliser cette donnée dans d'autres opérations avec addition, genre (result * nombre) + (!result * nombre), même si ce n'est pas très propre - true a une valeur fixe valant 0xFF, non ? -

---

true vaut 1 et false 0.

Citation:

---

D'après moi, c'est pire que ça : que tu utilises une syntaxe ou l'autre, le résultat en code machine / assembleur sera exactement le même.

---

J'ai fait le test par curiosité :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

int estpair1(int x) { return x&1; } ------------------------------   push ebp mov ebp,esp   mov eax,dword ptr [ebp+8] and eax,1   pop ebp ret

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

int estpair2(int x) { return x%2; } ------------------------------   push ebp mov ebp,esp   mov eax,dword ptr [ebp+8] and eax,-2147483647 jns short S1 dec eax or eax,-2 inc eax S1: pop ebp ret

---

Si tu remplaces "int" par "unsigned int" pour le type de x, tu devrais obtenir la même chose.

Citation:

---

Si tu remplaces "int" par "unsigned int" pour le type de x, tu devrais obtenir la même chose.

---

Affirmatif !

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

int nbpair1(unsigned int x) { return x&1; } ------------------------------   push ebp mov ebp,esp   mov eax,dword ptr [ebp+8] and eax,1   pop ebp ret

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

int nbpair2(unsigned int x) { return x%2; } ------------------------------   push ebp mov ebp,esp   mov eax,dword ptr [ebp+8] and eax,1   pop ebp ret

---

Citation:

---

Envoyé par CGi

Citation:

---

D'après moi, c'est pire que ça : que tu utilises une syntaxe ou l'autre, le résultat en code machine / assembleur sera exactement le même.

---

J'ai fait le test par curiosité :

Code:

---

1 2 3 4 5 6 7 8 9

int estpair1(int x) { return x&1; }   int estpair2(int x) { return x%2; }

---

---

Tu as teste avec des parametres negatifs? Normalement -1 & 1 donne 1 tandis que -1 % 2
donne -1. Pas trop etonnant que le code soit different. Je me demande si ton optimiseur est assez pousse pour savoir que les deux fonctions suivantes sont equivalentes:

Code:

---

1 2	bool estpair(int x) { return (x&1) == 0; } bool estpair2(int x) { return (x%2) == 0; }

---

Citation:

---

Envoyé par jmarc68

Citation:

---

Envoyé par Miles

On peut utiliser cette donnée dans d'autres opérations avec addition, genre (result * nombre) + (!result * nombre), même si ce n'est pas très propre - true a une valeur fixe valant 0xFF, non ? -

---

true vaut 1 et false 0.

---

C'est encore mieux ;)

Citation:

---

Envoyé par jmarc68

Je me demande si ton optimiseur est assez pousse pour savoir que les deux fonctions suivantes sont equivalentes

---

Et bien apparement non :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13

bool estpair1(int x) { return (x&1) == 0; } ------------------------------   push ebp mov ebp,esp test byte ptr [ebp+8],1 sete al and eax,1 pop ebp ret

---

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

bool estpair2(int x) { return (x%2) == 0; } ------------------------------   push ebp mov ebp,esp mov eax,dword ptr [ebp+8] and eax,-2147483647 jns short S1 dec eax or eax,-2 inc eax S1: test eax,eax sete al and eax,1   pop ebp ret

---

J'ai bien testé avec différentes options d'otimisation mais ça ne change rien.

Quelle est la condition, pour jns ? (surtout après un AND...)

Salut Cgi
Tu as utilisé quoi pour avoir le code machine? En général je ne l'ai moi qu'en utilisant gdb pour traquer les problèmes (et encore dans un code C).
Merci

Normalement ton compilateur a une option qui permet de générer un listing du code assembleur généré.

Citation:

---

Envoyé par Aurelien.Regat-Barrel

Normalement ton compilateur a une option qui permet de générer un listing du code assembleur généré.

---

8O je savais pas je regarde la page de g++ alors merci :)
PS: gcc doit permettre cela je vais chercher et je dirais :)

gcc -s (ou -S, je ne sais plus)

gcc prend plusieurs paramètres, indiquant à quel moment de la compilation il doit s'arrêter :
-c : Génère un fichier-objet
-E : S'arrête après le préprocesseur.
-S : Génère du code assembleur.

Citation:

---

Envoyé par Médinoc

gcc -s (ou -S, je ne sais plus)

---

:merci: je m'étais égaré sur la page présentant l'état de l'implémentation de la norme C99 :lol: