Est-ce que quelques soit l'architecture de la machine h�te le format des floats et des doubles suivent ieee-754 (bit de signe, exposant, mantisse le tout en big endian)?
Version imprimable
Est-ce que quelques soit l'architecture de la machine h�te le format des floats et des doubles suivent ieee-754 (bit de signe, exposant, mantisse le tout en big endian)?
Non, mais 99% du march� oui. A quelques variantes pr�ts ( pas de NaN ou INF par exemple) et des architecture exotique comme IBM ou le MIPS de la PlayStation 2....
Merci
Bonjour,
A part sur des processeurs pour l'embarqu� o� on peut avoir des formats particuliers (p.e des doubles sur 4 octets), j'ai toujours vu un format IEEE-754 mais pas toujours en big-endian. Le but est souvent d'avoir le bit de signe � la m�me position que les entiers et donc des float/double en little-endian.
Le s�quence est toujours : signe + exposant biais� + mantisse
Donc le bit de poids faible du double est le bit de poids faible de la mantisse. Ce bit est dans le premier octet en little-endian et dans le dernier en big-endian. C'est normalement transparent � l'utilisateur. Ce code marche toujours (du moins en C, en C++ c'est � �viter):
Tant qu'on ne s'int�resse pas au d�tail des octets, et on a aucune raison de le faire, l'endianess est invisible du code.Code:
1
2
3
4
5
6
7
8
9
10 union { double db; int64_t in; unsigned char tab[8]; }; db = 3.1416; uint64_t mantisse = in & 0x001FFFFFFFFFFFFFL; // marche toujours, ne dépend pas de l'endianess assert( (in < 0) == (db < 0) ); // marche toujours (sauf nombre spéciaux : NaN ou -0) assert( tab[0] == (mantisse & 0xFF) ); // vrai seulement en little-endian assert( tab[7] == (mantisse & 0xFF) ); // vrai seulement en big-endian
Salut,
Non, il n'y a aucune obligation de ce c�t� l�. La repr�sentation des flottants, boutisme compris, est d�finie par l'impl�mentation. Et �a va m�me plus loin, le compilateur peut utiliser une impl�mentation compl�tement diff�rente de celle qui sera utilis�e � l'ex�cution, jusqu'� m�me produire des r�sultats tr�s diff�rents pour une m�me op�ration, suivant que celle-ci est calcul�e pendant la compilation ou � l'ex�cution. Quoiqu'il en soit, C et C++ exposent un certain nombre de macros, constantes ou fonctions qui permettent de savoir si iec(60)559 (nom du standard correspondant � la norme ieee754) est pris en charge, dans quelle mesure et le cas �ch�ant d'affiner sont comportement.
�a me donne envie de pleurer, c'est si dur de se mettre d'accord? :cry::cry::cry:
Ce que l'on dit c'est que �a n'est pas garanti, comme l'a pr�cis� kaitlin tu as des macros pour v�rifier si c'est le cas. C'est souvent le cas mais pas toujours, le format effectif est li� au format des donn�es du coprocesseur flottant, le langage n'y est pour rien. C'est pour cela que la norme ne peut pas imposer un format.
La constante std::numeric_limits<double>::is_iec559 indique si le double est bien "ISO/IEC/IEEE 60559:2011 is the same as IEEE 754-2008."
Aussi il n'y a pas toujours de coprocesseur flottant. Et combien m�me il existerait, rien oblige l'impl�mentation � l'utiliser. Et m�me si elle est en mesure de le faire, avec les options ad�quates on peut lui demander de ne pas le faire.
Les standards C et C++ d�finissent ceux que sont les flottants et ce qu'il faut en attendre, pas comment (obligatoirement) y parvenir. Donc quelque part ce degr� de libert� est un axe d'innovation. Et c'est d'autant plus remarquable si on regarde du c�t� de la lib standard, car c'est ce m�me degr� de libert� qui permet � la lib standard d'exister sous forme de diff�rentes impl�mentations et d'aboutir donc � l'�cosyst�me riche que l'on conna�t.