Die Umwandlung einer Dezimalzahl in eine Gleitkommazahl in C# führt zu einem Unterschied

Question

Zusammenfassung des Problems:

Für einige Dezimalwerte wird bei der Umwandlung des Typs von decimal in double eine kleine Bruchzahl zum Ergebnis hinzugefügt.

Noch schlimmer ist, dass es zwei "gleiche" Dezimalwerte geben kann, die zu unterschiedlichen Double-Werten führen, wenn sie umgewandelt werden.

Codebeispiel:

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

Schauen Sie sich die Ergebnisse in den Kommentaren an. Die Ergebnisse wurden aus der Beobachtung des Debuggers kopiert. Die Zahlen, die diesen Effekt erzeugen, haben weit weniger Dezimalstellen als das Limit der Datentypen, daher kann es kein Überlauf sein (vermute ich!).

Was noch viel interessanter ist, ist, dass es zwei gleiche Dezimalwerte geben kann (im obigen Codebeispiel sehen Sie "dcm" und "dcm2" mit "deltaDcm" gleich null), die zu unterschiedlichen Double-Werten führen, wenn sie umgewandelt werden. (Im Code "dbl" und "dbl2", die einen Nicht-Null-"deltaDbl" haben)

Ich vermute, es sollte etwas mit dem Unterschied in der bitweisen Darstellung der Zahlen in den beiden Datentypen zu tun haben, aber ich kann nicht herausfinden, was! Und ich muss wissen, was zu tun ist, um die Umwandlung so zu machen, wie ich es brauche. (wie z.B. dcm2 -> dbl2)

Answer 1

Interessant - obwohl ich im Allgemeinen den normalen Weg des Schreibens von Gleitkommazahlen nicht vertraue, wenn man an den genauen Ergebnissen interessiert ist.

Hier ist eine etwas einfachere Demonstration, die DoubleConverter.cs verwendet, die ich schon einige Male zuvor verwendet habe.

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));
    }
}

Ergebnisse:

8224055000.00000095367431640625
8224055000

Jetzt stellt sich die Frage, warum der ursprüngliche Wert (8224055000.0000000000), der eine Ganzzahl ist - und genau als double darstellbar ist - zusätzliche Daten enthält. Ich vermute stark, dass dies auf Eigenheiten im Algorithmus zurückzuführen ist, der von decimal in double konvertiert, aber das ist bedauerlich.

Es verstößt auch gegen Abschnitt 6.2.1 der C#-Spezifikation:

Für eine Konvertierung von decimal in float oder double wird der Dezimalwert auf den nächsten double- oder float-Wert gerundet. Auch wenn diese Konvertierung Präzision verlieren kann, führt sie niemals dazu, dass eine Ausnahme ausgelöst wird.

Der "nächste double-Wert" ist offensichtlich einfach 8224055000... also ist dies meiner Meinung nach ein Bug. Ich würde jedoch nicht erwarten, dass er bald behoben wird. (Übrigens gibt es dieselben Ergebnisse auch in .NET 4.0b1.)

Um den Bug zu vermeiden, möchten Sie wahrscheinlich den Dezimalwert zuerst normalisieren, indem Sie effektiv die zusätzlichen Nullen nach dem Dezimalpunkt "entfernen". Dies ist etwas knifflig, da es 96-Bit-Integer-Arithmetik erfordert - die .NET 4.0 BigInteger-Klasse kann dies möglicherweise erleichtern, aber das ist möglicherweise keine Option für Sie.

Answer 2

Die Antwort liegt darin, dass decimal versucht, die Anzahl der signifikanten Stellen zu erhalten. Somit hat 8224055000.0000000000m 20 signifikante Stellen und wird als 82240550000000000000E-10 gespeichert, während 8224055000m nur 10 hat und als 8224055000E+0 gespeichert wird. Die Mantisse von double besteht (logisch) aus 53 Bits, d.h. maximal 16 Dezimalstellen. Dies ist genau die Genauigkeit, die Sie erhalten, wenn Sie in double konvertieren, und tatsächlich ist die verirrte 1 in Ihrem Beispiel an der 16. Dezimalstelle. Die Konvertierung ist nicht 1-zu-1, weil double die Basis 2 verwendet.

Hier sind die binären Darstellungen Ihrer Zahlen:

dcm:
00000000000010100000000000000000 00000000000000000000000000000100
01110101010100010010000001111110 11110010110000000110000000000000
dbl:
0.10000011111.1110101000110001000111101101100000000000000000000001
dcm2:
00000000000000000000000000000000 00000000000000000000000000000000
00000000000000000000000000000001 11101010001100010001111011011000
dbl2 (8224055000.0):
0.10000011111.1110101000110001000111101101100000000000000000000000

Für double habe ich Punkte verwendet, um die Vorzeichen-, Exponenten- und Mantissenfelder zu trennen; für decimal siehe MSDN zu decimal.GetBits, aber im Wesentlichen sind die letzten 96 Bits die Mantisse. Beachten Sie, wie die Mantissenbits von dcm2 und die signifikantesten Bits von dbl2 genau übereinstimmen (vergessen Sie nicht das implizite 1-Bit in der Mantisse von double) und tatsächlich stellen diese Bits 8224055000 dar. Die Mantissenbits von dbl sind die gleichen wie bei dcm2 und dbl2, jedoch mit der lästigen 1 im am wenigsten signifikanten Bit. Der Exponent von dcm ist 10 und die Mantisse ist 82240550000000000000.

Aktualisierung II: Es ist tatsächlich sehr einfach, nachgestellte Nullen abzuschneiden.

// In dieser Konstante gibt es 28 nachgestellte Nullen -
// keine Decimalzahl darf mehr als 28 nachgestellte Nullen haben
const decimal PräziseEins = 1.000000000000000000000000000000000000000000000000m ;

// decimal.ToString() zeigt nachgestellte Nullen getreu an
Behaupten ((8224055000.000000000m).ToString () == "8224055000.000000000") ;

// Lassen Sie System.Decimal.Divide() die ganze Arbeit tun
Behaupten ((8224055000.000000000m / PräziseEins).ToString () == "8224055000") ;
Behaupten ((8224055000.000010000m / PräziseEins).ToString () == "8224055000.00001") ;

Answer 3

Der Artikel Was jeder Informatiker über die Gleitkommadarstellung wissen sollte wäre ein ausgezeichneter Ausgangspunkt.

Die kurze Antwort ist, dass die Gleitpunkt-Binärarithmetik zwangsläufig eine Näherung ist, und es ist nicht immer die Näherung, die man vermuten würde. Dies geschieht, weil CPUs in Basis 2 arbeiten, während Menschen (normalerweise) in Basis 10 arbeiten. Daraus ergeben sich eine Vielzahl unerwarteter Effekte.

Answer 4

Um dieses Problem deutlicher zu sehen, probieren Sie es in LinqPad aus (oder ersetzen Sie alle .Dump()'s und ändern Sie sie in Console.WriteLine(), wenn Sie möchten).

Es scheint mir logisch inkorrekt zu sein, dass die Genauigkeit des Dezimals zu 3 verschiedenen Doubles führen könnte. Ein Lob an @AntonTykhyy für die /PreciseOne-Idee:

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

Answer 5

Dies ist ein altes Problem und war Gegenstand vieler ähnlicher Fragen auf StackOverflow.

Die vereinfachte Erklärung ist, dass Dezimalzahlen nicht genau im Binärsystem dargestellt werden können.

Dieser Link ist ein Artikel, der das Problem erklären könnte.