convertir des octets en float : format apparement specifique

Version imprimable

12/01/2006, 13h22
zax-tfh

convertir des octets en float : format apparement specifique

Re !
C'est encore moi et mon fichier 3ds ^^
Je dois convertir des octets en un float mais ça n'a pas l'air si simple que ça.
J'ai regardé un peu comment sous pc et mac les floats etaient placés en memoire mais c'est encore pire que ce que je pouvais penser ^^
En gros, je ne comprend pas comment en recuperant 4 octets on peux les replacer en float.
Ce qui est certain, c'est que entre pc et mac il y a une difference (endianess ? taille des floats ?)

Quelqu'un aurait-il une info la dessus svp ? j'ai essayé de regarder sur le net le principe de codage hexa d'un reel non signé, et à vrai dire je n'ai pas tout compris. Ils parlent du signe à droite du bit de poids fort, une mantisse et un exposant. Bon ok, mais ils ne disent pas ou se trouve la mantisse ni l'exposant donc je ne peux pas faire d'essai :(

Merci d'avance
@++
12/01/2006, 13h37
Laurent Gomila

Regarde la norme IEEE 754 (si je me souviens bien) pour une description détaillée de l'encodage des flottants. Par contre étant donné que c'est normalisé j'imagine que tous les systèmes utilisent ce même encodage non ?
12/01/2006, 13h49
PRomu@ld

Non, il n'y a rien de bien défini, tu peux trouver des systèmes qui auront peut être un codage différent pour les réels.

Citation:

Envoyé par Loulou24

Regarde la norme IEEE 754 (si je me souviens bien) pour une description détaillée de l'encodage des flottants. Par contre étant donné que c'est normalisé j'imagine que tous les systèmes utilisent ce même encodage non ?

La norme ne detaille pas l'encodage. Il y en a au moins 3 d'utilises (et deux d'entre eux ne different que pour les NaN)

Je suis cependant surpris que PowerPC ne soit pas simplement les meme bytes qu'un x86 dans un autre ordre. zax-tfh, peux-tu donner le resultat de ce programme sur tes deux plateformes?

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
#include <iostream>
#include <climits>
#include <cfloat>
 
template <typename T>
    std::string toBitGroup(T const& value, int bitPerGroup)
{
  static int const maxResultSize = sizeof(T)*CHAR_BIT + 1;  
  char result[maxResultSize];
  unsigned char const* raw = reinterpret_cast<unsigned char const*>(&value);
  unsigned char carry = 0;
  int bitsInCarry = 0;
  int resIndex = maxResultSize;
 
  result[--resIndex] = '\0';
  for (int rawIndex = sizeof(T)-1; rawIndex >= 0; --rawIndex) {
    while (bitsInCarry + CHAR_BIT >= bitPerGroup) {
      if (bitsInCarry >= 0)
        carry |= raw[rawIndex] << bitsInCarry;
      else
        carry |= raw[rawIndex] >> -bitsInCarry;
      result[--resIndex]
        = "0123456789ABCDEF"[carry & 0xF & (~(0xF << bitPerGroup))];
      carry >>= bitPerGroup;
      bitsInCarry -= bitPerGroup;
    }
    bitsInCarry += CHAR_BIT;
  }
  if (bitsInCarry > 0) {
    result[--resIndex]
      = "0123456789ABCDEF"[carry & 0xF & (~(0xF << bitPerGroup))];
  }
  return result+resIndex;
}
 
int main(int argc, char *argv[]) {
    std::cout << toBitGroup((double)0.0, 4) << '\n';
    std::cout << toBitGroup((double)DBL_MIN, 4) << '\n';
    std::cout << toBitGroup((double)-DBL_MIN, 4) << '\n';
    std::cout << toBitGroup((double)0.125, 4) << '\n';
    std::cout << toBitGroup((double)-0.125, 4) << '\n';
    std::cout << toBitGroup((double)0.25, 4) << '\n';
    std::cout << toBitGroup((double)-0.25, 4) << '\n';
    std::cout << toBitGroup((double)0.5, 4) << '\n';
    std::cout << toBitGroup((double)-0.5, 4) << '\n';
    std::cout << toBitGroup((double)1.0-DBL_EPSILON, 4) << '\n';
    std::cout << toBitGroup((double)1.0, 4) << '\n';
    std::cout << toBitGroup((double)1.0+DBL_EPSILON, 4) << '\n';
    std::cout << toBitGroup((double)2.0, 4) << '\n';
    std::cout << toBitGroup((double)4.0, 4) << '\n';
    std::cout << toBitGroup((double)0xFF6E5D+(double)0x9876543/0x20000000, 4) << '\n';
    std::cout << toBitGroup((double)DBL_MAX, 4) << '\n';
    std::cout << toBitGroup((double)-DBL_MAX, 4) << '\n';
}

12/01/2006, 14h27
Jean-Marc.Bourguet

Citation:

Envoyé par PRomu@ld

Non, il n'y a rien de bien défini, tu peux trouver des systèmes qui auront peut être un codage différent pour les réels.

Il y a deux choses:

Premierement, rien n'impose l'utilisation de IEEE-754 mais en pratique hors les descendants de machines anterieure a 1985, on ne trouve guere que ca. Une classe toujours importante de descendants de machines anterieure a 1985, c'est les descendants des IBM 360 (zSeries? je suis perdu dans cette nomemclature) bien qu'ils ont aussi des flottants IEEE-754. Une classe historiquement importante, c'est les differents formats des VAX, mais il me semble que l'interet n'est plus qu'historique. Quelque chose qui va peut-etre avoir une importance, c'est les flottants decimaux -- bien que je n'en ai jamais compris l'interet profond, IBM fait pas mal de lobbying autour. A ma connaissance, les processeurs en question ici se reclame de la norme IEEE-754.

Deuxiement, IEEE-754 ne detaille pas une representation binaire bien qu'un schema ou l'autre en suggere fortement une. En pratique on utilise la variante big endian et little endian de cette representation. Mais vient se greffer le probleme des NaN signalant/silencieux et la aussi il y a de la variation sans qu'il y ait une suggestion dans le texte. Au total je connais 3 representations utilisees.
12/01/2006, 14h39
zax-tfh

Re !

Alors voila le resultat mac :

Citation:

[Session started at 2006-01-12 14:36:07 +0100.]
0000000000000000
0010000000000000
8010000000000000
3FC0000000000000
BFC0000000000000
3FD0000000000000
BFD0000000000000
3FE0000000000000
BFE0000000000000
3FEFFFFFFFFFFFFE
3FF0000000000000
3FF0000000000001
4000000000000000
4010000000000000
416FEDCBA9876543
7FEFFFFFFFFFFFFF
FFEFFFFFFFFFFFFF

test float has exited with status 0.

Le resultat pc dans le prochain post dans trentes secondes ^^
12/01/2006, 14h46
zax-tfh

resultat pc :

Citation:

0000000000000000
0000000000001000
0000000000001080
000000000000C03F
000000000000C0BF
000000000000D03F
000000000000D0BF
000000000000E03F
000000000000E0BF
FEFFFFFFFFFFEF3F
000000000000F03F
010000000000F03F
0000000000000040
0000000000001040
436587A9CBED6F41
FFFFFFFFFFFFEF7F
FFFFFFFFFFFFEFFF

Ce qui est bizarre, c'est que le gars dans son loader de fichier 3ds, il ne se prend pas la tete avec tout ça...
Voici comment il procede (bon c'est sur il ne tient pas compte de l'endian)

Code:

sommet->m_fCoord[0] = *(float *)&m_ucpBuffer[0];

m_ucpbuffer etant son tableau de caracteres contenant ses octets lus dans son fichier.

Voilou ;)

je continue de nager moi ^^
12/01/2006, 14h55
zax-tfh

Je crois que je finis par comprendre à peu pres, par rapport aux resultats... faut que je continue à regarder et si je trouve une réponse, je la posterai ici. En attendant, je continue de chercher ^^
12/01/2006, 15h19
zax-tfh

Nan en fait je comprend rien ^^
Voici entre guillemets ma logique de pseudo debutant (ou plutot d'ignare en matiere de codage de types :

Je lis 4 octets dans mon buffer :
buff[0] buff[1] buff[2] buff[3]

Si je fais un sizeof(float) j'obtiens 4, donc un float est codé en 4 octets (du moins si on part sur une base de test sans chercher la portabilité ou autre vu que le float ne sera peut etre pas codé sur 4 octets partout, j'en sais rien).

Donc on à 4 octets d'un coté et on peut en placer 4 dans un float. Donc logiquement, soit on les place dans l'ordre soit on les place dans le sens inverse et on devrait retrouver nos billes... avec un decalage bien sur, de 8 par 8 bits.
Mais en phase de test ça ne fonctionne pas :(

Donc là c'est vraiment de la semoule liquide dans laquelle je nage ^^
12/01/2006, 17h52
zax-tfh

Bon ça fait toute une journée complete à chercher sur le sujet, je commence à saturer :(

J'ai retourné le probleme dans tous les sens mais je ne trouve toujours pas de solution...
Par contre j'ai des questions :

Imaginons un float ayant pour valeur 0xAABBCCDD
Cette valeur est inscrite dans cet ordre dans le fichier 3ds.
Si l'endian change vis à vis de cette valeur et donc de l'endian d'origine qui a inscrit le float dans le fichier.
Est-ce que mon float retranscrit dans l'endian courant aura bien pour valeur 0xDDCCBBAA ?
Je demande ça car vis à vis du format d'un float ça change completement la place des choses, notamment la place du bit de signe qui au lieu de se retrouver au 32 bit se retrouve finalement au 8eme.
De là decoule deux autres questions :
- soit le systeme le gere, dans quel cas une simple inversion des octets suffit (j'ai testé ça passe pas :( )
- soit le systeme ne le gere pas et donc il faut retranscrire le float dans un format lisible... dans quel cas je ne sais pas comment faire :(

Une question finale :
Sachant que l'on a ceci :

vector<unsigned char> buffer

Et que l'on souhaite recuperer 4 octets du buffer, comment feriez vous pour transformer ces 4 octets en un float adapté au systeme (endian et taille du float) ?

Merci d'avance
++
12/01/2006, 17h53
diogene

Pour information, dans un document non officiel sur les fichiers 3ds , j'ai lu que les float étaient effectivement codés en format IEEE sur 4 octets. Il ne précise pas l'endianess. C'est probablement celle des PC, le logiciel 3D Studio n'était pas je crois (au moins à l'origine) disponible sur Mac.
12/01/2006, 18h00
zax-tfh

merci diogene, je l'avais plus ou moins deviné vu que le reste l'est aussi (je parle de l'endianess).
Pour ce qui est des 4 octets, idem, j'avais lu sur une doc que c'etait codé sur 4 octets. Pour ce qui est du IEEE, je ne sais pas comment en tirer quelque chose en fait :oops: :oops: :oops:

Merci pour la precision en tout cas
12/01/2006, 19h07
diogene

Citation:

Et que l'on souhaite recuperer 4 octets du buffer, comment feriez vous pour transformer ces 4 octets en un float adapté au systeme (endian et taille du float) ?

Si on veut que ce soit indépendant de la plateforme, il faut recalculer la valeur à partir des octets:
En little endian,
- Le premier octet O1 (unsigned char) contient les bits de la mantisse de poids 2^-16 à 2^-23. sa contribution à la mantisse m est O1/8388608.0

- le second octet O2 (unsigned char)les bits de la mantisse de poids 2^-8 à 2^-15 sa contribution à la mantisse est O2/32768.0

- le troisième octet O3 (unsigned char) après mise à 1 du poids fort (-> O'3) les bits 2^0 à 2^-7 sa contribution à la mantisse est O'3/128.0
La mantisse m est la somme de tout ça;

- Le bit de poids fort de cet octet O3 est le bit de poids faible de l'exposant. Le quatrième octet O4 (unsigned char) a pour poids fort le signe 0 pour + et 1 pour -
Après élimination du bit de poids fort par décalage et insertion en poids faible du bit de poids fort de O3 (->O'4), on a l'exposant biaisé de 127.
Retouver l'exposant par int exp = O'4-127
Multipler la mantisse m par 2^exp
Si le bit de poids fort de O4 est 1, changer de signe

OUF

Edit : le cas de la valeur 0 est particulier (tous les octets à 0)
ceci suppose que le fichier ne contient pas de valeurs exotiques style NaN INF ou des nombres dénormalisés

Très interressante ta decomposition Diogene ! je vais travailler ça demain je pense ^^

Par contre, un truc qui me vient à l'esprit direct, si on recompose ce que tu dis, ça nous donne la description du format d'un float, ok ?
1bit pour le signe, 8 pour l'exposant et 23 pour la mantisse.
Or si on recompose le float je dirais de maniere barbare c'est à dire en obligeant le format du float en 4 octets (comme sur mon systeme actuel) et selon un endian précis (comme celui de mon systeme), normalement je devrais retrouver mon float non ?

Or j'ai fait le test suivant :

une fonction de test qui est censée recomposer mes 4 octets et transformer tout ça en float. j'ai testé les deux methodes (celle en commentaire et celle qui ne l'est pas, en essayant les deux endian également)
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 float readFloat(vector<unsigned char>buff, int debut, int fin) { float result = 0; /*result = result * 0x100 + buff[debut+1]; result = result * 0x100 + buff[debut+2]; result = result * 0x100 + buff[debut+3];*/ char toto[4]; toto[0] = buff[debut+3]; toto[1] = buff[debut+2]; toto[2] = buff[debut+1]; toto[3] = buff[debut]; result = *((float*)toto); return result; }
Code appelant :

Code:

x = readFloat(buffer, position_x, position_x + 3);

Je me retrouve tout le temps avec un nombre abhérent quelque soit la methode essayée...

Franchement je ne vois pas... :(
Merci pour ton explication en tout cas Diogene !

12/01/2006, 21h20
JolyLoic

Citation:

Envoyé par Jean-Marc.Bourguet

Quelque chose qui va peut-etre avoir une importance, c'est les flottants decimaux -- bien que je n'en ai jamais compris l'interet profond, IBM fait pas mal de lobbying autour.

N'est-ce pas parce que pour les calculs financiers, il permettent des calculs d'arrondis conformes aux lois, chose que les flottants ne font pas ?
12/01/2006, 21h26
diogene
Citation:

Par contre, un truc qui me vient à l'esprit direct, si on recompose ce que tu dis, ça nous donne la description du format d'un float, ok ?

Oui

Citation:

1bit pour le signe, 8 pour l'exposant et 23 pour la mantisse.

Oui
Tout dépend si tu veux une indépendance vis à vis de la pateforme. Dans ce cas, il faut recalculer : style
Code:

1 2 3 float mantisse = tab[0]/8388608.0; mantisse += tab[1]/32768.0; ....
Sinon, si la plateforme cible est spécifique (et IEEE), il suffit effectivement de replacer les octets dans le bon ordre selon l'endian de la plateforme.
Dans ton cas, les fichiers que tu lis possèdent des chunk qui décrivent la nature des blocs de données. Es tu sùr que tu ne te trompes pas dans leur gestion et que les données que tu essayes de lire sont bien des float ? Il suffit de se tromper d'un octet sur leur position dans le fichier et tout est foutu
12/01/2006, 22h03
Jean-Marc.Bourguet

Citation:

Envoyé par JolyLoic

Citation:

Envoyé par Jean-Marc.Bourguet

Quelque chose qui va peut-etre avoir une importance, c'est les flottants decimaux -- bien que je n'en ai jamais compris l'interet profond, IBM fait pas mal de lobbying autour.

N'est-ce pas parce que pour les calculs financiers, il permettent des calculs d'arrondis conformes aux lois, chose que les flottants ne font pas ?

Les lois que je connais demandent un calcul infiniment précis suivi d'un arrondi, ce que ne permettent pas les flottants qu'ils soient décimaux ou binaires. La précision nécessaire est généralement calculable a priori et donc une représentation en virgule fixe suffit et les flottants n'apportent rien qu'une consommation de bits inutile; pour autant qu'ils soient utilisables parce qu'il y a un risque de double arrondi. Il y a quelques cas où la précision nécessaire n'est pas facilement calculable a priori et donc les représentations en virgule fixe ne sont pas utilisables; mais alors si on veut faire un calcul exact -- je ne suis pas sûr que la loi le demande dans ces cas parce qu'on ne saurait le faire à la main de toute façon, il faut évaluer des fonctions transcendantes jusqu'à ce qu'on puisse les arrondir correctement -- il faut taper dans les bibliothèques de précision non bornée parce qu'à nouveau, les flottants n'aident pas.

Le seul avantage des flottants décimaux, c'est de conserver précisément les données décimales. Au prix d'une perte de précision et -- d'après les numériciens -- de difficultés d'analyse. Mais si les données décimales sont exactes et qu'il faut des calculs exacts, une représentation en virgule fixe ou une représentation à précision non bornée conviendrait vraissemblablement mieux. Si ce n'est pas le cas, les flottants binaires sont plus précis.
13/01/2006, 01h37
zax-tfh

YES !!!!!
Ca y est ! ça fonctionne enfin !
Alors voilà comment j'ai procédé, mais avant tout je tiens à remercier Diogène qui a terminé le traçage du chemin que ceux avaient commencé à me montrer (et je les en remercie aussi !)
Donc en gros, je me suis dit : Diogene souleve un lapin qui en effet n'est pas négligeable. Est-ce que je suis sur les bons octets ?
Je me suis dit, bah le soucis c'est que pour tester, bah faut bien parcourir le fichier, j'ai pas le choix. Sauf que m'est venue l'idée de faire un petit script qui va inscrire un float dans un fichier en binaire (à la façon de l'exemple de la FAQ C++ "comment lire/ecrire dans un fichier binaire".

J'ai fait mes essais, puis ensuite j'ai adapté ma technique de lecture de float avec mon tableau de caracteres (pas tres joliement fait mais c'etait pour le test). Et ça a marché ! donc ni une ni deux, je réadapte sur mon code pour mon fichier 3ds et là, c'est le drame... toujours rien...
Bon comme me disais Diogène, je ne dois pas etre au bon octet... Je vérifie par rapport à la doc que j'ai trouvé sur le net, et si j'y etais bien.... Mais je me suis souvenu que j'avais une autre doc, en english cette fois et genre le bon vieux fichier texte tout pourri ou ils ont pris un texte, melangé les caracteres et versé tout ca dans un tite boite tellement c'est pas tres lisible... lol. Et là, c'est le drame... Juste avant le chunk de mes floats, il y a un chunk pour lire le nombre de vertexs que je dois recuperer. Dans la doc française, il était écrit 4 octets... dans l'anglaise 2.... Donc voila d'ou ca venait... J'aurais pu tourner pendant des jours entiers sans pour autant trouver la réponse à ma question !

Enfin voila ! tout est bien qui fini bien et je dirais qu'au moins cette aventure m'aura permis d'apprendre encore de nouvelles choses !
Merci encore à tous pour votre patience et votre dévouement ;) c'est vraiment sympa !

@ bientot !

C'est re-moi, bon certes ça fonctionne avec la fonction test que j'ai fait mais c'est pas terrible quand meme...
Et y'à un truc que je ne saisis pas vraiment. J'ai essayé plusieurs méthodes et seule celle que j'ai fait avec le tableau de char fonctionne...

Voici le code :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 float readFloat(vector<unsigned char>buff, int debut, int fin) { float result = 0; //1ere methode decalage barbare (fonctionne pas) //result = (buff[debut+3] * 0x1000000) + (buff[debut+2] * 0x10000) + (buff[debut+1] * 0x100) + (buff[debut]); //2eme methode decalage recursif (non plus) /* result = buff[debut]; if(debut<fin) result = readFloat(buff, debut+1, fin) * 0x100 + result; */ //3eme methode tableau de char et cast en float. (fonctionne mais pas pratique...) /* char toto[4]; if (0) { //PC toto[0] = buff[debut]; toto[1] = buff[debut+1]; toto[2] = buff[debut+2]; toto[3] = buff[debut+3]; } else { //MAC toto[0] = buff[debut+3]; toto[1] = buff[debut+2]; toto[2] = buff[debut+1]; toto[3] = buff[debut]; } result = *((float*)toto); */ return (float)result; }
La premiere et deuxieme methode est la meme que pour renvoyer un long ou autre. Elle fonctionne très bien pour les long sur les deux OS/archi. Par contre en float je ne comprend pas, ça ne passe pas.
Pourtant, logiquement c'est censé remettre les octets dans l'ordre d'après l'endianess de la machine, chose qui se fait nickel pour les long avec cette meme méthode.
Mais alors, pourquoi ça ne passe pas avec les floats ?

C'est encore trop bizarre comme histoire ça....
Si vous avez une idée, n'hesitez pas
Merci !

13/01/2006, 13h26
superspag
Tu peux tenter un truc comme ça :
Code:

1 2 3 4 5 6 7 8 9 10 union FloatOct { float valfloat; struct { unsigned char oct3 : 8; unsigned char oct2 : 8; unsigned char oct1 : 8; unsigned char oct0 : 8; }; };
Je ne sais pas si ça marche, je n'ai pas le temps de faire des tests... ça devrai etre bon à l'ordre prés des octn :roll:

J'explique quand même : c'est le même principe que les champs de bits. Ici je declare une structure que j'interprete soit comme un float, soit comme 4 octets.
Code:

1 2 3 4 5 6 FloatOct test; test.valfloat = 15.61; ... ...test.oct0... ...
Je donne ainsi une valeur float et je peux recuperer les octets par la suite.
Code:

1 2 3 4 5 6 7 8 9 FloatOct test; test.oct0 = ...; test.oct1 = ...; test.oct2 = ...; test.oct3 = ...; ... ...test.valfloat... ...
De la même manière, je donne les valeurs à chacun de mes octets et je recupere par la suite la valeur float.

Dite moi si ça marche, ça m'interesse ^^
13/01/2006, 15h18
zax-tfh

Salut,

je pense que ta méthode va fonctionner, mais j'ai bien peur qu'elle ne gère ni l'endianess vu que l'on doit donner les octets dans le bon ordre, ni le sizeof float :(

Alors bon, pour l'endianess, il est clair qu'il faut absolument que je trouve un moyen de le gérer automatiquement sans faire de test sur la machine (comme la méthode N° 2 de mon précédent post. Par contre au sujet de cette méthode, il est évident que ça ne fonctionnera pas vu que l'on renvoie recursivement un float qui dans la récursivité est traité comme un octet char... je vais voir pour bidouiller ça ^^)

Par contre, j'ai une question très importante :

Au sujet de la taille d'un type : Y'a-t-il réellement des différences de tailles de types selon les systemes d'exploit / archi processeur ?
Pour exemple, au hasard et pas forcement juste, mais juste pour exprimer ma question : imaginons un float, sur pc/windows il est codé sur 4 octets, mais sur un autre systeme (je parle de systeme grand public, pas de station de calcul météo ou autres trucs du genre, ça je m'en tape un peu...), ne pourrait-il pas etre codé sur 8 par exemple ?

Si c'est le cas, comment on le gere ça ? Car je me dis que le jour ou on va changer de codage de type (du moins au niveau taille, pas forcement au niveau de la maniere de faire) beh quand je vais mettre mes 4 octets dans un float codé sur 8, ça risquerait de faire un truc debile...
Enfin ça c'est purement pour apprendre comment fonctionne l'interieur d'une becane on va dire, car pour le moment, un simple cast fait le taff, mais j'aimerai bien gérer ce genre de chose si c'est possible ^^

Merci supersag, je vais tester ta technique et en meme temps voir ma bidouille de la deuxieme methode de mon post, je posterai les resultats ;)

++

Ta methode 1 (et ta methode 2) ne fonctionne pas. Elles lisent un entier mais pas un float meme si elles mettent le resultat dans un float.

Si je ne me trompe pas (c'est pas teste, le 128 est de memoire), le code suivant devrait faire a peut pres ce que tu veux (les infini et les NaN ne sont pas traite)
Code:

1 2 3 4 5 6 7 8 9 float readFloat(unsigned char* buf) { float result = buf[0]; result = result/256 + buf[1]; result = result/256 + (buf[2] | 0x80); unsigned exp = unsigned(buf[3] & 0x7F) * 2 + ((buf[2] & 0x80) != 0 ? 1 : 0) - 128; bool sign = (buf[3] & 0x80) != 0; return sign ? -ldexp(result/256, exp) : ldexp(result/256, exp); }

13/01/2006, 15h40
zax-tfh

Supersag : je viens de tester ta méthode et elle fonctionne mais sans gérer l'endianess :( c'est bien ce qui me semblait.

Ca m'embete car pour lire un long la méthode du décalage fonctionne très bien ! le but est simple : opérer un décalage par 8bits sur un octet. Grace à cela, si l'endianess change, le décalage aussi, donc au final, quelque soit l'endianess, on n'a pas à changer l'ordre des octets, il est toujours correct.

Seulement cette méthode fonctionne bien pour un long, int ou short vu que ce sont des entiers donc codés directement sur tous les bits. Or pour mon cas d'un float, on ne peut pas vu que la mantisse est sur 23 bits, 8 bits pour l'exposant et 1 pour le signe.

Il faudrait que je puisse opérer ce decalage de bits sans altérer le contenu en le stockant dans une variable. Et là je ne sais pas trop comment faire :(
13/01/2006, 15h48
Jean-Marc.Bourguet

Citation:

Envoyé par zax-tfh

Au sujet de la taille d'un type : Y'a-t-il réellement des
différences de tailles de types selon les systemes d'exploit / archi
processeur ?

Suivant les processeurs et les modes de compilation, oui.

Par exemple, sur la machine que j'utilise j'ai le choix entre deux modes,
un pour lequel les long font 4 bytes, un pour lequel les long font 8 bytes.

Citation:

Pour exemple, au hasard et pas forcement juste, mais juste pour
exprimer ma question : imaginons un float, sur pc/windows il est codé sur 4
octets, mais sur un autre systeme (je parle de systeme grand public, pas de
station de calcul météo ou autres trucs du genre, ça je m'en tape un
peu...), ne pourrait-il pas etre codé sur 8 par exemple ?

Peu de risques. Cela fait 20 ans a peu pres que tout le monde tends a
s'aligner sur les formats IEEE. Il n'y a guere que les descendants de
vielle architecture et les DSP ou je concois des differences.

Citation:

Si c'est le cas, comment on le gere ça ? Car je me dis que le jour
ou on va changer de codage de type (du moins au niveau taille, pas
forcement au niveau de la maniere de faire) beh quand je vais mettre mes 4
octets dans un float codé sur 8, ça risquerait de faire un truc
debile...

Pour passer de 4 a 8, pas de probleme, tu etends avec les 0 et ca passera.
Pour passer de 8 a 4, tu arrondis la partie fractionnaire. Le plus gros
probleme c'est si l'intervalle de l'exposant dans la destination est plus
petit que celui de la source ou la tu te retrouves avec des nombres qui ne
sont meme pas approchables. Quelques possibilites: retourner un infini ou
un NaN ou bien generer une erreur.

Le code de Jean-Marc.Bourguet recalcule le float et le résultat doit donc être adapté automatiquement à l'endianess et à la taille du float de la machine. Il comporte uniquement une petite erreur sur les coefficients. Le code suivant doit marcher (sauf pour 0 ! ):
Code:

1 2 3 4 5 6 7 8 9 float readFloat(unsigned char* buf) { float result = buf[0]; result = result/256 + buf[1]; result = result/256 + (buf[2] | 0x80); unsigned exp = unsigned(buf[3] & 0x7F) * 2 + ((buf[2] & 0x80) != 0 ? 1 : 0) - 134; return (buf[3] & 0x80) != 0? -ldexp(result, exp) : ldexp(result, exp); }

13/01/2006, 18h08
zax-tfh

Jean Marc : ok, donc en gros ça veut dire que je n'ai pas vraiment à me préoccuper de la taille d'un type quoi ^^ Ca m'enleve une épine du pied, surtout pour un petit soft comme je suis en train de faire, c'est purement pour l'apprentissage, c'est tout.

Diogene : merci pour le code que tu as mis, en fait je ne l'avais pas vu, bizarrement... Donc merci à Jean Marc ! Je pense que le probleme de l'infini ne se posera pas vu que ce sont des coordonnées de Vertex donc il me semble que ce soit obligatoirement fini. Par contre pour les nan, vu que je ne sais pas ce que cela veut dire, je vais vite aller me renseigner et voir si dans mon cas c'est important ou pas.
En tout cas j'ai testé le code sur mes deux machines et ça passe nickel chrome !

Merci à tous !
@ bientot
13/01/2006, 20h27
Jean-Marc.Bourguet

Citation:

Envoyé par zax-tfh

Par contre pour les nan, vu que je ne sais pas ce que cela veut dire, je vais vite aller me renseigner et voir si dans mon cas c'est important ou pas.

NaN : Not a Number. Il y a peu de risques que ce soit important.
13/01/2006, 23h46
zax-tfh

En effet, il y a peu de risque vu que primo je recupere le float d'un format fixé et respectant la norme et que deuxio je ne fais pas d'operation sur le float ^^

Encore merci a vous tous ;)

Fuseau horaire GMT +2. Il est actuellement 02h31.