MEGA 128 verrechnet sich

sorry, glaskugel ist gerad in der reparatur...

wie wärs mit dem code?

So langsam ödet einen dieser dämliche, in diesem Forum immer
wiederkehrende Spruch mit der Glaskugel an...

Mein Auto fährt nicht mit diesel. Mein anderes auto fährt damit
problemlos.
Wo liegt der Fehler ?
kann das am vergaser liegen ?

Die Teile sind einfach nicht gleich. Und man sollte den code vielleicht
mal ein wenig anpassen.

@Andreas
mich nervts viel mehr, dass viele immer mit Problemen kommen, absolut
keine Angaben geben und sagen irgendwer soll sie mal lösen. Bei dem
Fehler kann es wohl 100k lösungen geben.

@Andreas:

Die Antwort mit der Glaskugel ist nicht viel zu freundlich!

Sollen hier jeder hellsehen können, was sein Problem ist?

Übrigens: Ich möchte  Klaus besuchen. Kannst Du mir bitte den Weg
sagen?

Wer ist eigentlich Paul?

Ich glaube nicht, daß es am Mega-128 selbst liegt. Ich gehe mal davon
aus, daß Du der falschen Annahme, C-Code sei ohne weiteres portierbar,
aufgesessen bist.
Ein Grund könnte der Unterschied im RAM sein, 80537-Systeme haben
grundsätzlich externen RAM und da wird dann meistens nicht gespart, der
Mega-128 hat zumeist nur den internen zur Verfügung.
Gib uns wenigstens etwas mehr Infos, sonst stochert man nur irgendwo in
einem dunklen Loch herum...

"Eigentlich Paul" ist ein Hund, den ich mal ein dreiviertel Jahr in
Pflege hatte. Es ist ein reinrassiger "Dalmatdoofcollie": Mutter
Dalmatiner, Vater Collie, Hund doof (aber sehr lieb).

...

das mit dem externen Speicher ist allgemein wohl richtig, aber ich habe
es damals so optimiert, das ich ohne externen Speicher ausgekommen bin,
soll heißen, es ist physikalisch kein externen Speicher angeschlossen.
Ich kan mir nicht vorstellen, dass es Sinn machen soll hier 3 A4-Seiten
Formeln zu posten.
Nehemn wir statt dessen die Eckdaten.
Es kommen 8 double Vars zum Einsatz die über x, x^2, x^3, x^4, sin(x),
cos(x), tan(x) und arctan(x) verknotet werden.
Ich vermute ein Basisproblem, entweder mit der Mathematik-Bibliothek,
oder im Makefile. Ich hatte da gerade gestern ein Schlüsselerlebnis mit
spintf.

Hallo tex,

ich glaube nicht, dass es mit der Library zu tun hat, ich denke es
liegt eher am Makefile. Library wäre ja zu einfach... obwohl, bei
arctan bin ich mir nicht ganz sicher, schau lieber mal in die Sourcen.

Ich hatte so was ähnliches wie ein Schlüsselerlebnis schon mal bei
einem Pic, da lag es auch am Makefile...

HTH

nun, den Verdacht hege ich ja auch, aber die Frage die sich stellt ist
WAS GENAU IM MAKEFILE MUSS ICH ÄNDERN?
Gestern habe ich ein kleines Doppelkreuz entfernt und schon klappte es
mit dem sprintf.
Ein weiteres, in der Euphorie gelöschtes Doppelkreuz führte dazu dass
garnix mehr ging.
Kann ich irgendwie erkennen, wann es mit meinem RAM zu Ende geht?

@Hannes: Klasse!

na dann, für alle Glaskugelspäher eine Ausschnitt aus dem Formelwald.
allein mir fehl der Glaube, daß das helfen kann.
Den Autovergleich kann ich nicht ganz nachvollziehen. Hier steht ja nun
bei Leibe nichts besonders Exotisches drin und wenn es der 15 Jahre alte
C-Compiler übersetzen und der noch ältere 8Bit-µC ausführen kann, dann
sollte es mit dem neuen Compiler und µC doch auch funktionieren oder
wenigstens eine Fehlermeldung vom Compiler kommen, wenn er was nicht
übersetzten kann.
Ich glaube aber nicht, dass es am Compiler oder am Code liegt. Ich
denke es liegt an der Maht.h oder am Makefile.

