<< symbole en C

Bonjour,
Je ne comprend pas bien cette ligne de code :

Code:

1
2
3
4
5
6
7
 
static GLfixed vertices[] ={-80 << 16,	-160 << 16,
								0 << 16,	160 << 16,
								80 << 16,	-160 << 16,
								-80 << 16,	-160 << 16,
								0 << 16,	160 << 16,
								80 << 16,	-160 << 16};

Quelqu'un pourrait-il m'expliquer le but de << ?
Merci

Je pense qu'il s'agit de ceci:

<< effectue un décalage à gauche du nombre de positions précisées
>> effectue un décalage à droite du nombre de positions précisées
<<= effectue un décalage à gauche du nombre de positions précisées et assigne le résultat à la première opérande
>>= effectue un décalage à droite du nombre de positions précisées et assigne le résultat à la première opérande

par décalage, on entend décalage binaire.

par exemple:
décimal : 12
binaire: 00001100

si on décale 12 de 2 vers la gauche, on se retrouve avec en binaire 00110000 cad 48
on a donc fait une multiplication par 4 cad 2 puissance 2

en gros un décalage binaire de n vers la gauche correspond à une multiplication par 2 puissance n

Reprenez moi si je me trompe, mais je crois que c'est ça.

ok merci. Mais ca sert a quoi au juste ?

Ca te sert à faire des multiplications et divisions, pas cher du tout.
Tres utile, mais à utiliser avec precaution. :wink:

Re: << symbole en C

Citation:

Envoyé par graphicsxp

Code:

1
2
3
4
5
6
7
 
static GLfixed vertices[] ={-80 << 16,	-160 << 16,
					  0 << 16,	160 << 16,
					80 << 16,	-160 << 16,
					-80 << 16,	-160 << 16,
					0 << 16,	160 << 16,
					80 << 16,	-160 << 16};

A quoi sert l'entierté du code auxquels tu a pris celui-ci ca aidera peut-etre pour l'explication.

Re: << symbole en C

Citation:

Envoyé par lipczynski

A quoi sert l'entierté du code auxquels tu a pris celui-ci ca aidera peut-etre pour l'explication.

Gnn ? :|

Re: << symbole en C

Citation:

Envoyé par ggnore

Gnn ? :|

Ben ouais quoi , pour lui expliquer pourquoi il était plus judicieux d'utiliser les "<<" à une multiplication simple avec un "*".

Re: << symbole en C

Citation:

Envoyé par lipczynski

Citation:

Envoyé par ggnore

Gnn ? :|

Ben ouais quoi , pour lui expliquer pourquoi il était plus judicieux d'utiliser les "<<" à une multiplication simple avec un "*".

Je pense que "l'entierté" l'a un peu choqué ... tu devrais peut-être reposer ta question avec "intégralité" :wink:

A vue de nez, son code a l'air de faire de la 3D.

Les décalages binaires c'est plus rapides que les multiplications/divisions. Dans un moteur graphique, tout gain de vitesse est à conserver.

vu comme ca c'est clair.

Citation:

Envoyé par ggnore

Dans un moteur graphique, tout gain de vitesse est à conserver.

En général, je dirais que pout tout programme tout gain de vitesse est bon.

ô que c'est bô.

Il y a un compromis à faire de temps en temps.

Si tu veux que ton code soit facilement modifiable par tout le monde (cad aussi les débutants), il faut éviter de faire du code obscur. Tu vas pas te faire chi** à optimiser un traitement de fichier texte banal sous prétexte que ton éthique te dit que plus ça va vite, mieux c'est. Si ton traitement de fichier texte marche bien, c'est l'essentiel

et oui mon code fait de la 3D... :)
en fait j'ai deux versions de declarations de tableaux de points dans l'espace 3D. Une version avec des floats que voici :
Code:

1 2 3 4 5 6 7 static GLfloat vertices[] = {-40, -80, 0, 80, 40, -80, -40, -80, 0, 80, 40, -80};
et une version avec des entiers fixes que voici :
Code:

1 2 3 4 5 6 7 8 static GLfixed vertices[] ={-80 << 16, -160 << 16, 0 << 16, 160 << 16, 80 << 16, -160 << 16, -80 << 16, -160 << 16, 0 << 16, 160 << 16, 80 << 16, -160 << 16};
Et je ne comprends pas l'interet de multiplier par 2^16....

je ne suis pas sûr que fixed signifie entier fixe.

Je crois que j'ai déjà vu une référence à fixed en ce qui concerne les angles.
Ici, on peut voir que cela fait référence à des vecteurs ou quelquechose dans le genre.

Admettons qu'on ait un repère orthonormé x;y basique.

On est d'accord qu'un vecteur qui fait (1;1) va dans la même direction qu'un autre qui fait (2;2)

Je dirais que c'est 'à peu près' le même principe pour tes 2 façons de faire. Quand on utilise des fixed, on a effectivement des entiers, mais on n'aura pas la même précision que les float si on reste avec des petites valeurs car les entiers n'ont pas de virgules (si je vous jure !)

