Beim Umgang mit Brüchen in der Programmierung ist große Vorsicht geboten. Ich bin sicher, einige von Ihnen haben in diesem Frühjahr damit begonnen, Arbeitsprogramme zu schreiben. Um die Aufmerksamkeit auf sich zu ziehen, werde ich dies auf leicht verständliche Weise mit Gründen erläutern. Es ist allgemein bekannt für diejenigen, die es wissen, aber es ist eine große Gefahr für diejenigen, die es nicht wissen. Wenn jemand zu wissen scheint, wie gefährlich es ist, lassen Sie es mich bitte wissen.
Die Quintessenz ist, dass Computer Zahlen in Binärform verarbeiten, während die reale Welt meistens in Dezimalzahlen berechnet. Es ist gefährlich, den Bruch zu berechnen, während der Radix konvertiert wird.
Warum ist es also gefährlich, beim Konvertieren von Radix mit Brüchen umzugehen? Lassen Sie uns zunächst über ternäre und dezimale Zahlen sprechen.
Die ternäre Zahl 0.1 ist eine Zahl, die bei dreimaliger Addition zu 1 wird. 0,1 + 0,1 = 0,2. 0,2 + 0,1 wird auf 1 übertragen. In Brüchen ausgedrückt ist es 1/3. Was ist also 1/3 in Dezimalzahl? Eine Zahl, die bei dreimaligem Hinzufügen zu 1 wird. das ist 0,3333333333333333333 ・ ・ ・ ・ ・ ・ Es ist ein unendlicher Bruchteil. 0,1, das ein endlicher Bruchteil in ternären Zahlen war, wird ein unendlicher Bruchteil in Dezimalzahlen. Und weil Computerressourcen endlich sind, können sie nicht unendlich viele Brüche enthalten. Der 64-Bit-Gleitkommatyp kann bis zu 16 Stellen enthalten. Wenn ein Computer einen Bruchteil hat, kann er daher einen ungefähren Wert haben. Wenn der Computer Zahlen in Dezimalzahl hätte, würde ein Drittel als 0,333333333333333333 beibehalten. Das ist gefährlich.
Ich habe am Beispiel von 1/3 beschrieben, dass der Anteil, der ausgedrückt werden kann, je nach Radix unterschiedlich ist. Was ist also eine Dezimalzahl, die in Binärform zu einem unendlichen Bruch wird? Beispielsweise kann die Dezimalzahl 0,2 nicht binär dargestellt werden. 0 .001100110011 ... Und wird ein unendlicher Bruchteil. PDF der mathemaTeX-Seite von tmt! erklärt ausführlich, warum daraus 0.001100110011 wird .... Daher kann die Dezimalzahl 0,2 von einem Computer nicht genau gehalten werden (eine normale Gleitkommavariable). Es wird einen ungefähren Wert haben.
Dies verursacht Probleme beim Umgang mit Brüchen in der Programmierung.
const num = 0.2 + 0.1;
console.log("0.2 + 0.1 = " + num);
> 0.2 + 0.1 = 0.30000000000000004
Es sollte 0,3 sein, aber es hat sich um 0,00000000000000004 erhöht. Das ist das Problem. Wenn Sie einen Bruchteil in einer Umlageberechnung verwenden, erhalten Sie möglicherweise eine fehlerhafte Rechnung. Das ist schrecklich.
Anstatt Brüche mit regulären Variablen zu behandeln, berechnen wir die Bibliothek. Verwenden Sie für JavaScript BigDecimal.js oder bignumber.js. .. Berechnen wir in Java mit der BigDecimal-Klasse der Standardbibliothek. In anderen Sprachen gibt es Bibliotheken mit Namen wie "Big Decimal" und "decimal".
Wenn Sie den Bruch genau berechnen möchten, berechnen wir ihn über die Bibliothek. Wenn es jedoch nicht erforderlich ist, so genau zu berechnen, wie z. B. die Berechnung der Zeichnungshöhe, ist es möglicherweise besser, mit einfachen Variablen anstelle der Bibliothek zu berechnen. Dies liegt daran, dass die Bibliothek möglicherweise die Geschwindigkeit opfert, um genau zu berechnen.
das ist alles.
Recommended Posts