void calculation(void)
    {
    float pi = 3.14159265359;
    double Beta,Gamma,Delta,Omega,Epsilon,Alpha;


    if (Zeta < 3)
       {
       Zeta += 12;
       Eta -= 1;
       }

    Gamma = (Theta + Iota * 1/342.0 + kappa * 1/7600.0);


    Beta =  (signed long)( 241.76  * ( Eta + 4716.0 ))
    + (signed long)( 41.6201 * ( Zeta + 1.0  ))
    + Lambda + ( Gamma/29 ) -1537.5;

    Gamma = ( Beta - 2543545.0 ) / 45425.0;

    Delta =  (280.46645 + 35380.76983 * Gamma + 0.0003032 * (Gamma *
Gamma))
     - (signed long)((280.46645 + 35380.76983 * Gamma + 0.0003032 *
(Gamma * Gamma)) / 360) * 360;

    Omega =  397.5291 + 38959.0503 * Gamma -0.0021559  Gamma  Gamma
-0.00000048 *Gamma *Gamma *Gamma
  - (signed long)((357.5291 + 35999.0503 * Gamma -0.0001559
   Gamma  Gamma -0.00000048 *Gamma *Gamma *Gamma) / 360) * 360;

    if (Omega < 0) Omega=Omega+360;

    Epsilon = (1.9146-0.004817 * Gamma - 0.000014  Gamma  Gamma)
  * sin (Omega * pi / 180) + (0.019993 - 0.001101 * Gamma)
  * sin (2  Omega  pi / 180) +0.00629 * sin(3  Omega  pi / 180);

     Omega = (Epsilon + Delta)-(signed long)((Epsilon +
Delta)/360.0)*360.0;


     Omega= Omega - 0.00569 - 0.00478 * sin((125.04 - 1934.136 * Gamma)
/ 180.0 * pi);


    Delta= 23.43929111111 - 0.01300416666666 * Gamma
       -0.00000016388888  Gamma  Gamma + 0.00000050361111 * ( Gamma *
Gamma * Gamma);

    Alpha = atan((cos((Delta + 0.00256 * cos((125.04 - 1934.136 *
Gamma)/180.0*pi))* pi / 180.0 )*sin(Omega * pi / 180.0))
                      /cos(Omega * pi / 180.0)) * 180.0 / pi - 180.0;

   if (Omega < 270 && Omega > 90)  Alpha = Alpha-23;  else Alpha =
Alpha + 230;

    Epsilon = asin(   sin ((  Delta+0.00256*cos((125.04 - 1934.136 *
Gamma)/180.0 *pi)  )* pi / 180.0)
        * sin ( Omega / 180.0 * pi )  )* 180.0 / pi;

    Delta = (280.46061837 + 370.98564736629 * (Beta-2451545)
  +0.005387933  Gamma  Gamma -(( Gamma  Gamma  Gamma) / 37817700))
        -(signed long)((280.46061837 + 370.98564736629 *
(Beta-2451545)
  +0.000387933  Gamma  Gamma -(( Gamma  Gamma  Gamma) /
37810000))/360.0)*360.0;

    Omega = (Delta - Psi - Alpha+3600.0) - (signed long)((Delta - Psi -
Alpha+3600.0) / 360.0) * 360.0;




    Sigma = asin(    sin ( Tau / 180 * pi )
       * sin ( Epsilon / 180 * pi )
       + cos ( Tau / 180 * pi )
       * cos ( Epsilon / 180 * pi )
       * cos ( Omega / 180 * pi )          ) * 180 / pi;



    Omikron = atan(  sin(Omega * pi / 180)
        / (   cos ( Omega * pi / 180)
      * sin ( Tau * pi / 180)
      - tan ( Epsilon * pi / 180)
      * cos ( Tau * pi / 180)
           )                           ) * 180 / pi;

    if (Omega < 360 && Omega > 180 && Omikron > 0 )
   Omikron = Omikron - 180;
    else
   if (Omega > 0 && Omega < 180 && Omikron < 0)
   Omikron = Omikron + 180;


    }

Wie ich das so sehe, kann man die Rechnerei doch um einiges
vereinfachen. Wieviel gültige Stellen brauchst Du ? 3 oder 4 ?

Hier noch der Code:

void calculation(void)
{
long n = 1000000;
  while(n--);
}

@Michael: Das war nicht unbedingt nötig. Trotzdem hab ich gelacht. :-)

Nun zum eigentlichen Problem: Der Formel-Wald hat seinen Namen
verdient. :-)  Was Du mal testen solltest sind die einzelnen
Funktionen. Du könntest Werte berechnen und sie am PC mal vergleichen.
Sollte sich auch automatisieren lassen. z.B.  so:

double x, y;
for(x = -pi; x <= pi; x+=0.0001) {
    y = atan(x);
    printf("%f\n", y);
}

Auf dem PC dann ein Programm schreiben, welches von der seriellen
Schnittstelle die Werte übernimmt und dann mit den am PC berechneten
Werten vergleicht.

Dein Problem hört sich aber eher nach irgendeiner Ungenauigkeit durch
Deine Formeln an. Man kann Genauigkeit durch ungeschickte Aufstellung
der Formeln verlieren.

Mich würde aber mal interessieren, wie lange die Berechnung dauert und
wieviel Code Dein Compiler daraus generiert. Und was machst Du da
überhaupt?

