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.
W.S. schrieb: > Dann > wächst das Ergebnis bei Multiplikationen nämlich nach rechts Na, das ist doch mal ein Argument.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.