de float à int : partie entière automatique ?

**stokastik** · 22/08/2006, 14h43

Bonjour,

Il me semble qu'avec ce code, n est la partie entière de x :

Code :

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

1
2
3
4
 
 float x=2.11;
 int n;
 n=x;

c'est bien vrai ?

**Médinoc** · 22/08/2006, 14h46

Je me permets de poser la même question avec

Code :

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

1
2
3
 float x=2.73;
 int n;
 n=x;

**Pragmateek** · 22/08/2006, 14h51

Envoyé par Médinoc

Je me permets de poser la même question avec

Code :

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

1
2
3
 float x=2.73;
 int n;
 n=x;

When a finite value of real floating type is converted to an integer type other than _Bool,
the fractional part is discarded (i.e., the value is truncated toward zero). If the value of
the integral part cannot be represented by the integer type, the behavior is undefined.50)

selon la norme Draft 9899 chapitre 6.3.1.4 point 1

**homeostasie** · 22/08/2006, 14h51

Oui pour ces deux cas on récupère la valeur 2, on arrondit donc toujours au nombre entier inférieur.

**gege2061** · 22/08/2006, 14h51

ça ne devrait pas compiler, avec les options de compilations nécessaires, mais qu'est ce qui vous empêche de faire le teste ?

**Médinoc** · 22/08/2006, 14h53

La flemme.
La peur du "dépendant de l'implémentation" : Il fallait la norme.
L'effet "Il a osé, alors j'ose aussi".

**DaZumba** · 22/08/2006, 15h01

Envoyé par gege2061

ça ne devrait pas compiler, avec les options de compilations nécessaires, mais qu'est ce qui vous empêche de faire le test ?

Pourquoi cela ne devrait-il pas compiler ? Affecter un flottant a un entier est tout a fait prevu par le langage, comme la citation de la norme par seriousme a montre.

Et effectivement, un test prend environ 3 sec. Mais c'est plus fun de faire bosser les autres, j'imagine:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
 
#include <stdio.h>
 
int main(void)
{
  float x = 2.11;
  int n;
 
  n = x;
  printf("%d\n", n);
 
  return 0;
}

Code :

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

1
2
3
4
 
$ gcc -W -Wall -ansi -pedantic toto.c -o toto
$ ./toto
2

**gege2061** · 22/08/2006, 15h20

Envoyé par DaZumba

Pourquoi cela ne devrait-il pas compiler ?

Je n'ai pas d'erreur non plus

Normalement le compilateur devrai t'avertir qu'il y a une perte de donnée possible

Mais c'était juste histoire de leur faire sortir le compilateur

**Pragmateek** · 22/08/2006, 15h32

Envoyé par gege2061

Je n'ai pas d'erreur non plus

Normalement le compilateur devrai t'avertir qu'il y a une perte de donnée possible

Oui car c'est un comportement indéfini si le "float" est trop grand:

If the value of the integral part cannot be represented by the integer type, the behavior is undefined.

**Jean-Marc.Bourguet** · 22/08/2006, 15h38

Envoyé par homeostasie

Oui pour ces deux cas on récupère la valeur 2, on arrondit donc toujours au nombre entier inférieur.

Non, vers 0. Il y a une différence pour les nombres négatifs. Si on veut l'entier inférieur, il faut utiliser floor et ceil pour l'entier supérieur; ces deux fonctions retournent des doubles, mais tu peux après utiliser la conversion implicite d'entier en double

**Médinoc** · 22/08/2006, 15h44

Au fait: Est-ce que floor(2.5) est garanti par la norme retourner une valeur qui ne soit pas inférieure à 2 (il faut que ce soit 2.00000000000001 plutôt que 1.99999999999999) ?
(Est-ce que la norme garantit que (int)floor(2.5) rendra toujours 2 sur toutes les plate-formes et jamais 1 ?)

man floor ne me dit rien du tout à ce sujet...

