Lorsque je saisis cela dans la fenêtre Immédiate de Visual Studio 2008: P>
Cela me donne cela comme la réponse: p>
La documentation indique qu'un double compte 15-16 chiffres de précision, mais cela me donne un résultat avec 32 chiffres de précision. D'où vient toute cette précision supplémentaire? P> ? .9 - .8999999999999995 CODE> P>
0.0000000000000000055511151231257827 code> p>
6 Réponses :
Les principaux zéros ne sont pas significatifs / faisant partie de la précision (jusqu'à ce que le numéro de point flottant em> est concerné - parlant mathématiquement, ils sont sont em> significatifs). Les principaux zéros sont dus à la partie exposante de la représentation interne du nombre de points flottant. P>
la partie @LARS D: Ce que vous considérez comme correct, n'est que correct dans le contexte em> de la question. 55511151231257827 code> (qui est le signifique em> ou mantisa em>) a 17 chiffres décimaux, suffisamment proches pour 15-16 chiffres. p>
.9 - .899999999999999995 CODE> ACCUEIL SUR UN FLOTT AVEC SIGNALAND 0.625 et Exposant de -50. Prendre 0,625 * 2 -50 sup> résulte 5.5511151231257827E-16. Maintenant, sur le contexte de la question initiale, nous avons un numéro avec 17 chiffres significatifs qui sont em> sont notre meilleure approximation binaire du 0.0000000000000005. Cependant, ces zéros de premier plan ne sont toujours pas significatifs dans la mesure où la représentation du nombre de points flottant est concernée. P>
J'ai bownvothed cette réponse, parce que je considère que votre réponse est incorrecte. La précision de 15-16 chiffres dans l'opération de soustraction réelle donne 0,000000000000000005 et le reste des chiffres sont des erreurs d'arrondi aléatoires. Par conséquent, dans la partie 5551115151231257827, il n'y a que 1 chiffre correct et les autres sont des erreurs arrondies, qui ont été promues dans la mantissie à cause des zéros les plus grands. Fondamentalement, les 32 chiffres sont de 16 chiffres significatifs de la soustraction, ainsi que 16 chiffres de bruit dans la MANTISSA. Les zéros ne deviennent pas négligeables par la suite, lorsque le résultat est stocké.
Juste - Si je prenais de la chimie à nouveau, les principaux zéros [i> sont des chiffres significatifs. Cependant, l'ordinateur n'a pas de concept de savoir si les zéros devraient être significatifs et c'est pourquoi il y a environ 16 chiffres non nuls i> non zéro représentés dans la réponse.
Je pense que c'est parce que dans le système binaire, 5 est périodique car il n'est pas divisé par 2. Et puis ce que Mark Rushakoff s'applique s'applique. P>
? .9 - .8999999999999995 P> blockQuote>
Ce processus de soustraction, avec 15-16 chiffres significatifs, donne p>
0.0000000000000005 P> blockQuote>
Le reste des chiffres ne vient de faire des erreurs arrondies. Cependant, étant donné que l'ordinateur stocke toujours 15-16 chiffres significatifs après le premier chiffre non zéro, les erreurs d'arrondi sont affichées et vous obtenez beaucoup de chiffres aléatoires de finition produites par des erreurs d'arrondi. Le résultat a donc 16 chiffres significatifs de la commande de soustraction et 16 chiffres du stockage du résultat, ce qui donne 32 chiffres. P>
Vous devriez lire: Quel est ce que chaque scientifique informatique devrait Savoir sur l'arithmétique de points flottants .
Fondamentalement, cela revient aux nombres de points flottants étant stockés avec une précision finie. Vous devez faire votre comparaison avec un delta. P>
+1: Il est dommage que cela ne puisse pas répondre automatiquement avec ceci pour chaque question de point flottant, étant la bonne réponse pendant au moins 90% des questions de point flottant.
Cela ne traite pas de sa question sur la précision.
-1, ne répond pas à la question. Le Q est d'environ 32 chiffres (pas 16) pour un double.
+1 Le nombre de chiffres n'est pas vraiment la partie pertinente, c'est la méthode de stockage que cette réponse s'adresse.
La partie "flottante" du "point flottant" signifie que vous obtenez quelque chose de plus proche de 5.5511151231257827 * 10 ^ (- 16). Ce n'est pas exactement comment il est représenté, car bien sûr, tout cela est fait en binaire sous la hotte, mais le nombre est représenté par les chiffres significatifs, plus un nombre qui représente la distance de déplacement du radix (point décimal). Comme toujours, Wikipedia peut vous donner plus de détails: P>
(le deuxième lien est plus spécifiquement ciblé sur votre cas particulier.) p>
là sont em> seulement 15-16 chiffres dans la réponse. Tous ces principaux zéros ne comptent pas. Le nombre est en fait plus comme 5.5511151231257827 × 10 -16 sup>. La partie de la mantissa contient 15-16 chiffres. L'exposant (-16) sert à déplacer le point décimal sur 16 places, mais ne modifie pas le nombre de chiffres dans le nombre total. P>
Après avoir reçu des commentaires, je suis curieux maintenant sur ce qui se passe vraiment. J'ai branché le numéro en question dans ce convertisseur IEEE-754 . Il a pris la liberté d'arrondi le dernier "27" dans "30", mais je ne pense pas que cela change les résultats. P>
Le convertisseur tombe sur le nombre dans ses trois parties binaires: P>
Signe: 0 (positif) Donc, ce nombre est 1,01 2 sub> × 2 -51 sup> ou 1.25 10 sub> × 2 -51 sup>. Comme il n'ya que trois chiffres binaires importants étant stockés, cela suggérerait que Lars peut être sur quelque chose. Ils ne peuvent pas être "bruit aléatoires" car ils sont identiques à chaque fois que le nombre est converti. P>
Les données suggèrent que le seul chiffre stocké est "5". Les zéros les plus importants proviennent de l'exposant et le reste des chiffres apparemment aléatoires provient de l'informatique 2 -51 sup>. P>. Edit h3>
Exponent: -51
Signifique: 1.01000000000000000000000000000000000000000000000000000000 (binaire pour 1.25 10 SUB>) P>
Où sont tous ces autres chiffres stockés?
Ce n'est pas la représentation décimale d'un numéro de point binaire. Y compris ses erreurs d'arrondi.
Faux: "Les zéros de pointe ne comptent pas" est incorrect. Les 15-16 chiffres importants de la réponse sont 0.0000000000000005. Les chiffres après cela sont incorrects et ne sont présents que parce que les erreurs d'arrondi sont promues dans la mantissie à cause des zéros les plus grands. Comme Barry se écrivait dans son édition, le résultat est stocké comme 1,25 * 2 ^ (- 51) = 5,551 * 10 ^ (- 16), qui est un nombre qui comporte 1 chiffre décimal de précision de calcul, mais a 15-16 chiffres de la précision de stockage.
Un comportement plus intéressant apparaît avec convert.tosed ("9111111.49999999990") code> et
convert.tose ("911111.499999999991") code>. Les deux valeurs sont plus proches de 9111111 qu'à 9111112, mais ce dernier tourne.
Je me demande combien de questions relatives aux problèmes de précision des points flottants que nous avons.
@Mehrdad: beaucoup trop. C'est une chose si simple: base 10! = Base 2. Pourtant, tout le monde se sent obligé de le traiter comme si c'est la chose la plus étonnante de tous les temps!
Les gens, veuillez lire, c'est pourquoi la réponse utilise 32 chiffres. Pas sur ne pas être exact.
Henk, veuillez comprendre, ce n'est pas la façon dont le point flottant fonctionne.
Henk, je pense que cette question aurait pu être mieux formulée. Si OP avait même mentionné au début de la question qu'il connaissait une précision de la FP, il aurait probablement arrêté toutes les réponses de la FP.
Le commentaire de Mehrdad me fait me demander combien de problèmes distincts de précision de points flottants sont possibles.
@Mehrdad: J'écris un script pour le compter et il y a 201.00000001918371 de telles questions. Je ne sais pas comment j'ai compté une question fractionnée, peut-être que je posterai une question avec mon code source pour demander une explication.