de float à int : partie entière automatique ?

Bonjour,

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

Code:

---

1 2 3 4

float x=2.11; int n; n=x;

---

c'est bien vrai ?

Je me permets de poser la même question avec

Code:

---

1 2 3

float x=2.73; int n; n=x;

---

Citation:

---

Envoyé par Médinoc

Je me permets de poser la même question avec

Code:

---

1 2 3

float x=2.73; int n; n=x;

---

---

Citation:

---

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

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

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

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

Citation:

---

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:

---

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:

---

1 2 3 4

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

---

Citation:

---

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 :koi: Mais c'était juste histoire de leur faire sortir le compilateur :aie:

Citation:

---

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:

Citation:

---

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

---

Citation:

---

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 :)

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...

Citation:

---

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 :koi: Mais c'était juste histoire de leur faire sortir le compilateur :aie:

---

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 :P

Citation:

---

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.

Citation:

---

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.

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

Code:

---

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

Citation:

---

ç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.