<![CDATA[Präzison der Datentypen]]>Hallo, ich schreibe derzeit ein Programm, welches verschiedene numerische Algorithmen durchführt.Mein Problem dabei ist,dass die gängigen Datentypen zur Zahlendarstellung einfach zu ungenau sind. Erfahrungen haben gezeigt,dass man z.B. long double maximal 12 Nachkommastellen glauben kann,danach wirds spekulativ. Hat jemand eine Lösung für mein Problem?Hab nicht so wirklich Bock,extra mir einen neuen Datentypen zu programmieren...

Danke im Vorraus
Sebastian

]]>https://www.c-plusplus.net/forum/topic/156519/präzison-der-datentypenRSS for NodeMon, 10 Aug 2026 03:31:38 GMTThu, 17 Aug 2006 12:14:17 GMT60<![CDATA[Reply to Präzison der Datentypen on Thu, 17 Aug 2006 12:14:17 GMT]]>Hallo, ich schreibe derzeit ein Programm, welches verschiedene numerische Algorithmen durchführt.Mein Problem dabei ist,dass die gängigen Datentypen zur Zahlendarstellung einfach zu ungenau sind. Erfahrungen haben gezeigt,dass man z.B. long double maximal 12 Nachkommastellen glauben kann,danach wirds spekulativ. Hat jemand eine Lösung für mein Problem?Hab nicht so wirklich Bock,extra mir einen neuen Datentypen zu programmieren...

Danke im Vorraus
Sebastian

]]>https://www.c-plusplus.net/forum/post/1119129https://www.c-plusplus.net/forum/post/1119129Thu, 17 Aug 2006 12:14:17 GMT<![CDATA[Reply to Präzison der Datentypen on Thu, 17 Aug 2006 12:18:04 GMT]]>Hallo

siehe zum Beispiel hier.

bis bald
akari

]]>https://www.c-plusplus.net/forum/post/1119133https://www.c-plusplus.net/forum/post/1119133Thu, 17 Aug 2006 12:18:04 GMT<![CDATA[Reply to Präzison der Datentypen on Thu, 17 Aug 2006 12:24:54 GMT]]>Hallo,

Genauer bekommst du es mit den eingebauten Typen nicht. Versuch lieber damit auszukommen. Du könntest natürlich auch spezielle Datentypen mit höherer Genauigkeit durch Verwendung spezielle Bibliotheken bekommen. Da dürfte aber die Performance stark einbrechen. Wenn es dir darauf nicht ankommt nimm halt so eine Bibliothek.
Wenn du mit dem BCB arbeitest kann ich dir NTL empfehlen. Die ist zwar langsamer als GMP, dafür läuft sie aber auch mit dem BCB.
[edit]
@akari
Hast du GMP mal mit dem BCB zum Laufen bekommen?
[edit]

]]>https://www.c-plusplus.net/forum/post/1119136https://www.c-plusplus.net/forum/post/1119136Thu, 17 Aug 2006 12:24:54 GMT<![CDATA[Reply to Präzison der Datentypen on Thu, 17 Aug 2006 13:22:21 GMT]]>Hallo

nein, habe es auf dem Builder nie probiert, nur vor einiger Zeit auf dem GNU-Compiler.

bis bald
akari

]]>https://www.c-plusplus.net/forum/post/1119196https://www.c-plusplus.net/forum/post/1119196Thu, 17 Aug 2006 13:22:21 GMT<![CDATA[Reply to Präzison der Datentypen on Thu, 17 Aug 2006 13:36:38 GMT]]>z.B. fortgesetzte Teilung mit 2 und anschliessende Bestimmung der Reste
(Nachkommaanteil vorher durch durch Multiplikation egalisieren.)

]]>https://www.c-plusplus.net/forum/post/1119213https://www.c-plusplus.net/forum/post/1119213Thu, 17 Aug 2006 13:36:38 GMT<![CDATA[Reply to Präzison der Datentypen on Thu, 17 Aug 2006 13:41:04 GMT]]>Ok, danke für die Tips, werd mal gucken was mich das Ganze an Performance kostet.
Würde natürlich alles darum geben,wenn ich mit long double klar kommen würde, aber es geht teilweise einfach nicht. Interessant ist, dass ich festgestellt habe,dass die Fehler beim Addieren zu vernachlässigen sind,während beim Subtrahieren erschreckende Genauigkeitseinbußen zu entdecken sind. Weiß jemand wie das zusammenhängt? Intern wird doch alles addiert(halt mit verschiedenen Vorzeichen),dachte ich... Egal,wenn jemanden noch irgendwelche Hinweise einfallen,wie man solche Rundungsfehler durch geschickte Programmierung minimieren kann, wäre ich sehr dankbar.

