Rechenfehler

**recycle** · 23.11.2005, 00:19

1. Soll das etwa heissen, dass mein ATMEL zu "dumm" ist um diverse Trigonometrische funktionen GENAU auszurechnen?

Ich habe da so grundsätzlich meine Zweifel ob ein schlauer Controller dem binären Zahlensystem mehr oder andere Werte entlocken kann als ein dummer

Mit einer Auflösung von x Bit lassen sich nunmal nur 2^x Werte darstellen, egal wie schlau man sich anstellt.

Huiuiui.... Am Schluss muss ich das noch mit dem PC machen!

Dann hoffe ich mal, dass du dich nicht irgendwann wundern musst, dass der dieselben Rechenfehler einfach nur etwas schneller macht

**izaseba** · 23.11.2005, 00:32

MUL
MULS
MULSU

zumindest steht der beim Mega8 mit dabei.
So ein Datenblatt macht schon was her

Sag ich doch immer wieder

Schon wieder was neues gelernt

Gruß Sebastian

EDIT: Scheint aber nur bei den Megas zu sein.

**Vogon** · 23.11.2005, 00:55

Zitat von surfer

Oder liegt es nur an den Zahlentypen? Kann man da ein anderes Format benutzen?

Wikipedia sagt: http://de.wikipedia.org/wiki/Gleitkommazahl
... bilden die Gleitkommazahlen eine endliche Arithmetik, die vor allem im Hinblick auf numerische Berechnungen mit Computern entwickelt wurde. Dort dienen die Gleitkommazahlen meist als rationale Näherungen für reelle Zahlen.

**linux_80** · 23.11.2005, 01:24

Zitat von izaseba

Scheint aber nur bei den Megas zu sein.

deshalb wird er wohl nicht so oft verwendet.

Müsste man mal probieren, ob der GCC diesen verwendet, und ob man dazu die richtige C-Formel zusammenbringt.

**Klaus_0168** · 23.11.2005, 02:06

Hi all,

Zitat von linux_80

Zitat von izaseba

Scheint aber nur bei den Megas zu sein.

deshalb wird er wohl nicht so oft verwendet.

Müsste man mal probieren, ob der GCC diesen verwendet, und ob man dazu die richtige C-Formel zusammenbringt.

Das Problem mit den Rechenfehlern ist ein systematischer Fehler, der vom verwendeten binären Zahlensystem verursacht wird. Bei einer Umwandlung der Zahl 80 in eine Gleitkommazahl wird die 80 in 0.8 x 10e2 umgewandelt.

Nach IEEE 754 ( http://de.wikipedia.org/wiki/Flie%C3%9Fkommazahl ) wird eine Gleitkommazahl im Singleformat mit 23Bit Mantisse und 8Bit Exponent dargestellt.
Die 0.8 wird in 11001100110011001100110 00000010 umgewandelt (0.79999995231 -> 79.999995231).

Binär gesehen ist 0.8 eine irrationale Zahl. Damit ist der Rechenfehler schon vorprogrammiert ohne Chance korrigiert werden zu können.

Grüße Klaus

**SprinterSB** · 23.11.2005, 10:51

Zitat von surfer

...auch wenn ich die zahl 6537.13700000 in die Variable schreibe, bringt er mir 6537.13711111111111 ????

Ist für solche Zahlen float nicht geeignet?
Habe auch schon folgendes versucht:
sprintf(ausgabe,"%f",r);
aber da gibt es eine warnung wegen double und ein ? wird ausgegeben...

Irgendwelche Tipps?

Bei Verwendung von float hast du bei den angegebenen Werten einen relativen Fehler von ca 1.7*10^{-8} \approx 2^{-25}. Bei 23 Bit Mantisse codiert das niederwertigste Bit für 2^{-24}, also besteht kein Anlass zur Sorge.

avr-gcc unterstützt intern nur float (1 Sign, 23 Mant, 7 Expo). Auch Verwendung von double hilft nicht weiter, da die libgcc2 für avr-gcc nur für SFmode (float) generiert ist. Verwendung von double bringt lediglich Overhead beim Umwandeln und mehr Speicherverbrauch. Falls du höhere Genauigkeit benötigst, dann

Benötigst du überhaupt höhere Genauigkeit? Oder ist es ein ästhetisches Problem?
eigene Bibliothek implementieren: Unterstützung für
-- double (1 Sign, 56 Mant, 11 Expo) oder
-- long double (1 Sign, 64 Mant, 15 Expo)
-- floats nach eingenem Gusto
-- Fixpunkt-Arithmetik nach eigenem Gusto
-- exakte Arithmetik nach eigenem Gusto (ganze Zahlen, rationale Zahlen oder Erweiterungskörper von Q)
eigene Version von avr-gcc generieren, die double bzw long double unterstützt. Die Quellen hast du
Dazu müssen Anpassungen im GCC-Backend für AVR gemacht werden.
entsprechende Bibliothek besorgen (kaufen / in Auftrag geben), CA-System (Computer-Algebra)

sprintf() ist ANSI-C, die %-Modifier müssen zu den Typen passen. Wenn du mit % einen 8-Byte-Wert angibst, lieferst aber nur 4 Bytes ab, dann sei froh, daß du einen Compilezeit-Fehler/Warnung bekommst, und nicht einen Laufzeitfehler wegen Stapel-Korruption!

Zitat von surfer

Soll das etwa heissen, dass mein ATMEL zu "dumm" ist um diverse Trigonometrische funktionen GENAU auszurechnen?

Was bitte meinst du mit *GENAU*???
Ein Rechner ist bestenfalls so schlau wie das Programm, das auf ihm läuft

Wie sieht eine genaue Darstellung von sin(1) deiner Meinung nach aus?

Bist du dir klar über die mathematischen/algorithmischen Grundlagen von dem, was du tun willst?