ciao, Stefan.

Na ja! es geht nicht um 3 oder 4 Stellen. Ein paar von den Zahlen werden
erst in der 15 Nachkommastelle interessant, darum das Zahlenformat.
@Michael
Ein Stundenlohn von 50€ ist vermessen, darüber magst Du beleidigt sein,
und kannst Dich an meiner Mailadresse ausheulen, aber es tut nicht Not,
dass Du dieses Forum damit belastest.

ich quäle mich sicher nicht durch dieses Ungetüm, aber ich glaube, dass
an "double" liegt. Die Compiler, die kenne, akzeptieren das zwar,
rechnen aber dennoch nur mit float, also 32bit statt 64bit.

das wäre fatal! Ist das sicher? Gibt es einen Weg, das zu umgehen?
Teure Compiler vieleicht?

Wenn Du hohe Genauigkeit brauchst, dann solltest Du nicht die Math-Lib
verwenden. Schau mal nach GMP, wenn ich auch bezweifle, daß es das für
den AVR gibt.

Warum brauchst Du überhaupt so eine hohe Präzision in einem AVR? Das
ist doch eher eine Aufgabe für eine FPU.

ciao, Stefan.

Es ist nicht unbedingt die Präzision, es ist nur die Natur der
Berechnung, dass es Zahlen gibt, die sich erst ab der 15.
Nachkommastelle verändern, dafür aber fatale Auswirkungen auf das ganze
System haben.
GMP werd ich mal suchen. Wenn es das nicht für den AVR gibt, kennst Du
einen Compiler für den es dass gibt?

Das Problem bei solchen Berechnungen ist, daß der AVR die denkbar
schlechteste Platform dafür ist. Er ist langsam, hat "nur" 8-bit und
wenig Speicher. Warum sollte jemand auf die Idee kommen und darauf
solche hochpräsisen Sachen drauf laufen lassen. Also mir erschließt
sich auf den ersten Blick keine Anwendung, die eine solche Genauigkeit
braucht. Kannst Du mir eine nennen? :-)

Daß double nicht mit 64-bit ausprogrammiert ist auf dem AVR ist keine
Sache des Compiler. Das ist eine Sache der AVR-Libc. Du könntest ja die
Routinen aus der AVR-Libc nehmen und entsprechend aufbohren. Daß sich
jemand hingesetzt hat und GMP auf den AVR portiert ist eher
unwahrscheinlich.

ciao, Stefan.

Hi

selbst mit double-Zahlen ist eine Berechnung die sich erst in der
15-Dezimalstelle unterscheidet sehr kritisch. Es bleiben dann nur noch
1,5 Dezimalstellen übrig die sich ändern können. Das ist nicht wirklich
viel.

Matthias

@Steffan.
Das Idee und das Ergebnis ungewöhnlich sind, weiß ich wohl.
Erstaunlicher Weise braucht der 80537 aber nur ca 8 - 10 sec. um das
Ergebnis der Berechnug zu liefern (bei 8Mhz). (Ein paar Hürden gibt es
natürlich schon zu umschiffen).
Anwendungen gibt es eine ganze Reihe dafür.

Was mich wundert ist, dass ich mit dem 537 keine Probleme hatte aber
der  AVR nicht mitspielt. Bevor ich nun den Formelsalat
auseinanderpflücke und die Hürde manuell umschiffe, würde ich nur gerne
wissen ob ein ödes Makefile - Flag oder eine andere Math.h Abhilfe
schaffen.

JETZT SAG DOCH ENDLICH, WOZU DER FORMELWALD DA IST!!!!!!

Ich bin doch so neugierig. :-)

@Peter: Ich wollte Mikrocontroller nicht verdammen. Nur ist es schon
ungewöhnlich, daß jemand solche Routinen in einen Mikrocontroller
packt. Das wollte ich als Grund aufführen, warum keiner die doubles
ausprogrammiert hat und GMP nicht für den AVR existiert. Von mir aus
kann man auch meherere AVRs als Rechencluster benutzen. Wenn es denn
Spaß macht....

Zurück zum Problem: Daß die Berechnung auf einem 8051 funktioniert
heißt noch lange nicht, daß sie auch auf dem AVR korrekte Ergebnisse
liefert. Ich habe ja schon geschrieben, daß durch unglückliche
Verkettung der Befehle große Ungenauigkeiten entstehen können. Und wer
weiß, ob die einzelnen Routinen überhaupt für solche Genauigkeiten
ausreichend sind. Das müßte man aber durch "zurückrechnen" erkennen
können.

ciao, Stefan.

Hab jetzt nochmal in den Source der AVR-Libc geschaut. Dort ist wirklich
alles nur Float. In den Kommentaren steht aber auch was zur Genauigkeit
der einzelnen Funktionen drin. Ein Blick in den Source-Code kann also
hilfreich sein.

