Conversion d'un nombre décimal en nombre double en C# entraîne une différence

Résumé du problème:

Pour des valeurs décimales, lorsque nous convertir le type de décimal à double, une petite fraction est ajouté à la suite.

Ce qui est pire, c'est qu'il peut y avoir deux "égalité" des valeurs décimales qui sont le résultat de différentes valeurs double lors de la conversion.

Exemple de Code:

decimal dcm = 8224055000.0000000000m;  //dcm = 8224055000
double dbl = Convert.ToDouble(dcm);    //dbl = 8224055000.000001

decimal dcm2 = Convert.ToDecimal(dbl); //dcm2 = 8224055000
double dbl2 = Convert.ToDouble(dcm2);  //dbl2 = 8224055000.0

decimal deltaDcm = dcm2 - dcm;         //deltaDcm = 0
double deltaDbl = dbl2 - dbl;          //deltaDbl = -0.00000095367431640625

Regardez les résultats dans les commentaires. Les résultats sont copiés à partir du débogueur regarder.
Les chiffres qui produisent cet effet ont beaucoup moins de chiffres après la virgule que la limite des types de données, de sorte qu'il ne peut pas être un dépassement de capacité (je suppose!).

Ce qui le rend beaucoup plus intéressant, c'est qu'il peut y avoir deux égal les valeurs après la virgule (dans l'exemple de code ci-dessus, voir "dcm" et "dcm2", avec "deltaDcm" égal à zéro) résultant de différentes double des valeurs lors de la conversion. (Dans le code, "dbl" et "dbl2", qui n'est pas nulle "deltaDbl")

J'imagine que ça doit être quelque chose lié à la différence de la bit-à-bit de la représentation des nombres dans les deux types de données, mais ne peut pas comprendre ce qui! Et j'ai besoin de savoir quoi faire pour faire de la conversion de la manière dont j'ai besoin c'est d'être. (comme dcm2 -> dbl2)

J'ai signalé ce problème sur MS Connecter. Voici le lien: connect.microsoft.com/VisualStudio/feedback/...
Je ne suis pas sûr de ce qui est la raison, mais il semble que le problème est dans l' (6) un grand nombre de décimales. J'ai testé avec 5 décimales et fonctionne très bien. J'ai même scénario où je transformer un nombre décimal en double et en arrière, et depuis ma précision n'est que de 2 décimales, mon code est sûr converti.

InformationsquelleAutor Iravanchi | 2009-10-18

c#decimal double

49

Intéressant - même si en général je n'ai pas confiance en normal façons d'écrire des valeurs à virgule flottante lorsque vous êtes intéressé par le résultat exact.

Ici est un peu plus simple démonstration, à l'aide de DoubleConverter.cs que j'ai utilisé à quelques reprises avant de.
```
using System;

class Test
{
    static void Main()
    {
        decimal dcm1 = 8224055000.0000000000m;
        decimal dcm2 = 8224055000m;
        double dbl1 = (double) dcm1;
        double dbl2 = (double) dcm2;

        Console.WriteLine(DoubleConverter.ToExactString(dbl1));
        Console.WriteLine(DoubleConverter.ToExactString(dbl2));
    }
}
```
Résultats:
```
8224055000.00000095367431640625
8224055000
```
Maintenant, la question est pourquoi la valeur d'origine (8224055000.0000000000) qui est un entier - et exactement représentable comme un double - se termine avec des données supplémentaires. Je soupçonne fortement que c'est en raison de bizarreries dans l'algorithme utilisé pour convertir de decimal à double, mais c'est malheureux.

Il viole également l'article 6.2.1 de la C# spec:

Pour une conversion de décimal de type float ou double, la valeur décimale arrondie à la
plus proche, double ou float valeur. Bien que cette conversion peut perdre de la précision, il ne provoque jamais de problème
la levée d'une exception.

Le "plus proche du double de la valeur" est clairement 8224055000... donc c'est un bug de l'OMI. Ce n'est pas celui que je m'attends à obtenir fixe tout moment bientôt cependant. (Elle donne les mêmes résultats .NET 4.0b1 par le chemin.)

