Hi!! Möchte gerne mit einem Atmega float-Zahlen berechnen. Wieviel Zahlen hinterm Komma sind möglich? Würden Berechnungen mit +9,9999999....-9,9999999 funktionieren, also mit 7 Stellen hinterm Komma?? Gruß
Das kommt immer darauf an wie schnell du rechnen willst. Im prinzip ist alles möglich dauert dann halt ne Weile
32bit float rechnet auf 6-7 Stellen genau, egal ob die vor oder nach dem Komma sind. Deine Zahlen haben 8 Stellen. Also: Nein. Deine Forderung klingt allerdings nach Festkomma. Und das geht bereits mit 32bit Integer-Rechnung (9 Stellen), ggf. zwischendrin mit 64bit Integers.
Thorsten wrote: > Hi!! > Möchte gerne mit einem Atmega float-Zahlen berechnen. Wieviel Zahlen > hinterm Komma sind möglich? Würden Berechnungen mit > +9,9999999....-9,9999999 funktionieren, also mit 7 Stellen hinterm > Komma?? > Gruß float ist auf einem ATmega mit WinAvr 4 Bytes gross. Normalerweise sagt man, dass das ca. 5, 6 bis 7 signifkante Stellen bringt. Achtung: Signifikante Stellen sind nicht gleich Nachkommastellen. Signifikante Stellen sind alle Stellen beginnend von links. D.h. mit der Zahl 1234.56 hast du bereits 6 sigifikante Stellen aufgebraucht. Die Sache wird aber noch schlimmer: Je mehr du mit dem float rechnest umso mehr Rundungsungenauigkeiten reist du dir auf. Nach ein paar zig float Rechnereien kann es durchaus sein, dass du nur noch 4 bis 5 signifikante Stellen übrig hast. Je mehr du mit einer Variablen rechnest, desto weniger korrekte signifikante Stellen bleiben übrig. Alles was dann nach diesen Stellen rechts noch kommt, ist mehr oder weniger 'gelogen'. Natürlich lässt sich nachvollziehen wie diese 'gelogenen' Stellen zustande kommen. Sie haben aber nur noch wenig mit dem korrekten Ergebnis zu tun.
Der Link zeigt ein paar Zentimeter über die Augen (die eigenen) und soll an den Matheunterricht erinnern.
Gute C-Compiler(Fa.Keil) bieten die Wahl der doppelten Genauigkeit, z.B. 14-stellig.
@Karl heinz Buchegger, es ist nicht so, dass man Duzende Float operationen braucht um von 6 auf 4 Stellen zu kommen. Eine Subtraktion genuegt um von 6 auf 2 stellen zu kommen. Man sagt dann das Problem sein schlecht konditioniert. Das kann natuerlich auch mit double passieren. Will heissen, man ist nicht automatisch mit double auf der sicheren Seite.
Zacc wrote: > @Karl heinz Buchegger, > es ist nicht so, dass man Duzende Float operationen braucht um von 6 auf > 4 Stellen zu kommen. Eine Subtraktion genuegt um von 6 auf 2 stellen zu > kommen. Man sagt dann das Problem sein schlecht konditioniert. :-) Überfall ihn doch nicht gleich mit solchen Horrorszenarien. :-) Aber du hast natürlich recht. Floating point ist eine Wissenschaft für sich. http://docs.sun.com/source/806-3568/ncg_goldberg.html > Das kann > natuerlich auch mit double passieren. Will heissen, man ist nicht > automatisch mit double auf der sicheren Seite. Wie wahr, wie wahr. Nie werde ich mein 3D Roboter Simulationssystem vergessen. Im Test hat alles klaglos funktioniert und für die Demo beim General- direktor der VOEST Alpine haben wir dann mal ein längeres Robot Programm simuliert und natürlich nicht vorab getestet. Die Gesichter wurden immer länger nachdem die Geometrie des Robots nach ein paar zig-tausend Matrix-Operationen immer unförmiger wurde und dann regelrecht explodiert ist. War irgendwie peinlich, denn schliesslich hat die VOEST eine Truppe von 6 Mann über einen Zeitraum von 2 Jahren finanziert und dann sowas.
Ich hab das zum Glück noch nie bei so etwas wichtigem erlebt :) Hab mich nur gewundert, dass in einem physikalischen Modell alles bei kleineren Simulationsschritten nicht genauer, sondern nur kleiner wurde... Wir haben in "Computational Physics" gelernt: -> Das Modell sollte von der Mathematik her keine Energie erzeugen oder vernichten. Und wenn es das durch numerische Fehler doch tut, dann gibt man eben einfach hinter jeden Rechenschritt einen Faktor ins EM-Feld, der die Energie ausgleicht. <- Tja, das tat ich dann auch, nur habe ich durch den Faktor anschließend Energie ins gesamte System gepumpt, während sie nur an einer Stelle durch die Numerik verschwand => auch Mist ;) Nicht umsonst hatten wir ein Semester lang eine Vorlesung "Numerik", das ist echt ne Wissenschaft für sich.
Genau so ist es. Wenn man nicht vor Stabilitaetsproblemen gewarnt wurde hat man die Problematik der numerischen Verarbeitung weder angeschaut, noch debugbar gestaltet. Wenn man schon zu faul ist das Problem genau zu analysieren (ist man sicherlich), sollte man wenigstens ein Debuginterface angedacht haben um Prozesswerte in Echtzeit ueber laengere Zeit anschauen zu koennen.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.