ciao, Stefan-

Hallo,

mich würd auch mal interessieren, wozu der Formelwald da ist, wenn er
Zahlen rechnet, die erst bei 10^-15 nen Unterschied aufweisen.

Zum Problem selber: Kann's vielleicht sein, dass der Compiler durch
irgendwelche Code-Optimierungen die Hälfte vom Code weglässt? Ein
ähnliches Problem hatte ich mal ... Abhilfe: Entweder Optimierungen
komplett abschalten oder die betreffenden Variablen mit "volatile"
deklarieren (bewirkt, das der Compiler Lesezugriffe auch tatsächlich
ausführt und nicht einwach "wegoptimiert")

MFG

Hannes

Um die Diskusion um den Formelwald mal zu stoppen, ich sag nicht, was
ich damit ausrechne. Ich will es doch noch verkaufen. ;-) Aber es ist
auch nicht in 3 Sätzen beschrieben. Ich habe ein Jahr gesessen und
diesen Zauber zusammengeschrieben, bis es endlich passte.
Das mit der Optimierung und der Volatile werde ich mal ausprobieren.
Das die Funktionen auf Float-Größe abgefressen werden sagt mir ja
garnicht zu.

<Ein Blick in den Source-Code kann also hilfreich sein.>
Ich wollt, ich wüßte was Du damit meinst und könnte es tun.

Wenn man da reinschauen kann, dann kann man es doch auch ganz bestimmt
manipulieren, zumindest für die Funktionen, die ich brauche, oder?

Was spricht eigentlich dagegen, den Code mal in einem Debugger laufen zu
lassen und ihm dabei auf die Finger zu schauen?
Im AVR Studio ist immerhin ein für diesen Zweck gedachter Simulator
enthalten.

mangelndes Verständnis für die Materie, keine Arbeitsanleitung, keine
Ahnung wie das vor sich geht, ...

Hallo tex,

hat das Ding etwas mit unserem Projekt zu tun ??

ha!
 Um das Problem noch um eine Dimension zu erweitern eine kleine
Geschichte aus der mega8515-uart-Abteilung:

Hab zur Sicherung einer RS485-Übertragung eine xor-verknüpfung eines 4
Byte großen Datenframes gemacht. Hat aber nicht sauber funktioniert.
Nach 2 Tagen !!! hab ich das Problem gefunden:
2 Exemplare von mega8515 die bei einer xor-Operation das 4. Bit
manchmal falsch berechnen, wobei das Auftreten von der Konstellation
der anderen 7 Bits abhängig war.

Das ist aber ganz bestimmt nicht das Problem von tex. Wenn Du Dir seine
Formeln anschaust, dann wirst Du vielleicht erkennen woran es liegt.

@tex: Laut Deiner Aussage ist die Formel kritisch und abhängig bis zur
15ten Stelle nach dem Komma. Mir hat das ganze keine Ruhe gelassen und
ich habe mal mit floats, doubles und der Genauigkeit der beiden
rumgespielt. Folgendes Programm:

int main(void)
{
  double eins = 1.0;
  double eps  = 1.0;

  int iter;

  for(i = 0; i < 100; i++) {
    double a = eins + eps;
    if(a == eins) {
      printf("eps is %g (iter is %d)\n", eps, i);
      break;
    }
    eps /= 2.0;
  }
}

Das verringert den Wert von eps so lange, bis sich bei einer Addition
von 1 mit eps keine Änderung ergibt. eps kann man also als Grenze für
die Genauigkeit bei der Arbeit mit doubles sehen.

Das Programm habe ich mal auf einem x86 kompiliert mit verschiedenen
Optimierungen:

ohne:  eps is 1.11022e-16 (iter is 53)
-O3:   eps is 5.42101e-20 (iter is 64)

Man sieht sehr deutlich, daß die Genauigkeit der Berechnungen von der
Optimierung abhängt. Du kann also in Deinem Makefile mal mit den
Optimierungen spielen, vielleicht bringt das ja was.

Davon mal ganz abgesehen bezweifle ich die Genauigkeit der von Dir
angestellten Berechnungen. Ich weiß leider immer noch nicht, was Du da
genau berechnest (SAG ES ENDLICH!!! :-) ). Aber wenn es wirklich so
eine hypersensible Formel ist, dann solltest Du Dich nochmal mit dem
Thema Genauigkeit beschäftigen. Kann man die Formel vielleicht
vereinfachen? Ich würde da schon potential sehen auf den ersten Blick.

Auch vom Quellcode her würde ich noch verbesserungsbedarf sehen. Z.b.
all diese Konstanten würde ich mit defines festlegen, damit sie bei
Bedarf geändert werden können.

ciao, Stefan.