**koala01** · 22/08/2006, 15h51

Envoyé par gege2061

Je n'ai pas d'erreur non plus

Normalement le compilateur devrai t'avertir qu'il y a une perte de donnée possible

Mais c'était juste histoire de leur faire sortir le compilateur

Héhé... Les avertissements, s'il y en a, n'empechent nullement la compilation...

Ils sont "juste là" pour attirer ton attention sur le fait que tu adoptes un comportement "qui pourrait éventuellement poser problème" ou "dont il ne voit pas l'utilité"
(exemples:
warning variable is defined but never used "pourquoi donc s'em...-t-il à déclarer une variable sans l'utiliser"
warning comparaison between signed and unsigned "a-t-il pensé au fait qu'il y a un bit en moins pour le signed int que pour le unsigned (il sert au signe et n'entre pas dans l'évaluation de la valeur absolue du int)"
warning comparaison between real and integer is never true "du fait de la différence de format et de la représentation en mémoire des entier et des reels, il y a bien plus de chances que la comparaison soit fausse que de chances qu'elle soit juste"
et tous ceux qui ont trait à la mauvaise utilisation des pointeurs (risque de plantage aléatoires))

On peut "estimer" (à tord ou à raison) que le compilateur pourrait suivre un raisonnement du genre de "les gens savent bien que, si s'ils transforment un réel en entier, ils perdront la partie decimale"

Le but des avertissements n'est que de signaler qu'il y a un risque potentiel de comportement aléatoire

J'ai meme eu un prof qui, quand il demandait un travail en C, allait en priorité voir les lignes sur lesquelles apparaissaient les avertissements...

Comme, bien souvent, il s'agissait de lignes où des pointeurs étaient mis en oeuvre, il se doutait que la ligne risquait réellement de poser un probleme à un moment ou un autre

**Pragmateek** · 22/08/2006, 15h52

Au fait: Est-ce que floor(2.5) est garanti par la norme retourner une valeur qui ne soit pas inférieure à 2

"floor" se contente de prendre la partie entière et de la renvoyer convertie en "double" donc à priori pas de problème.

**Jean-Marc.Bourguet** · 22/08/2006, 15h52

Envoyé par Médinoc

Au fait: Est-ce que floor(2.5) est garanti par la norme retourner une valeur qui ne soit pas inférieure à 2 (il faut que ce soit 2.00000000000001 plutôt que 1.99999999999999) ?
(Est-ce que la norme garantit que (int)floor(2.5) rendra toujours 2 sur toutes les plate-formes et jamais 1 ?)

J'ai pas envie de me lancer dans une exégèse de la norme pour voir ce qu'elle garanti à ce sujet. Mais en pratique je ne vois pas de raisons pour laquelle une implémentation ne le ferait pas: aucun format de flottant que je connais permet de représenter un nombre sans pouvoir représenter l'entier immédiatement inférieur ou égal. La plupart des surprises qu'on a avec les flottants sont dues à l'impossibilité de représenter exactement le nombre exact qui est le bon résultat d'un calcul.

**Médinoc** · 22/08/2006, 15h53

Ah, suis-je bête: La partie entière est exacte, en effet...

**Ti-R** · 22/08/2006, 16h38

Code :

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

1
2
3
4
5
	float t_f = (float)10000003.0 + (-(float)10000000.0 + (float)7.501);
	printf("%f\n",t_f);
 
	t_f = ((float)10000003.0 -(float)10000000.0) + (float)7.501;
	printf("%f\n",t_f);

Dans les trucs qui peuvent surprendre...

source

**stokastik** · 22/08/2006, 16h51

ça ne devrait pas compiler, avec les options de compilations nécessaires, mais qu'est ce qui vous empêche de faire le test ?

Je l'ai fait! (et avec plusieurs valeurs...) je me demandais en fait si c'était correct de faire ça.

de float à int : partie entière automatique ?

C

Discussions similaires

Partager

Partager