Pour éviter le bug, vous voulez probablement pour normaliser la valeur décimale d'abord, effectivement "retrait" de l'extra-0 après la virgule. C'est un peu difficile car il implique de 96 bits arithmétique des nombres entiers - le .NET 4.0 BigInteger classe peuvent le rendre plus facile, mais qui peut ne pas être une option pour vous.
- C'est un bug de l'OMI trop. Avez-vous/tout le monde signalé à Microsoft? Je suis à la recherche de connexion MS et ne peut pas voir tout ce qui est lié. Donc, je vais le poster. Je veux juste savoir si elles confirment ce que d'un bug ou non.
- 96 bits de l'arithmétique n'est pas nécessaire dans ce cas particulier, parce que l'on peut obtenir decimal faire le gros du travail 🙂
- Fascinant bug! Anton Tykhyy notes, ce n'est presque certainement parce que la représentation de décimales avec beaucoup plus de précision n'est plus "natif" dans les entiers qui s'inscrivent dans un double sans représentation d'erreur. Je serais prêt à parier jusqu'à un dollar que ce bug a été dans OLE Automation pour les quinze ans-nous utiliser les OA des bibliothèques pour les décimales de codage. J'ai justement une archive de l'ARTHROSE sources de dix ans sur ma machine; si j'ai du temps libre demain, je vais prendre un coup d'oeil.
- Soutien à la clientèle n'est pas beaucoup mieux que cela 🙂
- J'ai utilisé une partie de votre réponse lors de la déclaration de ce problème sur la connexion MS (Le C# spec partie). Merci pour l'info.
- si vous avez déjà Eric oreille, vous avez une bonne longueur d'avance ;-p
- Quant au "pourquoi", essayez de diviser 2E23/1E21, ou 2E25 par 1E23, et de voir comment les résultats sont à comparer avec une valeur décimale en double conversions qui impliquerait de ces divisions.
- J'ai récemment eu ce problème lors de la récupération des valeurs de la base de données Oracle. Aucun des entiers impliqués : Oracle Nombre(3,1) récupéré dans un DataRow contenant des objets, objet contenant à la valeur désirée dans la fenêtre espion express. À l'aide de Convert.ToDouble(object) retourne mauvaises valeurs : 8.4 devient 8.39999..., 9.1 devient 9.1000003... . Mon laid solution de contournement : arrondir les valeurs retournées par la conversion à l'aide de la précision attendue de l'oracle de la valeur.
- Bien qu'est-ce que le temps d'exécution type de l'objet? Je m'attends à être decimal.
- Skeet : c'est un Single
- Ok - c'est vraiment regrettable. Si vous êtes en essayant de préserver la décimal chiffres d'une précision spécifique, decimal est un meilleur type à utiliser... c'est une honte si la base de données est le processus de conversion à float automatiquement 🙁
- Je suis de retour d'un long chemin de retour, mais avez-vous plus d'information sur ce bug? Était-il corrigé?
InformationsquelleAutor Jon Skeet
25

La réponse réside dans le fait que decimal tente de conserver le nombre de chiffres significatifs. Ainsi, 8224055000.0000000000m a 20 chiffres significatifs et est stockée en tant que 82240550000000000000E-10, tandis que 8224055000m a seulement 10 et est stockée en tant que 8224055000E+0. double's de la mantisse est (logiquement) 53 bits, c'est à dire à plus de 16 chiffres décimaux. C'est exactement la précision que vous obtenez lorsque vous convertir à double, et en effet la divagation des 1 dans votre exemple, dans le 16e décimale. La conversion n'est pas 1-de-1, parce que double utilise la base 2.