Hallo Stefan,
erst mal ganz vielen Dank für die Hilfe ich werd es gleich
ausprobieren. Die Konstanten dürfen auf gar keinen Fall geändert
werden. Ich habe sie nicht als Defines gespeichert, weil ich im 537
keinen Platz im Speicher hatte also musste alles sofort verworfen
werden, wenn es nicht mehr gebraucht wurde. Ich fürchte, dass ich mit
dem mega das gleiche Problem bekomme. Ich bin aber für alle
Verbesserungs- und Optimierungsvorschläge dankbar. Immer los. Ich habe
Monate an der Vereinfachung gesessen.

Also Moment mal:

Einen Define den Du nicht brauchst, der wird auch nicht im Code
umgesetzt. Du könntest statt dem folgenden:

z = 587.0 * 0.34544 * x;

viel besser schreiben:

#define alpha 587.0
#define beta  0.34544
z = alpha  beta  x;

Das kommt aufs gleiche raus.

ciao, Stefan.

Hi

x86 darfst du zur Bestimmung von floating-Point Genauigkeit nicht
herenziehen. Deren FPU arbeitet mit einem Format von 80Bit Breite (IEEE
754 Extended).

Aber deine Werte passen ganz ordentlich.

Double hat eine Mantisse von 52 Bit was einer Dezimalzahl von
4.503.599.627.370.496 entspricht. Also etwa 15,5 darstellbare
Dezimalstellen. Extended arbeitet mit 64 Bit Mantisse und kann damit
etwa 19,1 Dezimalstellen darstellen. Bei -O3 beläßt der Compiler die
Ergebnisse in den FPU-Registern und damit behalten diese ihre höhere
Genauigkeit. Bei reinen Softwareimplementierungen wie beim AVR spielt
das keine Rolle.

Matthias

@Stefan
Das sie in code umgestezt wird stört mich weiter nicht, der
Programmspeicher ist ja groß genug, wo sie nicht hin darf ist der RAM,
weil dort arger Platzmangel herscht. die Sache mit dem Define könnte ic
mir nett vorstellen, aber wo landet meine Zahl dann? im Flash oder im
RAM?

@ alle
Nach dem ich das Forum heute längere Zeit nicht erreichen konnte stehen
plötzlich viel mehr Beiträge drin, als zuvor, z.b. Peter... Also
Entschuldige ich mich mal pauschal bei allen, die ich scheinbar
ignoriert habe ;-)

Im Flash. Im RAM landet es nur, wenn Du das als Variable definierst.
Schau Dir nochmal an, was der Preprozessor von C macht, dann entdeckst
Du den Unterschied.

@Matthias: Das kann schon sein mit den FPU Registern. So genau wollte
ich das dann doch nicht wissen.

ciao, Stefan.

@Peter
define statt lang verketteter Konstanten ist ok, hab ich verstanden, ob
der besseren Lesbarkeit.
Aber unter dem Strich müssen die Konstanten dann doch wenigstens in
Flash landen, damit der µC damit rechnen kann? Im Flash dürfen sie
rummodern, da is (noch) genug Platz, nur im Ram wird erfahrungsgemäß
eng.

Ich habe mal versucht den mega mit diesem kleinen Programm zu testen

while( me != save)
    {
  save = me;
  me = me / 10.0;
        count++;

  display_cursor(1,1);
  sprintf(displaystring,"%1.14f", (double)me);
        display_string(displaystring);

  display_cursor(2,1);
  itoa(count,displaystring,10);
        display_string(displaystring);

  for (pause=1; pause < 300000 ;pause++ ) asm("NOP");
}
Wenn ich jetzt keinen elementaren Fehler gemacht habe, ist das Ergebis
folgendes:
1. Der Mega128 rechnet 38 Stellen aus, egal ob float oder double
eingestellt ist
2. Der Mega verrechne sich und zwar ganz gewaltig. bei der dritten
Division ist das Ergebnis 0.000999999999504
Hat jemand ein Erklärung oder eine Lösung auf Lager?

Bei dieser Abwandlung endet das Programm nach der 10. Division?!

me = (me / 10.0)+1;

Hallo,

Das Problem mit der 3. Division liegt allein darin, das der dezimale
Bruch 0,1 nicht Binär dargestellt werden kann. Dafür kann weder der
Controller was, noch der Erfinder der Fließkommazahlen für Computer. D.
h. es ist eine "natürliche" Ungenauigkeit der Zahlendarstellungsweise.
Willst du solche Systemfehler umgehen, müsstest du entweder mit 2er
Potenzen rechnen (also 2 oder 4 oder 8 als Basis) oder aber du müsstest
deinen Code in BCD (Binary Coded Decimal) umwurschteln. Beides sehr
umständlich, vor allem die BCD-Version. Und mit den Potenzen is des so
ne Sache ... wie gesagt lassen sich manche (dezimal dagestellte) Zahlen
nicht in 2er Potenzen darstellen.

