Forum: Compiler & IDEs Festkomma, fract, accum, sat?


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
von Festkomma (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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?

von N. G. (newgeneration) Benutzerseite


Bewertung
0 lesenswert
nicht lesenswert
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.

von W.S. (Gast)


Bewertung
0 lesenswert
nicht lesenswert
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.

von Festkomma (Gast)


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

Na, das ist doch mal ein Argument.

Antwort schreiben

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

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.