Voici les représentations binaires de vos numéros:
```
dcm:
00000000000010100000000000000000 00000000000000000000000000000100
01110101010100010010000001111110 11110010110000000110000000000000
dbl:
0.10000011111.1110101000110001000111101101100000000000000000000001
dcm2:
00000000000000000000000000000000 00000000000000000000000000000000
00000000000000000000000000000001 11101010001100010001111011011000
dbl2 (8224055000.0):
0.10000011111.1110101000110001000111101101100000000000000000000000
```
Pour le double, j'ai utilisé des points de délimiter le signe, l'exposant et la mantisse champs; pour les décimales, voir MSDN sur le système décimal.GetBits, mais essentiellement de la dernière 96 bits de la mantisse. Notez comment les bits de la mantisse de dcm2 et les bits les plus significatifs de dbl2 coïncident exactement (ne pas oublier l'implicite 1 peu dans double's mantisse), et, en fait, ces bits représentent 8224055000. Les bits de la mantisse de dbl sont les mêmes que dans dcm2 et dbl2 mais pour le méchant 1 dans le bit le moins significatif. L'exposant de dcm est de 10, et la mantisse est 82240550000000000000.

Mise à jour II: Il est effectivement très facile à lop off zéros à droite.
```
//There are 28 trailing zeros in this constant —
//no decimal can have more than 28 trailing zeros
const decimal PreciseOne = 1.000000000000000000000000000000000000000000000000m ;

//decimal.ToString() faithfully prints trailing zeroes
Assert ((8224055000.000000000m).ToString () == "8224055000.000000000") ;

//Let System.Decimal.Divide() do all the work
Assert ((8224055000.000000000m / PreciseOne).ToString () == "8224055000") ;
Assert ((8224055000.000010000m / PreciseOne).ToString () == "8224055000.00001") ;
```
- Cela fait sens, mais voir Jon Skeet réponse. Logiquement, en précisant plus de chiffres significatifs, devrait aboutir à une conversion plus précise, pas un pire! Est-il un moyen de convertir du décimal à celui qui a "moins" de chiffres significatifs? Il devrait en résulter une meilleure conversion dans mon cas!
- La conversion est plus précises, vous obtenez 6 chiffres supplémentaires — mais le résultat n'est pas ce que vous attendez, car décimal et double les bases sont différentes. Je vais ajouter exemple momentanément.
- Ce n'est pas une conversion plus précise. La valeur exacte de la décimale est disponible, il doit donc être renvoyée. Je peux voir pourquoi cela arrive, mais ce n'en est pas de droite 🙂
- Eh bien, si vous comprenez "précis" dans ce sens, je suis d'accord.
- Merci, représentations binaires sont très utiles. Je sais que c'est ce qui se passe, mais ma question est "pourquoi" exactement la conversion de place que "1" à la fin? La conversion d'une plus grande précision de la valeur à une faible valeur de précision est censé effectuer l'arrondi. C'est comme lors de la conversion "0.0" en entier, il en résulte 0, mais la conversion "0.000000000000" en entier les résultats de 1!
- Il est arrondi, mais pas à un chiffre décimal (base 10), mais pour un chiffre binaire (base 2).
- Arrondi à la Base 2 devrait produire le même résultat. Pourquoi, lorsque plus de chiffres spécifiés dans le décimal, il obtient arrondi à "1", mais quand le nombre de chiffres spécifié il obtient arrondi à "0" ?
- C'est un savant peu de code, mais je ne sais pas si l'algorithme pour décider du nombre de chiffres significatifs est bien spécifié. Je pense que je serais personnellement plutôt l'utilisation d'un grand nombre entier de la bibliothèque et de le faire d'un point de vue théorique - mais comme je l'ai dit, c'est un chouette morceau de code.
- Comme pour "exactes" - assez simple mesure de précision est: "quelle est la différence entre le nombre exact étant représenté pour commencer, et la valeur exacte du résultat de la conversion"? 0 représente l'exactitude complète - au moins en termes de l'ampleur du nombre, et est disponible dans ce cas. C'est ce que je voulais dire. Que le double n'est pas un concept de la "le nombre de chiffres significatifs" je ne crois pas que la précision peut mesurer en ces termes. (Il pourrait pour les autres conversions, par exemple, à un autre type ne préserver le nombre de chiffres significatifs.)
- Bon point environ le double de ne pas avoir de chiffres significatifs. Aussi, il y a un moyen beaucoup plus facile de couper les zéros de fin de ce morceau de code que j'ai écrit (voir l'exemple de code).
- Bon travail sur la PreciseOne truc. J'ai l'intention d'utiliser ce avant toutes les décimales à double conversions pour s'assurer que la précision et la représentation de la virgule n'est pas de créer des incohérences lors de la fonte ou de la conversion.
InformationsquelleAutor
5