MFG

Hannes

verstehe.
Dann manifestiert sich dieses Problem aber immer nur mit einem durchaus
konstanten Fehler, und sollte den 80537 mit der gleichen Ungenauigkeit
belastet haben?

So könnt ich mir das auch vorstellen. Vielleicht liegt es an der
Umsetzung des sprintf in den unterschiedlichen Bibliotheken. In der
alten Bibliothek hat es das Ergebnis "genauer" gerundet und die neue
Version rundet eben "ungenauer", sodass es jetzt auffällt, wenn nach
3 Stellen hinter dem Komma eine Ungenauigkeit auftritt. (Anm.: Ich hab
das Programm mal auf dem PC laufen lassen und da gibt das printf bzw.
sprintf den "richtigen" Wert aus, obwohl die Zahlen falsch im
Speicher stehen)

MFG

Hannes

<obwohl die Zahlen falsch im Speicher stehen)>
Ich verstehe nicht. Warum stehen sie falsch im Speicher bzw. wie sieht
man das?
Und was passiert eigentlich bei
me = (me / 10.0)+1; ?
Warum sind die Ergebnisse da bereits nach der 10. Division
unterschiedlich?
Könnte ich das Problem mit einem teuren Compiler Compiler erschlagen?

@tex:

Weiß ich nicht! Aber Hersteller teurerer Compiler stellen einem diese
durch aus als Demo-Version zur Verfügung, damit man solche Fragen vor
dem Kauf klären kann. ;)

Ausserdem kann man bei Hersteller ja anfragen, wie es um die
Rechengenauigkeit ihrer Bibliotheken bestellt ist bzw. ob sie double
korrekt unterstützen.

Gruß, Michael

Hallo tex,

Ich glaube ein teurer Compiler wird Dir bei Deinem Problem nicht
helfen. Ich habe mal nach einem Dokument gesucht, welches die Probleme
mit Gleitkommazahlen bei der Berechnung im Computer erläutert. Es ist
leider nur in Englisch verfügbar, ich hoffe, das ist kein Problem.

http://docs.sun.com/source/806-3568/ncg_goldberg.html

Ich kann mir immer noch nicht vorstellen, was Du da tolles berechnest.
Aber wenn Du so eine hohe Genauigkeit benötigst, dann verwendest Du
meiner Meinung nach die falsche Plattform. Es gibt ja nicht umsonst
FPUs, die für die Berechnung von Gleitkomma-Zahlen entworfen wurden.

Wenn Du Dich näher mit dem Thema auseinandersetzen willst, dann schau
mal nach dem Standard IEEE754. Nach dieser Methode werden
Gleitkommazahlen in Binärer Form abgebildet. Wenn Du das obige Dokument
liest, dann werden Dir die Probleme bei Deinen Berechnungen auffallen.

mfg, Stefan.

P.S. Ich glaube Du versuchst nicht das Problem zu beheben, sondern nur
die Symptome.

@ Stefan May:

Eine FPU ist mitnichten nötig, um beliebig präziese zu rechnen! Sie ist
nur dann nötig, wenn dieses auch noch schnell gehen soll. Wie wir
bereits gehört haben, scheint es tex darauf nicht anzukommen.

Auch mich würde übrigens interessieren, um was es bei dieser Anwendung
geht.

Gruß, Michael

"Ich glaube Du versuchst nicht das Problem zu beheben, sondern nur
die Symptome."


Das glaube ich auch.

Da alle mir bekannten µC-Compiler nur 32Bit floats können, sollte man
versuchen, die Formeln so umzustellen, daß sich die Fehler entweder
weitgehend kompensieren oder garnicht erst so weit aufschaukeln.


Eine andere Möglichkeit ist auch, die ganze Mathematik in Assembler zu
machen. Da ist es dann leicht, eine beliebig genaue Ganzzahlarithmetik
zu machen (80 Bit, 128 Bit oder was Du willst). Die Winkelfunktionen
müßte man dann auf die Grundrechenarten zurückführen.


Vorher sollte man aber erstmal prüfen, ob es auch wirklich daran liegt
und nicht an einem Speicherproblem (Stacküberlauf). Auch die 4kB können
schnell dahinfließen, wenn man irgendwo gemeine Rekursionen hat oder
versehentlich viele Konstanten (Texte) im SRAM definiert hat.

Dann gibt es auch noch das Mega103-Bit zu beachten, welches den
Speicher einfach mal verschiebt.


Peter

@tex:

>> obwohl die Zahlen falsch im Speicher stehen
> Ich verstehe nicht. Warum stehen sie falsch im Speicher
> bzw. wie sieht man das?

