Version imprimable
Bonjour, j'aimerai savoir s'il est possible d'éviter la troncature lors de la conversion d'un float vers un int. Mon but est de retrouver ma valeur de départ sans aucune perte information. Est ce que c'est possible? Il existe un astuce a connaitre comme passer par des chaines de caractère?
Merci d'avance pour vos réponses.Code:
2
3
4
5
6
que voulez-vous dire par là ?
Mauvais clic désolé j'ai modifier mon message. Je suis un utilisateur occasionnel de bouml très pratique et utile comme programme.:ccool:Citation:
Envoyé par bruno_pages
Salut,
Il semblerait que quelques mots soient restés coincés dans le clavier, et je présumes donc que ta phrase termine par "conversion d'un float en int" :aie:
La réponse est non, tout simplement parce que int ne peut représenter que des valeurs entières.
Par contre, il est possible de demander un arrondi, suivant les règles mathématique (à l'unité inférieur si la partie décimale est inférieure à 5, à l'unité supérieure autrement), à l'unité supérieure en toutes circonstances ou à l'unité inférieure (ce qui revient au même que la troncature) en toutes circonstances avec les fonctions respectives round, ceill et floor.
la troncature n'a pas lieu lors du passage float -> int, elle a lieu lors du passage int -> float , car 2147483647 réclame plus que 23 bits pour être représenté
remplacez le float par un double et il n'y aura pas de problème de précision
Salut, je vois les fonctions dont tu parle tel que floor et ceil de <math.> pour faire des arrondis mais est ce qu'il serait possibles par un moyen ou un autre de ne garder que la partie entière lors du passage int -> float ->int. Je me disait en récupérant dans une chaine de caractère la partie entière du float peut on pourrait retomber sur nos pattes?
Citation:
Envoyé par koala01
que de réponses simultanées :lol: => lire ma précédente réponse ;)
Le fait est que la partie entière sera la partie la plus stable (du moins dans les limites des valeurs représentables) lors des conversions:
0.9 en float ou en double donnera 0 (si on n'utilise pas round ou ceil) en int et 0 en int donnera.... 0. 00000 en float ou en double (idem pour 12540.xxxxx).
Ce qui est plus embêtant, c'est que si tu converti un float en int, que ce soit avec troncature ou avec arrondi, puis que tu reconverti ce int en float, tu perd, purement et simplement, la partie décimale :aie:
Cette troncature dans ce sens la int -> float ne me dérange pas c'est celle dans l'autre sens float -> int qui me pose problème de plus je travaille avec des données codées sur 64bit( int64 -> float64-> int64 ). Je suppose que c'est le même problème avec des entier sur 32 bitsCitation:
Envoyé par bruno_pages
Si je rentre la valeur maximum et minimum en entrer j'obtiens le même résultat au final.
int64 -> float64-> int64
min -9223372036854775808 -> -9223372036854775808
max 9223372036854775807 -> -9223372036854775808
Je devine bien que -9223372036854775808 correspond à la partie entière de mon float qui doit être 7FFF FFFF. Est ce qu'il existe une moyen de tricher lors du passage float -> int pour retourner au résultat du début.
Pour vous donner une id de ce que j'essaye de faire, je travail avec un float64 dont j'ai supposé à tord qu'il pouvait contenir tout les autres types ensuite j'effectue une conversion d'où celle qui m'intéresse float64 vers int64
Lors de mes test avec mes valeurs max pour chaque type je constate que le passage float64 vers int64 échoue. C'est tout bête comme problème mais sa arrive.Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Merci pour votre aide.
vous n'avez pas compris, c'est un problème de précision, et cela arrive lors du passage entier -> réel
à taille égale un réel est par définition moins précis qu'un entier car il faut stoker la mantisse et le signe (problème du signe uniquement si l'entier est non signé et récupère donc ce bit)
Si le float64 n'est qu'un stockage intermédiaire et que la valeur qui se retrouve dedans ne t'intéresse pas, tu peux simplement utiliser ses 64 bits sans tenir compte du fait que c'est un flottant. C'est en quelque sorte le mécanisme inverse de la fonction que tu nous as montré, qui restitue la valeur dans une variable en fonction du type interne.
D'ailleurs là tu peux prendre un char[8] plutôt qu'un float64, puisque tout ce qui t'intéresse sera d'avoir un espace mémoire de 64 bits.Code:*reinterpret_cast<int64_t*>(&fValue) = le_int_64;
Et si tu fais ça, assure-toi bien qu'aucun des types que tu gères ne dépasse 64 bits.
ou bien-sûr utiliser une union
Ok j'ai saisie la perte de précision, après réflexion c'est normal. Je me pose alors comme question qu'elles sont les valeurs maximum et minimum pour mon int64 pour que le passage int64 -> float64 -> int64 fonctionne. La limitation serait donc égale au maximum et au minimum que je peut coder sur la partie entière de mes float 64bits.
Merci pour votre j'utilise bouml et mingw et mine de rien vos aides sont super utiles et super bien faites.
Super comme idée, je vais voir si je peut la mettre en œuvre vu que je fait quelques opérations sur mon float64. :ccool:
Citation:
Envoyé par Laurent Gomila
je veux pas casser l'ambiance, mais de mémoire déréférencer un pointeur issu d'un reinterpret_cast est une Undefined Behavior.
L'union me semble être la solution la plus évidente étant donné ce qu'on sait du problème.
Il me semble qu'on est plutôt dans le défini par l'implémentation sauf si en fait on revient au type initial (càd que le pointeur casté provient lui-même d'un cast) auquel cas le comportement est garanti aux conditions d'alignement.Citation:
Envoyé par Joel F
Le code présenté n'est pas dans ce cas, le pointeur casté provenant d'un &.
Essayer de représenter sans perte des entiers sur 64 bits dans des flottants sur 64 bits est voué à l'échec sur les plateformes IEE754. On est certain que certains entiers devront être codés comme NaN et même comme NaN signalant, avec un risque élévé d'effets indésirables dans les manipulations intermédiaires.
:aie: j'avais une chance sur deux. Je me susi tellement fait avoir que je paranoise :cry:Citation:
Envoyé par Jean-Marc.Bourguet