Hallo,
Festkomma schrieb:
> Hallo zusammen,
>
> nun habe ich mir mal die Definitionen bei open-std.org durchgelesen
> ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf ), und
> denke, dass ich fract und accum in ihren Spielarten verstanden habe.
> Aber wozu brauche ich sat?
Sat steht, wie du richtig erkannt hast, für saturation, zu deutsch
Sättigung.
> Wenn ich das richtig verstehe, geht es nur um das Verhalten beim
> Über/Unterlauf.
Korrekt.
> Bei sat Variablen ist das Ergebnis dann die höchste oder niedrigste
> darstellbare Zahl (d.h. bei sat unsigned eine Null).
> OK, das scheint vernünftig.
Das ist vor allem bei DSP-Anwendungen wichtig, wo 127 + 1 nicht -128
sein sollte
> Aber das default Verhalten ist nicht sat - sondern "undefined". Warum?
> "Undefined" mag ich ja nicht so gern... Welchen Vorteil hat das?
> Wird der Code dann kleiner?
Exakt, dem Compiler wird die Freiheit gelassen, alles mit dem Code zu
machen. Unter anderem halt auch schneller.
Zu Saturation gibts ihr einen detaillierten Artikel, siehe
AVR Arithmetik/Saturierung (ist zwar für AVR, aber gilt natürlich
auch für andere Controller).
> Und Wo - ganz praktisch - würde ich das Zeugs (fract, accum & Co)
> überhaupt verwenden an Stelle von Integer-Arithmetik?
Naja, es ist ein Angebot. Du musst es nicht nutzen, aber diese
Datentypen können unter Umständen effektiveren Code führen. Im Zweifel
einfach mal eine Testreihe machen.
_Fract wäre beispielsweise etwas, wenn nur Zahlen kleiner 0 auftreten
können. Dort müsste man bei Integer erst einmal Skalieren, und dann
dementsprechend mit großen Zahlen rechnen.
Inwiefern diese fixed-point-Typen einen Performance-Vor- oder Nachteil
bringen, kann ich dir aber im Moment nicht sagen.
mit freundlichen Grüßen,
N.G.