Ganz einfach: Die Zahlen werden ja im Speicher mit Exponent und
Mantisse dargestellt. Und bei einer 0,1 als Gleitkomma dargestellt
sieht die Mantisse in etwa so aus (double/52 Bit Mantisse):
1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1001 1011
Hier sieht man, das in der letzten Stelle aufgerundet wurde, da der
Bruch eben nicht endlos lang werden kann. Den Exponenten weiss ich
jetzt net ganz genau, aber es trifft die Sache schon ganz gut. Ein
teurerer Compiler wird hier auf keinen Fall was bringen, weil es halt
Mathematisch schon nicht funktioniert. Ich würde auch die Methode von
Peter anraten, bei der die Formeln eben nicht für Menschen genau
ausrechenbar sein müssen, sondern für die Maschine.

MFG

Hannes

Erst mal wieder vielen Dank euch allen. Im Prinzip komme ich ja mit den
38 Stellen der Float klar und der 80537 hat bewiesen, das es mit 8Bit
ja problemlos geht. Die Fehler liegen halt in meiner Software.
Ich sags nochmal. es ist nicht die genauigkeit, die mich in die floats
treibt. Bei der Berechnung treten halt nur Zahlen auf, die sich nur in
ab der 15. Nachkommastelle ändern. Weil diese zahlen in der Nächsten
Formel aber als ^2 ^3 ^4 ^5 wieder ienfließen ist ein winziger Fehler
im Vorhergehenden Wert in der nächsten Formel eine katastrophale
Abweichung. es geht um die Berchnung von Koordinaten im
dreidimensionalen Raum. Hast Du schon mal versucht eine Forelle im Bach
mit einem Speer zu fangen? Geht nicht, wegen der Lichtbrechung, wenn Du
keine Übung hast und nicht in der Lage bist den korrekten Blickwinkel
zu berechnen. Genauso kippst Du mit dem Fahrrad um, wenn Dein Gehirn in
der Kurve nicht den Winkel ausrechnen kann in der sich Zentifugalkraft
und Erdanziehung zu 0 addieren. Wenn also ein µC Fahrad fahren könne
soll muss er in der Lage sein, sowas auszurechnen. Klar. Sony und
Mitsubischi machen das mit Mega Aufwand mit FPUs. Ich habs mit 8 Bit
hinbekommen.

"Ich habs mit 8 Bit hinbekommen."

fahrradfahren oder fische fangen?

Liegt es an mir?

        double JD;

  D = 2454939 - 1534.063232;

  display_clear();
  display_cursor(1,1);
  sprintf(displaystring,"%-6.6f", (double)D);
        display_string(displaystring);

Das ausgegebene Ergebnis ist
      2453405.0000
Was mache ich falsch?

evtl
D = (double)2454939 - 1534.063232;
bzw
D = 2454939.0 - 1534.063232;

Hi

jetzt glaubs halt endlich:
Die Fließkommaimplementierung des AVRGCC unterstützt nur Zahlen mit
einfacher Genauigkeit (-> float). Dieses Format kann dank 23 Bit
Mantisse etwa 7 Dezimalstellen darstellen.

Matthias

ja schon, aber mir gehen hier gerade ALLE Nachkommastellen flöten! Ich
wäre ja bei der Zahl oben schon froh, wenns denn 3-4 Nachkommastellen
wären.

Du hast eine Integer-Addition hingeschrieben. Wenn Du schreibst


x = 23 + 1.4

Dann ist das Ergebnis 24 und nicht 24.4, weil das Ergebnis der Addition
ein int ist. Du mußt hinschreiben

x = 23.0 + 1.4

Das hat Tobi schon geschrieben. Selbst wenn x ein double, float oder
was auch immer ist, dann ist das Ergebnis der Addition trotzdem ein
int.

ciao, Stefan.

P.S. siehe dazu auch K&R Einführung in C

"wenns denn 3-4 Nachkommastellen wären."
bei floating point darstellungs sind vor- und nachkommastellen das
gleiche. du hast deine 7 stellen schon vor dem komma ausgereizt, da
bleibt für dahinter nix mehr über

@Steffan
OK. Das war dann beim RC-Compiler anders. Wie muss ich es schreiben,
wenn der erste Summand der ganzzahlige Anteil einer Division ist, also
sagen wir mal   (signed long)(A/12.5) ? DA aknn ich ja nun kein .0
dransetzen.

@Tobi
Sorry, Dein Statement hatte ich nicht gesehen.

@tex:

  (A / 12.5)

Was hier geschieht, hängt vom Datentyp der Variablen A ab.

Wenn das ein int ist, Du aber eine float-Division ausführen möchtest,
hilft ein Typecast:

  ((float) A / 12.5)

nein nein, Noch mal die Frage:
Ich brauche als Ergebnis einer Addition eine Gleitkommazahl. Ein
Summand (z.b 2) sind jedoch gewollt Integer
Stelle ich mir dass dann so vor?

x = (float)((unsigned int)(A/12.5)) + 15.5

??

x=((float) 0.08*a+15.5)

He he,
nicht schlecht
IAR-Compiler macht übrigens 64Bit floats

> Stelle ich mir dass dann so vor?
>
> x = (float)((unsigned int)(A/12.5)) + 15.5

Stell doch die 15.5 nach vorne:

x = 15.5 + ((unsigned int)(A/12.5))

Hierbei
> x=((float) 0.08*a+15.5)
ist (A/12.5) doch als float enthalten und nicht als Dein gewünschter
Integer.

Volkmar

ich hab es vorwärts und rückwärts, mit und ohne (float) ... eingegeben,
mit und ohne Optimierung im Makefile das Ergebnis ist immer integer.
Ich habe keine Idee mehr.

Hi

es ist kein Integer. Es ist ein float. float kann aber nur 7
Dezimalstellen darstellen. Wenn die schon vor dem Komma sind kommen
nach dem Komma einfach keine Zahlen mehr. Informier dich endlich über
die Funktionsweise von Fließkommazahlen. Dann wird dir auch klar was da
passiert.

Matthias

@tex: Was Matthias meint ist:

D = 2454939 - 1534.063232;
D = 2453405.0000

D hat eben schon 7 gültige Ziffern und lässt eben keine
Nachkommastellen mehr zu.

Hier ist dieses ominöse Problem mit den 7 gültigen Ziffern (eben NICHT
Nachkommastellen) sehr schön zu sehen. Die 32 Bit Floats können eben
nicht mehr! Auch mein Super-Hyper-Pseudo Visual Studio .NET 2003
Compiler für x86 rechnet nicht genauer als der 8-Bit AVRGCC. Ein
anderer Compiler der möglicherweise 64 Bit berechnet hat aber genau das
gleiche Problem:
Du hast möglicherweise ne Zahl, die 5 Stellen vor dem Komma hat, dann
kannst du eben auch nur 10 Stellen hinter dem Komma noch genau
darstellen. Von dem her ...

Wie schon gesagt müsstest du für dein spezielles Problem mit der
Genauigkeit der Zahlendarstellung eine eigene Mathe-Bibliothek
schreiben, die eine höhere Stellenzahl aufweist. (Z. B. die 80
Bit-Variante, die in x86 kompatiblen FPUs verwendet wird)

MFG

Hannes

Oder, wie schon einmal kurz angesprochen, eine BCD-Arithmetik. Das ist
die einzige Möglichkeit, Dezimalzahlen fehlerfrei darzustellen. Viele
Warenwirtschaftsprogramme arbeiten damit, da sonst bei der Berechnung
von Rabatten nur Müll herauskommt.
Ein sehr interessanter Artikel:

http://www.3dcenter.de/artikel/fp_format/

Zwar gehts hier um Grafikkarten und die genutzten Zahlenformate, aber
das ist eine sehr informative Seite. Dort werden verschiedene Fix- und
Gleitkommatypen beleuchtet und die Vor- und Nachteile diskutiert.

@ Matthias
Sorry! Bin ein bisschen begriffsstutzig die Tage. Ich hatte meine
C-Buch Definition 3.4Exp-38 noch im Hinterkopf, was sich ziemlich genau
mit meinem Versuch von oben deckte und wollte Dir nicht so recht
glauben,
Ich tue hiermit Buße.

Inzwischen ist das Problem klar. Ich werde mal versuchen, ob ich es
umgehen kann, aber ich finde es gotterbärmlich, dass mein kleiner
billiger 0815 RC-Compiler, der mit Sicherheit schon uralt war, als ich
ihn vor 10 Jahren für mein Projekt bemühte, ganz locker 64Bit Variablen
konnte und die neueste Evolution auf dem µC-Markt 10 Jahre später, mit
Debugger und gigantischen Make-Files, die das 1000fache an Speicher und
Rechnerperformance frisst, einen erbärmlichen Bruchteil dessen leistet,
was das Uraltprodukt hergab.
Mit der Technik von heute hätte ich mein Projekt von vor 10 Jahren
nicht realisieren können.

Ich schau mich mal nach etwas ausgegoreneren Compilern um, weil die
Lösung mit der Zahlenumstellung nur ein Notlösung sein kann.
Das Teil von IAR hab ich schon, also die Demoversion, die kann zwar
meine 64bit, aber glücklich bin ich damit nicht so recht. Die
Lizenzanbindung am meinen Rechner, wo ich mir alle halbe Jahre ein
neues Notebook gönne, ist rottig. Außerdem bekomme ich einfach nichts
damit zusande, was ich in meinen Prozessor schieben kann? Ich zu doof
oder Programm zu doof?

Also wenn jemand eine Nette Idee für einen Compiler hat, der sich nicht
an einer Double-Variablen verschluckt, ...

Und noch einmal vielen Dank an alle die mir hier so nett geholfen
haben.