Cette question fait référence aux numéros de points flottants standard IEEE utilisés sur C / x86.
est-il possible de représenter tout numérique (c'est-à-dire à l'exclusion des valeurs spéciales telles que la NAAN) flotter ou double comme une chaîne décimale telle que la conversion de cette chaîne vers le dos à un flotteur / double donnera toujours exactement le nombre d'origine?
Sinon, quel algorithme me dit si un numéro donné subira une erreur de conversion?
Si tel est le cas, considérez ceci: certaines fractions décimales, lorsqu'elles sont converties en binaires, ne seront pas numériquement identiques à la valeur décimale originale, mais l'inverse n'est pas vrai (car le binaire a borné la précision afin que toute expansion décimale soit finie et Parfait si pas tronqué), alors voici une autre question ...
Est-il nécessaire d'introduire des erreurs délibérées dans la représentation décimale afin d'asperger le Atof (ou autre) pour donner le numéro d'origine exacte, ou un code naïf et non tronquant > La fonction est adéquate (en supposant que la conversion exacte soit possible en général)?
3 Réponses :
étant donné que le format IEEE ne peut représenter qu'un nombre fini de chiffres (binaires), et donc une précision minimale (cf. epsilon), vous n'aurez besoin que d'un nombre fini de chiffres (décimaux). Bien sûr, il est préférable que la mise en œuvre ( strtod , snprintf ) a un comportement de mappage d'identité entre {tous les floatts} et l'ensemble de {une représentation décimale pour chaque float}.
Selon Cette page :
En réalité, la norme IEEE754-1985 indique que 17 chiffres décimaux est assez dans tous les cas. Cependant, il semble que la norme soit un peu vague sur si les implémentations conformes doivent garantir la perte sans perte conversion lorsque 17 chiffres sont utilisés.
SE SOIN SE stockez un
Double comme une chaîne décimale avec au moins 17 chiffres (correctement arrondi) garantira qu'il peut être converti en binairedouble sans perte de données.En d'autres termes, si toutes les valeurs de double précision possibles devaient être converties en une chaîne décimale de 17 chiffres (arrondi correctement arrondi), ils feront toutes la carte pour différentes valeurs. Ainsi, il n'y a pas de perte de données.
Je ne suis pas sûr de la coupure minimale pour une précision unique. Mais je soupçonnerais que ce sera 8 ou 9 chiffres.
Il s'agit de 9 chiffres pour les flotteurs (voir page 4 de CS.berkeley.edu/ ~ wkaan / ieee754status / ieee754.pdf ; également, voir le papier de Goldberg, section "Binaire à la conversion décimale".)
Vous mentionnez "correctement arrondi". N'est-ce pas une échappatoire? Quelles implémentations ne veulent généralement pas ou ne peuvent pas adhérer à? De plus, les implémentations réelles répondent-elles à cette garantie théorique?
en Java, il est possible de convertir un double de / sur une chaîne, en construisant un objet BigDecimal intermédiaire: Il n'y a pas de problème locale avec cette méthode.
Cependant, une double valeur spéciale (Infinite, NAN) ne fonctionnera bien sûr pas.
Quelle langue / environnement? Des symboles que vous mentionnez, cela pourrait être JavaScript, ou cela pourrait être C, ou cela pourrait être autre chose. (Un indigène
tostring sera presque certainement pas être adéquat pour un aller-retour véritablement sans perte.)