Festkomma, fract, accum, sat?

[Festkomma (Gast)]

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?

Wenn ich das richtig verstehe, geht es nur um das Verhalten beim 
Über/Unterlauf.
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.
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?

Und Wo - ganz praktisch - würde ich das Zeugs (fract, accum & Co) 
überhaupt verwenden an Stelle von Integer-Arithmetik?

[N. G. (newgeneration)]

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.

[W.S. (Gast)]

N. G. schrieb:
> Inwiefern diese fixed-point-Typen einen Performance-Vor- oder Nachteil
> bringen, kann ich dir aber im Moment nicht sagen.

Ist nicht so schwer zu verstehen: Sowas braucht man bei der digitalen 
Signalverarbeitung, wenn man mit Festkomma rechnet und nicht mit 
Gleitkomma. Aber dort sollte es bittesehr nicht in Software, sondern in 
Hardware erfolgen, sonst wird der Code zu trödelig.

Also: wenn du z.B. ne Multiplikation in Integer machst, wächst das 
Ergebnis nach links, du kriegst also regelmäßig größere Zahlen heraus 
als die Operanden. Sowas ist ärgerlich und praktisch nicht zu 
gebrauchen. Also skalierst du alles (die zu verarbeitenden Werte und die 
diversen Faktoren etc.) so, daß es echt gebrochene Zahlen sind. Dann 
wächst das Ergebnis bei Multiplikationen nämlich nach rechts - eben 
immer vom Dezimalpunkt weg. Damit kann man arbeiten, weil dann nämlich 
nur die am wenigsten bedeutsamen Bits nach rechts ins Nirvana gehen.

Normalerweise macht man das so, daß man vor dem (gedachten) Dezimalpunkt 
ein Vorzeichenbit und zwei ganzzahlige Bits vorsieht und alles Andere 
kommt nach dem Dezimalpunkt. Dann hat man nämlich noch etwas Luft nach 
oben, falls bei Filterkerneln usw. mal bei der Konvolution etwas 
überläuft. Aus diesem Grunde haben die Akkus von DSP's auch meistens 
mehr Bits als die eigentlichen Datenbreiten haben.

W.S.

[Festkomma (Gast)]

W.S. schrieb:
> Dann
> wächst das Ergebnis bei Multiplikationen nämlich nach rechts

Na, das ist doch mal ein Argument.