Discussion :

[subzero01]

Bonjour,
sur un system 32 bits (mais ordinateur 64 bits) si on execute le code suivant :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
#include <iostream>
#include <limits>
#include <math.h>
 
using namespace std;
 
int main()
{
	double i=0;
 
	do
	{
		cout<<"i="<<i<<"\t2^i="<<pow((double)2, i)<<endl;
		i++;
	}while(pow((double)2, i) <= numeric_limits<unsigned long double>::max());
	cout<<endl<<endl<<"max = "<<numeric_limits<unsigned long double>::max()<<endl,
	cin.get();
}

j'obitiens le resultat suivant

- est ce que c'est normal que i va jusqu'à 1023 ? une explication sera la bienvenue.
- où est ce que apparait le terme 32 bits, 64bits dans ce cas ?
merci d'avance

[Elstak]

et bien je dirai :

la i s'arrete à 1023 car apres ta puissance va dépasser le max que tu affiche (donc ta boucle s'arrete).

32 bit, 64 bit? je vois pas le rapport avec ton code en fait...

[Sylvain Togni]

En passant, si quelqu'un peut m'expliquer ce qu'est un « unsigned long double » ? Visual 6 & 8 ont l'air de supporter ce type, ça me parait bien bizarre !

[Jean-Marc.Bourguet]

- est ce que c'est normal que i va jusqu'à 1023 ? une explication sera la bienvenue.

Oui, c'est l'exposant maximal dans le format flottant que tu utilises. En passant, pour tester le depassement de capacite de pow(), il faut avant l'appel remettre errno a 0 et apres tester si la valeur est toujours 0.

- où est ce que apparait le terme 32 bits, 64bits dans ce cas ?

Nulle part. Il y a peu de rapport entre la taille des registres d'usage general (ce a quoi correspond generalement -- il y a quelques exceptions provenant plutot de considerations markettings que techniques -- le nombre de bits d'un processeur) et les registres flottants, en particulier dans le cas d'une transition 32->64.

En passant, si quelqu'un peut m'expliquer ce qu'est un « unsigned long double » ? Visual 6 & 8 ont l'air de supporter ce type, ça me parait bien bizarre !

Bug ou extension de VC++.

[wiztricks]

Les nombres de type long double sont codés sur 80 bits dont :
* 64 bits pour la mantisse
* 15 bits pour l'exposant
* 1 bit pour le signe
Ce qui permet d'aller de -3.4*10^^-4932 à 3.4*10^^4932
Exemple:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
#include <iostream>
#include <limits>
#include <math.h>
 
using namespace std;
 
int main()
{
  cout << "long double: " << numeric_limits<long double>::max() << endl;
  cout << "double : " << numeric_limits<double>::max() << endl;
}

sort:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
$ ./test
long double: 1.18973e+4932
double : 1.79769e+308

-W

[Jean-Marc.Bourguet]

Les nombres de type long double

Je doute que le problème de Sylvain soit le long, je penche plutôt pour l'unsigned.

sont codés sur 80 bits dont :
* 64 bits pour la mantisse
* 15 bits pour l'exposant
* 1 bit pour le signe

C'est loin d'être universel. Il s'agit là d'une description de l'extended double de IEEE 754 qui a l'avantage d'être disponible en hard sur les x86; mais le support est en perte de vitesse -- SSE2 ne l'a pas et c'est vers l'usage de cette interface qu'on tends. Même un unixien hard core comme moi sais que Windows ne l'utilise plus depuis des années. Et un unixien comme moi sait que certaines plateforme -- Solaris sur Sparc -- ont un long double qui fait 128 bits.

[wiztricks]

Le post initial tourne sur Windows qui tourne généralement sur x86 sur lequel les "long double" sont définis ainsi.
Note: Je sais que des plates-formes plus exotiques supportent d'autres formats mais quel est le rapport?.

Avec ces informations, on peut se poser des questions sur le retour de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

numeric_limits<unsigned long double>::max()

pour peu qu'il soit raisonnable qu'il compile.

Car de fait le programme ne sort pas de la boucle pour la raison qu'on croit sauf à penser que le compilateur utilisé traduise long double en double

- W

[Médinoc]

C'est beaucoup plus compliqué que ça sous Windows:

• Les long double de Visual sont exactement la même chose que des double (64 bits)
• Alors que ceux de MinGW font 80 bits.

Le tout sachant que MinGW utilise la CRT de Visual, ce qui fait que sous MinGW, on ne peut pas afficher un long double avec printf().

[Jean-Marc.Bourguet]

Le post initial tourne sur Windows qui tourne généralement sur x86 sur lequel les "long double" sont définis ainsi.

Le choix d'un modele depend du processeur et de l'OS. Ma comprehension de discussion avec des collegues et d'autres discussions, c'est que Microsoft -- je ne sais pas pour les autres fournisseurs de compilateurs pour Windows -- a fait depuis longtemps le choix de ne plus donner acces au type extended double des x86 et d'avoir la meme representation pour long double que pour double.

Meme sur les x86, le support pour les extended double est finissant -- c'est uniquement dans le jeu d'instruction herite des 8087 et pas dans SSE2 et suivant, et il me semble me souvenir que le mode 64 bits ne donne plus acces au mode 8087 (mais ce peut etre une confusion induite par le fait que gcc utilise SSE par defaut en mode 64 bits et pas en mode 32 bits).

Note: Je sais que des plates-formes plus exotiques supportent d'autres formats mais quel est le rapport?.

Si tout ce qui n'est pas x86 est exotique et qu'il ne faut donc pas en signaler l'existance, desole. Mais un petit rappel quand meme, toutes applications confondues, l'architecture 32 bits la plus repandue est l'ARM (je suis loin d'etre sur que celle du 8051 ne l'est encore pas plus) et l'OS le plus repandu est Linux.

Avec ces informations, on peut se poser des questions sur le retour de

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

numeric_limits<unsigned long double>::max()

pour peu qu'il soit raisonnable qu'il compile.

L'utilisation d'unsigned n'est pas du tout raisonnable.

Car de fait le programme ne sort pas de la boucle pour la raison qu'on croit sauf à penser que le compilateur utilisé traduise long double en double

La boucle sort parce que pow a un overflow et qu'il est vraisemblable que dans ce cas la valeur retournee soit une representation de l'infini (et en plus ERANGE est assigne a errno).