L'article Ce Que Tout Informaticien Devez Savoir À Propos De L'Arithmétique À Virgule Flottante serait un excellent endroit pour commencer.

La réponse courte est que virgule flottante binaire arithmétique est nécessairement un rapprochement, et il n'est pas toujours le rapprochement vous dirais. C'est parce que les Processeurs ne l'arithmétique en base 2, alors que l'homme (en général) de faire de l'arithmétique en base 10. Il y a une grande variété d'effets inattendus qui en découlent.
- Merci pour le lien de l'article, c'est très long, mais je vais essayer de le lire. Base 2 arithmétique vs Base 10 de l'arithmétique est ce que je me méfiais de, mais il ya deux points: 1. virgule a 28-29 chiffres significatifs, et double a 15-16 chiffres significatifs. 8 chiffres significatifs sont assez pour que mon numéro. Pourquoi faut-il le traiter comme ça? Et tant qu'il y a une représentation de l'origine nombre en double, pour lesquelles la conversion devrait se traduire dans un autre? 2. Ce que les deux "mêmes" valeurs décimales se converti à différents doubles?
- Le nombre de chiffres significatifs n'est pas particulièrement pertinent - "0.1" n'a qu'un seul chiffre significatif, mais tout n'est pas représentable en float/double. Le point sur y être une représentation exacte disponible est beaucoup plus significatif. Comme pour les deux valeurs de donner différents lits doubles, ils sont égal, mais ils ne sont pas les même.
- Est-il un moyen de convertir ces "égaux mais pas identiques" décimales pour les uns les autres? Et est-il un moyen de voir que dans le débogueur? (Je suppose que je devrais voir le bit à bit de la représentation, mais il n'y a pas une telle option dans VS. Et "l'affichage Hexadécimal" ne fonctionne pas de cette façon non plus)
- Décimal.GetBits vous donnera le bit à bit de la représentation - vous voulez normaliser par qui. Il ne sera pas facile 🙁 savez-vous que la valeur est en fait, un entier? Si oui, ça aiderait...
- Le nombre qui est "réellement" un nombre entier de cette instance. Mais il peut être un non-entier. Ce qui est sûr, c'est qu'il n'est pas (et ne veut pas) avoir 16 chiffres significatifs.
- Irchi: il est très facile de convertir des "égaux mais pas identiques" décimales, voir mon exemple de code. Aussi Decimal.ToString() fidèlement vous montre les zéros à droite, de sorte que vous pouvez distinguer les "égaux mais pas identiques" décimales par que, même en VS du débogueur montre normale etc. de windows.
InformationsquelleAutor Greg Hewgill

De voir que ce problème plus clairement illustré essayer dans la LinqPad (ou remplacer tous les .Dump()'s et changer de Console.WriteLine()s, si vous avez envie).

Il semble logiquement incorrecte pour moi que la précision des décimales pourrait résultat en 3 doubles. Bravo à @AntonTykhyy pour l' /PreciseOne idée:

((double)200M).ToString("R").Dump(); //200
((double)200.0M).ToString("R").Dump(); //200
((double)200.00M).ToString("R").Dump(); //200
((double)200.000M).ToString("R").Dump(); //200
((double)200.0000M).ToString("R").Dump(); //200
((double)200.00000M).ToString("R").Dump(); //200
((double)200.000000M).ToString("R").Dump(); //200
((double)200.0000000M).ToString("R").Dump(); //200
((double)200.00000000M).ToString("R").Dump(); //200
((double)200.000000000M).ToString("R").Dump(); //200
((double)200.0000000000M).ToString("R").Dump(); //200
((double)200.00000000000M).ToString("R").Dump(); //200
((double)200.000000000000M).ToString("R").Dump(); //200
((double)200.0000000000000M).ToString("R").Dump(); //200
((double)200.00000000000000M).ToString("R").Dump(); //200
((double)200.000000000000000M).ToString("R").Dump(); //200
((double)200.0000000000000000M).ToString("R").Dump(); //200
((double)200.00000000000000000M).ToString("R").Dump(); //200
((double)200.000000000000000000M).ToString("R").Dump(); //200
((double)200.0000000000000000000M).ToString("R").Dump(); //200
((double)200.00000000000000000000M).ToString("R").Dump(); //200
((double)200.000000000000000000000M).ToString("R").Dump(); //199.99999999999997
((double)200.0000000000000000000000M).ToString("R").Dump(); //200
((double)200.00000000000000000000000M).ToString("R").Dump(); //200.00000000000003
((double)200.000000000000000000000000M).ToString("R").Dump(); //200
((double)200.0000000000000000000000000M).ToString("R").Dump(); //199.99999999999997
((double)200.00000000000000000000000000M).ToString("R").Dump(); //199.99999999999997
"\nFixed\n".Dump();
const decimal PreciseOne = 1.000000000000000000000000000000000000000000000000M;
((double)(200M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.0M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.00M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.0000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.00000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.0000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.00000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.0000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.00000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.0000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.00000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.000000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.0000000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.00000000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.000000000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.0000000000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.00000000000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.000000000000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.0000000000000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.00000000000000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.000000000000000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.0000000000000000000000000M/PreciseOne)).ToString("R").Dump(); //200
((double)(200.00000000000000000000000000M/PreciseOne)).ToString("R").Dump(); //200

Je pense que la clé pour comprendre ce qui se passe est à imprimer 2E23/1E21 et 2E25/2E23. La conversion de Decimal à double est effectuée par la division d'un entier par une puissance de dix, même si ce peut introduire une erreur d'arrondi.

InformationsquelleAutor Ilan

1

C'est un vieux problème, et a été l'objet de beaucoup de questions similaires sur StackOverflow.

La simpliste explication est que les nombres décimaux ne peuvent pas être exactement représenté en binaire

Ce lien est un article qui pourrait expliquer le problème.
- Qui n'a pas l'expliquer, en fait. Beaucoup nombres décimaux ne peuvent pas être exactement en binaire - mais dans ce cas, l'entrée peut être exactement représenté en binaire. Les données sont perdues inutilement.
- Jon, les données n'est pas perdu, au contraire — c'est le inutilement préservé (à partir de Irchi POV, aucune infraction) les données du problème.
- Anton, voir la spécification posté par Jon. La inutilement conservé les données ne devraient pas gâcher la conversion. Après les 16 chiffres significatifs, la valeur décimale indique les chiffres à tous les "0". Pourquoi devrait-il être arrondi à "1" dans le 16ème position?! "0" est plus proche de la "exact" décimal de la valeur de "1".
- Je ne sais pas à propos de "devraient" pas être un homme — mais c'est comment il se comporte et que la seule question est de savoir quoi faire à propos de ce comportement.
- J'ai souligné le mot "simpliste" dans ma réponse, pour l'enregistrement.
- Mon point est que je ne crois pas que c'est vraiment un cas de la situation normale qui a conduit à de nombreuses autres questions. Généralement, vous avez un certain nombre qui ne peut pas être représentée exactement comme un double. Dans ce cas, nous n'avons pas.
- oui, vous avez raison, je n'avais pas regardé de près: les chiffres sont à peu près entiers. Il n'y a aucune raison pourquoi les données doivent être "perdu", il doit être dans le decimal à double de conversion
InformationsquelleAutor pavium

Vous devez vous connecter pour publier un commentaire.