Richtiges Rechnen mit Floats?
-
Rastafarianism schrieb:
edit: Mit casten der "170.1" funktioniert es, würde aber gerne mal wissen warum das notwendig ist.
Weil 170.1 in C automatisch den Typ double hat. 170.1F wäre float. (float)170.1 wäre dasselbe.
-
Schau dir mal an, wie floats oder doubles funktionieren, dahinter steckt eine Mantisse*2^Exponent-Darstellung.
Problematisch hier:
- 0,1 kann man im Binärsystem schon mal nicht exakt hinschreiben
- Die float-Zahlen sind nicht gleichmäßig über den Wertebereich verteilt, sondern liegen um die 0 dichter als um die 100 (beispielsweise). Wenn Du zwei solche Zahlen addierst, dann werden die Exponenten angepaßt und zwar wird der kleinere groß gemacht, dann werden die Mantissen addiert usw. Offenbar wird beim Ausweiten der Mantisse aus einem 0,1 durch die Verdichtung dann eine Zahl >1. Kann sein, ich hab es jetzt nicht nachgerechnet.
- Vergleicht man, wegen oben angesprochener Ungenauigkeiten, floats nie direkt sondern eher so: abs(x-y)<eps, wobei eps die Genauigkeitsschranke ist, aber der man zwei Zahlen für hinreichend ähnlich hält, so daß man sie gleichsetzen kann. Da allerdings Subtraktion eine schlecht konditionierte Operation ist, sollte man Differenzbildung zwischen Termen verschiedener Größenordnungen eher vermeiden.
Mehr zu float: http://docs.sun.com/source/806-3568/ncg_goldberg.html
-
Daniel E. schrieb:
Schau dir mal an, wie floats oder doubles funktionieren, dahinter steckt eine Mantisse*2^Exponent-Darstellung.
Problematisch hier:
- 0,1 kann man im Binärsystem schon mal nicht exakt hinschreiben
- Die float-Zahlen sind nicht gleichmäßig über den Wertebereich verteilt, sondern liegen um die 0 dichter als um die 100 (beispielsweise). Wenn Du zwei solche Zahlen addierst, dann werden die Exponenten angepaßt und zwar wird der kleinere groß gemacht, dann werden die Mantissen addiert usw. Offenbar wird beim Ausweiten der Mantisse aus einem 0,1 durch die Verdichtung dann eine Zahl >1. Kann sein, ich hab es jetzt nicht nachgerechnet.
- Vergleicht man, wegen oben angesprochener Ungenauigkeiten, floats nie direkt sondern eher so: abs(x-y)<eps, wobei eps die Genauigkeitsschranke ist, aber der man zwei Zahlen für hinreichend ähnlich hält, so daß man sie gleichsetzen kann. Da allerdings Subtraktion eine schlecht konditionierte Operation ist, sollte man Differenzbildung zwischen Termen verschiedener Größenordnungen eher vermeiden.
Mehr zu float: http://docs.sun.com/source/806-3568/ncg_goldberg.html
Super Antwort, danke für die Erklärung!
-
hmmmmmmm schrieb:
du solltest vielleicht erstmal lernen wie ein computer funktioniert bevor du mit programmieren anfängst.
Im Grunde genommen kann es mich einen scheissdreck interessieren wie ein Computer funktioniert, wenns nicht für bestimmte Fälle gebraucht wird.
Im Grunde genommen ist es eine Schwäche des Systems denn eig sollte ich mir erwarten können dass eine Sprache/ein Computer richtig mit Kommazahlen umgehen kann also spar dir solche scheisssprüche.
-
daniel hat schon recht. du trollst hier.
-
muhi schrieb:
hmmmmmmm schrieb:
du solltest vielleicht erstmal lernen wie ein computer funktioniert bevor du mit programmieren anfängst.
Im Grunde genommen kann es mich einen scheissdreck interessieren wie ein Computer funktioniert, wenns nicht für bestimmte Fälle gebraucht wird.
Als Anwender: ja, definitiv. Als Programmier, nein keinesfalls.
Im Grunde genommen ist es eine Schwäche des Systems denn eig sollte ich mir erwarten können dass eine Sprache/ein Computer richtig mit Kommazahlen umgehen kann
Nein, es geht nunmal nicht anders. Wenn du das nicht weisst ist das dein Problem
also spar dir solche scheisssprüche.
Du koenntest auch etwas freundlicher sein.
-
Als Anwender: ja, definitiv. Als Programmier, nein keinesfalls.
Ja das stimmt, was ich gemeint habe ist, dass wenn ich mit floats arbeite ich mich im Grunde genommen nicht unbedingt mit dem binärsystem ausseindandersetzten sollen sowie wenn ich mit ints arbeite.
Nein, es geht nunmal nicht anders
doch doch is mir schon klar dass das im Binärsystem nicht geht, trotzdem ändert das nichts daran dass es eine Schwäche des systems ist, denn ich rede nicht von der Anwendung/Verwendung des Systems sondern vom Gesamstsystem.
Nur weil kein besseres/praktikableres bekannt ist heisst das nicht dass theoretisch kein besseres möglich ist.
Und selbst wenn es keine bessere Lösung gibt ist es trotzdem eine Schwäche.
@rechtegeber: Hab ich in irgendeinerweise bestritten/kritisiert was Daniel E. geschrieben hat? Pass lieber auf was du sagst ich trolle keineswegs, wenn überhaupt dann hatte ich eine rauhe Tonart das wars aba auch schon.
-
muhi schrieb:
@rechtegeber: Hab ich in irgendeinerweise bestritten/kritisiert was Daniel E. geschrieben hat? Pass lieber auf was du sagst ich trolle keineswegs, wenn überhaupt dann hatte ich eine rauhe Tonart das wars aba auch schon.
Zu unrecht übrigens
Die Konditionszahl für die Subtraktion geht gegen unendlich, wenn die Zahlen etwa gleich groß sind, also tritt dann ein Genauigkeitsverlust auf. Trotzdem passiert nicht sehr viel wenn man von einer sehr großen Zahl eine sehr kleine abzieht, aber das hat was mit 2) zu tun.
-
muhi, guck dir mal binary coded decimals an. dann guck dir mal "arbitrary precision math" libraries (wie z.b. GMP) an.
-
muhi schrieb:
Nur weil kein besseres/praktikableres bekannt ist heisst das nicht dass theoretisch kein besseres möglich ist.
0.1 ist binaer ein unedliche nichtperiodische Folge. Wie koennte man das deiner Meinung nach, wenigstens rein theoretisch, loesen?
-