Donc on prend des valeurs super grandes comme ça, on peut appliquer dse modifications dessus sans perdre d'information.

C'est sûrement pas très bien expliqué :?
Edit: évident que c'est vaseux ce que je raconte
et pas sûr du tout que ça soit correct

pfiou, alors la :bravo:
merci bcp, c effectivement une raison tres plausible ! tout est clair maintenant :)

:oops: de rien du tout. C'est un peu du bol.

Tant que tu y es, clique sur résolu si juges avoir eu ta réponse :twisted:

Citation:
Envoyé par graphicsxp
et oui mon code fait de la 3D... :)
en fait j'ai deux versions de declarations de tableaux de points dans l'espace 3D. Une version avec des floats que voici :
Code:

1 2 3 4 5 6 7 static GLfloat vertices[] = {-40, -80, 0, 80, 40, -80, -40, -80, 0, 80, 40, -80};
et une version avec des entiers fixes que voici :
Code:

1 2 3 4 5 6 7 8 static GLfixed vertices[] ={-80 << 16, -160 << 16, 0 << 16, 160 << 16, 80 << 16, -160 << 16, -80 << 16, -160 << 16, 0 << 16, 160 << 16, 80 << 16, -160 << 16};
Et je ne comprends pas l'interet de multiplier par 2^16....
Je crois comprendre pourquoi. Disons qu'a la base, il utilise des float, ca veut donc dire que tes nombres font pouvoir prendre des valeurs non-entieres.
La deuxieme methode se fait avec des GLFixed.

Voici mon interpretation:
un nombre flottant a une virgule flottante (d'où son nom) dont la position est précisé par l'exposant du nombre. Lequel exposant est stocké dans la représentation du nombre (8 bits pour un float, 11 pour un double, plus de détails là: http://www.haypocalc.com/maths/ieee754_854.php).
Donc du coup, ca laisse un petit peu moins de places pour stocker le reste du nombre (le "signe" et la "mantisse").

Ce que semblent representés tes GLFixed sont en fait des nombres flottants dont l'exposant est fixé (donc ce n'est plus des entiers). Ca permet de gagner de précieux bits de représentations du nombre, cependant, comme c'est fixé, ca perd en souplesse. Et pour representer celà, il utilise donc des entiers, et le décalage de 16 bits indique qu"il utilise l'exposant -16. En gros un GLFixed codé 55 (par exemple) representera en fait la valeur 55 * 2^(-16). Pour obtenir vraiment 55 il faut stocker 55 << 16. Tu stockes donc des nombres décimaux avec une précision figée de 2^(-16).

Ton programme suppose donc que tes nombres ne vont pas etre trop grand ni trop petits, et qu'une perte de 2^(-16) n'est pas grave, et il va
ainsi stocker les nombres décimaux dans des entiers. Celà lui permet de gagner en rapidité (l'arithmétique des flottants, avec mantisse + exposant, est assez longue comparée à l'arithmétique sur les entiers).

Donc selon moi tes GLFixed sont des entiers (int ou long).

Citation:

Envoyé par lipczynski

vu comme ca c'est clair.

Citation:

Envoyé par ggnore

Dans un moteur graphique, tout gain de vitesse est à conserver.

En général, je dirais que pout tout programme tout gain de vitesse est bon.

Vu que ce sont des constantes évaluées à la compilation, je ne vois pas ce que ça change...

Citation:

Envoyé par Emmanuel Delahaye

Citation:

Envoyé par lipczynski

vu comme ca c'est clair.

Citation:

Envoyé par ggnore

Dans un moteur graphique, tout gain de vitesse est à conserver.

En général, je dirais que pout tout programme tout gain de vitesse est bon.

Vu que ce sont des constantes évaluées à la compilation, je ne vois pas ce que ça change...

ok, mais ...

Quel est l'intérêt du décalage binaire par rapport à une multiplication pure et simple alors ?
Peut être que c'est pour se donner un style de hard core coder ?

Citation:

Envoyé par ggnore

Citation:

Envoyé par Emmanuel Delahaye

Citation:

Envoyé par lipczynski

vu comme ca c'est clair.

Citation:

Envoyé par ggnore

Dans un moteur graphique, tout gain de vitesse est à conserver.

En général, je dirais que pout tout programme tout gain de vitesse est bon.

Vu que ce sont des constantes évaluées à la compilation, je ne vois pas ce que ça change...

ok, mais ...

Quel est l'intérêt du décalage binaire par rapport à une multiplication pure et simple alors ?
Peut être que c'est pour se donner un style de hard core coder ?

Pour des expressions constantes, on peut parfois dire ça. Pour des expressions évaluées à l'exécution, ça améliore le code, bien que dans bien des cas, le compilateur soit capable de reconnaitre une puissance de 2 et emplace la multiplication par un décalage. Mais dans le doute, il vaut mieux clarifier ses intentions.

Ca peut être aussi intentionnel, car ça correspond exactement à ce qu'on veut faire (manipulations de bits par exemple).

http://emmanuel-delahaye.developpez..../ed/inc/BITS.H