Gruss an Alle
Sebastian

]]>https://www.c-plusplus.net/forum/post/1119219https://www.c-plusplus.net/forum/post/1119219Thu, 17 Aug 2006 13:41:04 GMT<![CDATA[Reply to Präzison der Datentypen on Thu, 17 Aug 2006 13:51:59 GMT]]>Was ist für dich eine erschreckende Genauigkeitseinbuße?
Was für Algorithmen erfordern derartig hohe Genauigkeiten?
Meines Wissens nach werden diese hohen Genauigkeiten hauptsächlich in der Zahlentheorie (Cryptografie) verwendet. Bei numerischen Simulationen genügt meistens die vorhandenen Genauigkeit. Geschwindigkeit ist hier sowieso meistens wichtiger.

]]>https://www.c-plusplus.net/forum/post/1119227https://www.c-plusplus.net/forum/post/1119227Thu, 17 Aug 2006 13:51:59 GMT<![CDATA[Reply to Präzison der Datentypen on Thu, 17 Aug 2006 14:13:25 GMT]]>Du meinst sicherlich Auslöschung.
Um das zu vermeiden sollten die Beträge der Zahlen etwa in der gleichen Größenordnung liegen wie die gewünschte Genauigkeit.

]]>https://www.c-plusplus.net/forum/post/1119246https://www.c-plusplus.net/forum/post/1119246Thu, 17 Aug 2006 14:13:25 GMT<![CDATA[Reply to Präzison der Datentypen on Fri, 18 Aug 2006 09:23:08 GMT]]>@Braunstein

Ich schreibe ein Programm,dass die Schwingungen von Feder-Masse-Systemen simuliert.
Dabei wird über einen Zeitraum T zu jedem Zeitpunkt t+h (wobei h die Schrittweite ist) eine Differentialgleichung gebildet und nach dem Runge-Kutta Algorithmus numerisch gelöst.Dabei wird bei jedem Schritt durch eine Formel eine Fehlerabschätzung vollzogen und eventuell die Schrittweite h verdoppelt oder halbiert.Nerven tut mich dieser numerische Fehler halt bei der Fehlerabschätzung sowie aufgrund der Tatsache,dass ja mit jedem Schritt sich der Rundungsfehler fortpflanzt. Bei teilweise bis zu 20000 Schritten fällt es halt irgendwann ins Gewicht.
Ach ja, und Rechenzeit spielt eine gehörige Rolle dabei...

Gruß Sebastian

]]>https://www.c-plusplus.net/forum/post/1119666https://www.c-plusplus.net/forum/post/1119666Fri, 18 Aug 2006 09:23:08 GMT<![CDATA[Reply to Präzison der Datentypen on Fri, 18 Aug 2006 09:43:01 GMT]]>Bei derartigen Simulationen brauchst du solche Genauigkeiten nicht. Das Problem der Auslöschung besteht zwar, lässt sich aber meistens durch geschickte Umformung der Gleichungen lösen. Du kannst ja mal überprüfen wie groß der Fehelr wird und was das in realen Fällen ausmacht. Meist wird ein solcher Fehler überschätzt.

]]>https://www.c-plusplus.net/forum/post/1119687https://www.c-plusplus.net/forum/post/1119687Fri, 18 Aug 2006 09:43:01 GMT