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?
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.
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.
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang