Hallo Leute Ich komme dummerweise in letzter Zeit nicht mehr um floats rum bei der Programmierung meines AVR's in C. Also habe ich mich damit beschäftigt und dabei rausgefunden, dass ein normaler float nur 6-7 signifikante Ziffern hat. Naja, nicht so schlimm, ich habe ja noch den double, der sollte 15-16 signifikante Ziffern habe (http://de.wikipedia.org/wiki/IEEE_754). Nun habe ich das ausprobiert und dabei festgestellt, dass ich auch mit einem double nur 6-7 signifikante Ziffern habe. Kann mir jemand erklären, warum das so ist? Sollte ja noch IEEE nicht so sein (siehe Link). mit freundlichen Grüssen Sputnik
Gast
#707279
RTFM Für die avr-libc z.B. steht dort: >Data types: >char is 8 bits, int is 16 bits, long is 32 bits, long long is 64 bits, >float and double are 32 bits Oliver
Vielen Dank für den Hinweis. Ich habe es aber bis jetzt noch nicht im Manual von avr-libc gefunden. Aber wiso ist den das so? Was bringt denn so der double, wenn er tritzdem single precisision ist?
Gast
#708217
Portabilität. Programme von woanders laufen wenigstens "so ungefähr". In der C spec ist ja AFAIK nicht garantiert, dass double genauer als float ist.
Tom wrote: > In der C spec ist ja AFAIK nicht garantiert, dass double genauer > als float ist. Aber es ist für "double" ein Mindestgenauigkeit von 10 Dezimalstellen gefordert. GCC/AVR ist also in dieser Hinsicht nicht ANSI-konform.
float ist in den meisten Programmiersprachen einfach ein Alias für das default-Fließkommaformat - meist single oder double single und double kann in jeder Programmiersprache was anderes bedeuten. Bei int isses ähnlich.
Gast
#708282
Waere nun nicht die passende Frage, wie man die Library aout 64bit float aufbohren kann ?
sechszweisechs wrote: > Waere nun nicht die passende Frage, wie man die Library aout 64bit float > aufbohren kann ? Du musst das gleichzeitig auch dem Compiler beibringen. Das ist kein unüberwindliches Hindernis, da er mit 64-Bit Daten bereits umgehen kann, aber bis dahin gilt sizeof(double)==4, da ändert keine Library etwas daran. Eher ein Grund, für solche Jobs geeignetere Controller zu verwenden.
Gast
#708315
Eine einfache Suche hier im Forum fördert u.A. das hier zu Tage: Beitrag "CrossWorks AVR" Vielleicht hilfts weiter. Oliver
Gast
#708460
> Aber wiso ist den das so? Was bringt denn so der double, wenn er > tritzdem single precisision ist? Also die Wahrheit ist wohl das du, ja genau DU!, dich noch nicht hingesetzt hast und eine Libary fuer double programmiert hast. Andere Leute haben sich halt gedacht das es verdammt viel Arbeit ist sowas zu machen und sie dann besser auf einen anderen Prozessor umsteigen wo die Arbeit bereits erledigt ist. Zumal so eine Libary ja auch ordentlich Platz im Rom braucht und einiges an Ram verloren geht. Mittlerweile wird man es einem dicken modernen AVRs sicherlich beibringen koennen, trotzdem ist sowas natuerlich nicht gerade ein Geschwindigkeitswunder. Weshalb dann wohl die meisten Menschen entweder feststellen das sie double garnicht brauchen, oder wenn es sich wirklich nicht umgehen laesst dann gleich einen Prozessor nehmen der das etwas besser unterstuetzt. Und der verbleibende Rest, als DU, hat es eben noch nicht programmiert. :-) Olaf
Gast
#708488
Richtig. Wenn's double nicht gibt, muss man zuerst herausfinden, ob man's wirklich braucht, und falls doch, selbst machen. Oder eine andere Library nehmen.
Gast
#708574
>Weshalb dann wohl die meisten Menschen entweder feststellen das sie >double
garnicht brauchen,
Die meisten werden wohl feststellen, daß sie noch nicht einmal float
brauchen.
Oliver
Gast
#708587
Ich würde eher behaupten, daß viele zwar float bzw. double eigentlich nicht bräuchten, das aber nicht feststellen.
Gast
#708606
Die schnellste Lösung für AVRs: IAR Systems. Wenn du auf C-Spy und MISRA verzichten kannst, liegst du bei knapp unter 2k€ (Netto). MW
Rolf Magnus wrote: > Ich würde eher behaupten, daß viele zwar float bzw. double eigentlich > nicht bräuchten, das aber nicht feststellen. :-) ... aber irgendwann merken dass ihre Rechenergebnisse auf 'seltsame Art' nicht stimmen.
Hallo Leute Ich danke euch alles für eure Antworten. Ich denke auch, dass man vielfach den float oder double vermeiden kann/sollte und damit besser fährt. Naja, wie dem auch sei: Ich persönlich gehe den floats und doubles aus dem Wege, wo ich kann, nur leider hat es dieses Mal nicht ganz geklappt. Ich wünsche euch allen einen schönen Tag Sputnik
Gast
#709886
Überlege, ob du mit einem eigenen Format nicht ans Ziel kommst: * Festkommaformat (z.B. 16bit Vorkomma + 16 bit Nachkommawert) * struct Mantisse + Exponent (1 int Wert für Mantisse, 1 Wert für Exponent). * Kombination von beidem Fange am besten damit an den Zahlenbereich einzugrenzen/zu definieren und die benötigten Operationen. Auch komerzielle Bibliotheken haben ggf. Probleme. Ich weiss nicht ob IAR den Bug noch hat, aber früher waren die Float Library Funktionen nicht reentrant. Klaus
Klaus H. wrote: > Überlege, ob du mit einem eigenen Format nicht ans Ziel kommst: > > * Festkommaformat > (z.B. 16bit Vorkomma + 16 bit Nachkommawert) > * struct Mantisse + Exponent > (1 int Wert für Mantisse, 1 Wert für Exponent). > * Kombination von beidem > > Fange am besten damit an den Zahlenbereich einzugrenzen/zu definieren > und die benötigten Operationen. Ja, das ist dann der Weg, wenn es wirklich gar nicht mehr geht. Ist eben ein wenig Arbeit, aber für ein optimales Ergebnis kann/sollte man die Arbeit nicht scheuen. Ich habe mir auch schon Gedanken zu einem eigenen Format gemacht, habe aber bisher immer einen akzeptablen Weg mit schon vorhandenen Mitteln gefunden und deshalb noch nichts eigenes gemacht. Es dauert ja auch immer ein Weilchen, bis solche mathematische Funktionen schön ausgereift sind und auch wirklich schön durchoptimiert. ich wünsche ein schönes Wochenende Sputnik
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.