Genaues Rechnen
-
Hallo
habe einen kleinen Taschenrechner geschrieben. Nun habe ich festgestellt, dass es bei langen Ausdrücken zu einer großen Ungenauigkeit der Ergebnisse kommt.
Zum Beispiel bei solchen:
Pi * (-10) * 155.48 + (-808.72) / 438.09 + lg(30.20) / tan((-130) + |(-893.31) * 573|)Ich führe die Ungenauigkeit auf den Datentyp double zurück. Leider gibt es in C keinen genauen Datentyp der auch Kommawerte aufnehmen kann.
Ich denke ich bin nicht der erste mit diesem Problem. Gibt es kostenlose Open-Source Biblitoheken, die so einen genauen Datentyp bereitstellen?
Vielen Dank für die Hilfe!
-
digitalrechner sind bei rellen zahlen immer etwas ungenau.
aber probiers mal damit: https://gmplib.org/
-
Erstmal Danke für die Antwort. Werde es mir anschauen. WIe macht das denn ein richtiger Taschenrechner? Mit was für Datentypen arbeit der? Oder gibt es eventuell einen ganz anderen Lösungsansatz?
-
hier auch noch:
http://www.xsc.de
-
FlexW schrieb:
Erstmal Danke für die Antwort. Werde es mir anschauen. WIe macht das denn ein richtiger Taschenrechner? Mit was für Datentypen arbeit der? Oder gibt es eventuell einen ganz anderen Lösungsansatz?
echte taschenrechner runden auch, aber wegen der krassen hardwarebeschränkungen nutzen sie andere methoden, z.b. das: https://de.wikipedia.org/wiki/CORDIC
-
Wenn's um absolute Genauigkeit geht, werden in der Regel so was wie PBCDs verwendet.
-
Mit "richtiger" Taschenrechner meinst du so ein Gerät? Die haben mit fixed-point Zahlen gerechnet, oft sogar im Dezimalsystem. Das äußert sich in anderen Arten von Ungenauigkeiten, die du wahrscheinlich nicht bemerkt hast, weil man mit den Dingern eben nur Sachen machen konnte, bei denen das nicht so auffiel.
-
dachschaden schrieb:
Wenn's um absolute Genauigkeit geht, werden in der Regel so was wie PBCDs verwendet.
sowas wie 1/3 oder sqrt(2) kannste auch in bcd nicht exakt darstellen. geht in dezimal einfach nicht. und bcd ist ja ein packformat für dezimalzahlen.
-
Kommt auf die Art der Repräsentation an.
1/3 und sqrt(2) kann man in jedem Zahlencode exakt repräsentieren, der eine exakte Darstellung ganzer Zahlen ermöglicht, nämlich als Nullstellen von (0, 3, -1) ~ 3x-1 bzw (1, 0, -2) ~ x^2-2.
Man repräsentiert die Zahl dann durch die Koeffizienten ihres Minimalpolynom statt durch Ziffernfolgen mit Nachkommaanteil. Arithmetik ist natürlich deutlich verwickelter als in Zifferndarstellung, man rechnet dann in algebraischen Erweiterungen des rationalen Zahlkörpers.
-
zufallswert schrieb:
Kommt auf die Art der Repräsentation an.
1/3 und sqrt(2) kann man in jedem Zahlencode exakt repräsentieren, der eine exakte Darstellung ganzer Zahlen ermöglicht, nämlich als Nullstellen von (0, 3, -1) ~ 3x-1 bzw (1, 0, -2) ~ x^2-2.
Man repräsentiert die Zahl dann durch die Koeffizienten ihres Minimalpolynom statt durch Ziffernfolgen mit Nachkommaanteil. Arithmetik ist natürlich deutlich verwickelter als in Zifferndarstellung, man rechnet dann in algebraischen Erweiterungen des rationalen Zahlkörpers.
du kannst ja gleich ein stellenwertsystem mit basis 3 nehmen. dann wäre 3 eine 10 und 1/3 (0.3333 periode in base-10) exakt eine 0.1, ohne weitere stellen. das ist vielleicht weniger abgefahren als deine methode.
