Es ist nicht nur nicht simpel, es ist auch nicht sinnvoll, wenn man zuhauf float- und double-Berechnung braucht, zusammen mit den ebenfalls nötigen reellen und transzendenten trigonometrischen und Exponential-Funktionen, die wiederrum intern mit Taylorreihen oder Produktentwicklungen etc. nachbildet werden und dafür intern irrsinnig viele fp-Divisionen durchführen.Zitat von PICture
Tatsächlich rechnet aber ja jede MCU IMMER nur mit integer-Werten, nämlich binär kodierten bytes (=integer-Werten), tut also nichts anderes, als wenn man das auf 8bit-Prozessoren umständlich selber mit int nachbilden will - es ist nur hochoptimiert seitens C/C++ und MCU für Geschwindigkeit und Genauigkeit. Gerade die C/C++-Compiler sind auch optimiert auf Probleme, die durch den Vergleich zweier fp-Variablen auf Gleichheit oder Ungleichheit betrifft u.v.m., was durch minimalste Rundungsfehler der Rechen-Zwischenschritte bei der Konvertierung von fp in ihre binären Repräsentationen angeht.
Dabei muss man auch wissen, dass floats oder deren int16-Repräsentationen oft nicht genau genug sind, um bestimmte Berechnungen zu lösen (wie z.B. Matrix-Determinanten) und dadurch extremst falsche Ergebnisse liefern, daher muss man dann zwingend double verwenden.
Ich hatte schon oft bei meinen ersten Gehversuchen mit Matrizen mit dem Mega2560 (8bit-AVR, kann nur float, kein double) das "unerklärliche" Ergebnis, dass oft Determinanten einen Wert von deutlich größer null hatten (z.B. ein- oder zweistellig positiv), per float berechnet, obwohl die Matrizen antisymmetrisch waren oder ihre Zeilen nicht linear unabhängig, also die det(M) Null hätten sein müssen. Man kann eine Matrix mit Determinante Null aber nicht invertieren (genausowenig wie man durch Null dividieren darf), und die linearen Gleichungssysteme sind bei det(M)=0 nicht lösbar, und das falsche Ergebnis mit floats hätte dies fälschlich erwarten lassen.
Erst double-fp auf 32-bit ARMs erbrachte dann die korrekten Ergebnisse.
Es geht also bei float vs. double vs. int-Arithmetik nicht (nur) um Genauigkeit des Endergebnisses, sondern sogar u.U. tatsächlich darum, ob das Problem überhaupt grundsätzlich lösbar ist.
Fazit: wer 8bit AVRs mit floats braucht, soll mit floats rechnen, wenn es nicht zeitkritisch ist und die Genauigkeit ausreicht;
wer höhere Genauigkeit oder Geschwindigkeit braucht, soll ARM Cortex verwenden, entweder mit single- oder falls erforderlich double-fp, im Extremfall auch mit fpu (M4 oder SoC).
Alles andere ist Murks.
Wer also weiß, dass später vielfach fp zeitintensiv benötigt wird, soll besser gleich mit ARMs anfangen (my2ct).
Zitieren
Lesezeichen