MSP430 double genauigkeit

[Frank B. (rank_b)]

Hallo,
weis jemand auf wieviel Nachkommastellen ich mit double beim 
MSP430FR59XX rechnen kann?
Als Entwicklungsumgebung verwende ich den IAR und habe dort schon double 
auf 64 bit gestellt.
Wenn ich nun z.B. einer  Variable den Wert -6.37853111E+00 zuweise, 
rundet er den Wert auf -6.378531109999999944.
Kann man wirklich nur auf 8 Nachkommastellen genau rechnen?

Danke für eure Hilfe
Frank

[Dirk K. (merciless)]

http://www.iti.fh-flensburg.de/lang/informatik/ieee-format.htm

merciless

[Luther B. (luther-blissett)]

Der Unterschied zwischen den beiden Werten beträgt .000000000000000056, 
d.h. tritt erst in der 17ten Nachkommastelle auf.

"Ergebnis unterschiedet sich ab der X ten Stelle" bedeutet nicht "Auf X 
Nachkommastellen genau" - denn ansonsten wäre ja -6.378531110000000056 
"besser" als -6.378531109999999944.

[Frank B. (rank_b)]

Luther B. schrieb:
> Der Unterschied zwischen den beiden Werten beträgt
> .000000000000000056,
> d.h. tritt erst in der 17ten Nachkommastelle auf.
>
> "Ergebnis unterschiedet sich ab der X ten Stelle" bedeutet nicht "Auf X
> Nachkommastellen genau" - denn ansonsten wäre ja -6.378531110000000056
> "besser" als -6.378531109999999944.

ok, das stimmt natürlich.
Mein Problem ist, dass ich für meine Berechnung eine Polynomfunktion 3. 
Grades benötige und hier mit bis zu 16 Nachkommastellen genau rechnen 
müsste. Das Ergebnis ist dann leider zu ungenau. Gibt es denn irgend 
eine Möglichkeit mit dem MSP430 eine höhere Genauigkeit zu erreichen, 
hat hierzu jemand einen Tip?

[Luther B. (luther-blissett)]

16 Nachkommastellen entsprechen 4nm auf den Erdradius berechnet - stimmt 
die Anforderung oder ist es ein Problem mit der Berechnung selbst, d.h. 
müssen z.B. viele sehr kleine auf wenige, viel größere Zahlen addiert 
werden? Das löst man meistens eher, in dem man die Berechnung umstellt 
und Werte verschiedener Größenordnung separat berechnet.

Falls das nichts hilft, musst du wohl versuchen eine Library für 
höheraufgelöste Zahlentypen auf dem MSP430 zum Laufen zu bringen. 
"decNumber" hat z.B. 128 Bit Dezimalzahlen mit 34 Stellen Genauigkeit:

http://speleotrove.com/decimal/decnumber.html

[Frank B. (rank_b)]

ok danke, werde ich mir anschauen.

vielleich noch mal ein Beispiel meines Problemes.
Ich arbeite mit der Formel f = a*x3 + b*x2 + c*x + d
Als Werte gebe ich z.B. folgende ein:
x hat bei mir den Wert 48916, a=-7,18417038E-16, b=9,29568227E-11, 
c=3,31982246E-04 und d=-6,37853111E+00


Wenn ich jetzt meine Werte einsetze, bekomme ich z.B. beim MSP als 
Ergebnis 10.085. Rechne ich das gleiche mit Excel erhalte ich das 
gewünschte Ergebnis 10.000. Sicher kann ich nun nicht Excel auf einen PC 
mit dem MSP430 vergleichen.

[Luther B. (luther-blissett)]

Das ist ja katastrophal daneben! Ich bekomme unter armhf 
9.999050090800253
raus und das ist einigermaßen am richtigen Ergebnis dran 
(9.99905091456285793184...). Kannst du mal zeigen, wie du das Polynom 
berechnest?

[Theor (Gast)]

Frank B. schrieb:
> ok danke, werde ich mir anschauen.
>
> vielleich noch mal ein Beispiel meines Problemes.
> Ich arbeite mit der Formel f = a*x3 + b*x2 + c*x + d
> Als Werte gebe ich z.B. folgende ein:
> x hat bei mir den Wert 48916, a=-7,18417038E-16, b=9,29568227E-11,
> c=3,31982246E-04 und d=-6,37853111E+00

Du könntest mal ein wenig im Internet recherchieren, denn das Problem 
tritt immer wieder auf.

Die Lösungen laufen daraus hinaus, die Gleichung, - insbesondere die 
Abfolge der Operationen -, und/oder die Darstellung der Zahlen so zu 
ändern (obwohl sie mathematisch identisch bleibt), dass der Fehler 
minimal wird.
Z.B.: Bleibt man bei der IEEE-Darstellung, so berechnet man Summen von 
Zahlen (ungefähr) gleicher Grössenordnung (also ähnlicher Mantisse).
Oder: Stellt man die Zahlen als Brüche von natürlichen Zahlen dar, so 
lassen sich meist Abfolgen der Operationen finden, bei denen die 
Zahlenbereich nicht verlassen werden - also das Ergebnis exakt ist.
Anderer Varianten sind die Zerlegung der Summanden und Faktoren wiederum 
in Summanden und Faktoren, die dann zunächst einzeln verrechnet werden.
Noch andere Varianten laufen auf Näherungsverfahren hinaus.

Das ist ein etwas umfangreicheres Feld und kann hier nicht vollständig 
abgedeckt werden.

Ich empfehle Dir, zunächst mal für jeden der Werte a, b, c, d, x und das 
Ergebnis f zu beschreiben, welchen Wertebereich sie haben und welche 
Auflösung.

[Luther B. (luther-blissett)]

In seinem Fall ist der Fehler aber so nicht zu erklären. Wenn man es 
einfach so direkt macht:

#include <stdio.h>
int main()
{
typedef double real;
real x=48916; 
real a=-7.18417038E-16;
real b=9.29568227E-11;
real c=3.31982246E-04; 
real d=-6.37853111E+00;
real f=a*x*x*x+b*x*x+c*x+d; 
printf("%.15f\n",(double)f);
}

kommt 9.99905 raus. Aufm Raspberry-PI. Da liegt ein anderes Problem vor 
würde ich sagen.

[Theor (Gast)]

Luther B. schrieb:
> In seinem Fall ist der Fehler aber so nicht zu erklären.
> [...]

Nun gut. Du kommst auf ein anderes Ergebnis.
Interessant wäre noch die Bitanzahl von double auf dem jeweiligen 
System.

[M. K. (sylaina)]

Luther B. schrieb:
> In seinem Fall ist der Fehler aber so nicht zu erklären.

Seh ich auch so, sogar auf nem AVR, der nur float kann und double gar 
nicht kennt, kommt da 9.99905 raus was ja wesentlich besser ist als die 
10.085. Da hat man doch woanders nen Bock geschossen...

[Frank B. (rank_b)]

Also erst mal danke für die Hilfe.
Durch die Antwort von luther-blissett ist mir mein Fehler klar geworden. 
Ich hatte die Berechnung in einzelnen Schritten gemacht, also erst a*x3 
und a*x2... einzeln gerechnet und dann die Ergebnisse addiert.
Das ist natürlich nicht so sinnvoll. Ich habe jetzt alles in eine Formel 
gepackt und schon geht es :)

[Detlef _A (Gast)]

Super, es geht, das hört man gern.

32 Bit float ist ungefähr 6 gültige Nachkommastellen, 64 Bit float ca. 
15, siehe auch
Beitrag "64 Bit float Emulator in C, IEEE754 compatibel"

Und man darf sich die Dynamik nicht versauen, also sollten die Zahlen in 
der gleichen Größenordnung liegen. Wenns nicht schon gehen würde würde 
aich als Rechnung auch empfehlen ((a*x+b)*x+c)*x+d

math rulez!
Cheers
Detlef

[Egon D. (Gast)]

Detlef _A schrieb:

> Wenns nicht schon gehen würde würde aich
> als Rechnung auch empfehlen ((a*x+b)*x+c)*x+d

Richtig: Horner-Schema.

[Purzel H. (hacky)]

Computergerecht Rechnen ist eine Vorlesung fuer sich. Von selbst ist da 
gar nichts.

[M. K. (sylaina)]

Name H. schrieb:
> Computergerecht Rechnen ist eine Vorlesung fuer sich. Von selbst ist da
> gar nichts.

Wieso sollte auch, der Computer ist dumm wie Brot, woher sollte der 
Wissen was Mensch will? ;)