Hallo Forum, ich würde gerne Festkommazahlen in meinem Assemblerprogramm verwenden. Habe viel gegooglet und allerhand gefunden, nur nichts hilfreiches für mich. Bis jetzt habe ich folgende Erkenntnisse gesammelt. Bei 32 Bit Festkommazahlen ist das erste Bit das Vorzeichen, dann kommen 8 Bit für den Exponenten und der Rest ist für die Mantisse. Da kommt die erste Frage, hat die Mantisse auch ein Vorzeichen? Bisher dividierte ich mit einem Assemblerprogramm, bei dem ich die Ganzzahl und den Rest erhielt. Wie komme ich von der Ganzzahl und dem Rest auf eine Festkommazahl? Habt ihr ein paar Anregungen für mich?
Thomas S. schrieb: > Habt ihr ein paar Anregungen für mich? Eine Festpunktzahl hat keine Mantisse, sondern nur einen "gedachten Punkt" irgendwo mitten in den Bits. Nach jeder Rechnung muss das Ergebnis dann ggfs. entsprechend "zurechtgerückt" werden.
:
Bearbeitet durch Moderator
Thomas S. schrieb: > Bei 32 Bit Festkommazahlen ist das erste Bit das Vorzeichen, > dann kommen 8 Bit für den Exponenten und der Rest ist für die Mantisse. Du bist in der falschen Rubrik gelandet. Was du da beschreibst sind Floating Point Zahlen. Oft werden heutzutage die im IEEE-754-Standard definierten Formate verwendet. https://de.wikipedia.org/wiki/IEEE_754#Zahlenformate_und_andere_Festlegungen_des_IEEE-754-Standards > Da kommt die erste Frage, hat die Mantisse auch ein Vorzeichen? Wie willst du sonst negative Zahlen darstellen?
Lothar M. schrieb: > Eine Festpunktzahl hat keine Mantisse. Natürlich muss sie die haben. Genau genommen besteht eine Festpunktzahl nur aus der Mantisse, weil man den (sowieso festen) Exponenten gar nicht immer mitschreibt/speichert.
Thomas S. schrieb: > ist das erste Bit das Vorzeichen, [..] der Rest ist für die Mantisse. > Da kommt die erste Frage, hat die Mantisse auch ein Vorzeichen? Du hast dir das doch selbst beantwortet. Einmal davon abgesehen, dass das dann keine Festpunktzahl ist.
Thomas S. schrieb: > Hallo Forum, ich würde gerne Festkommazahlen in meinem Assemblerprogramm > verwenden. Habe viel gegooglet und allerhand gefunden, nur nichts > hilfreiches für mich. Bis jetzt habe ich folgende Erkenntnisse > gesammelt. Bei 32 Bit Festkommazahlen ist das erste Bit das Vorzeichen, > dann kommen 8 Bit für den Exponenten und der Rest ist für die Mantisse. Kompletter Unsinn. Festkomma hat nix mit Fließkomma zu tun. Es gibt also insbesonder nix in der binären Repräsentation, was man als Exponent bezeichnen könnte. Der steckt allein in der Interpretation der Zahl. Wie auch die Tatsache, ob signed oder unsigned.
Ich verwende fuer interne Rechnungen, zb Regelungsalgorithmen, immer Festkomma zahlen. Ich rechne immer mit Longint, 32 bit. Dort denke ich mir den Punkt zB auf der 8. Stelle. Das ist aber erst wichtig wenn ich auf's Stellglied gehe. als zB Stellglied 0..32767 (15bit). Da dividiere ich also durch 2^8, dh longint zahl shift right 8
Je nach Plattform und Aufgabe muss es keine binäre Festkommadarstellung sein. So kann man bespielsweise auch in Hundertsteln rechnen. Ist aber nur sinnvoll, wenn eine schnelle Division zur Verfügung steht.
Wolfgang schrieb: > Genau genommen besteht eine Festpunktzahl nur aus der Mantisse Uuuups, ist auch schon spät. Eine Festpunktzahl hat keinen (expliziten) Exponenten. Der Exponent ist lediglich ein "gedachter" Punkt mitten in der Mantisse...
:
Bearbeitet durch Moderator
Pandur S. schrieb: > Ich rechne immer mit Longint, 32 bit. Schwachsinn. Damit gibst du einen wesentlichen Vorteil auf: Speed. Man rechnet natürlich immer nur mit so vielen Bits, wie für die Anwendung nötig und sinnvoll (natürlich unter Berücksichtung der Rechenfähigkeiten des Targets).
c-hater schrieb: >> Ich rechne immer mit Longint, 32 bit. > > Schwachsinn. Damit gibst du einen wesentlichen Vorteil auf: Speed. Man > rechnet natürlich immer nur mit so vielen Bits, wie für die Anwendung > nötig und sinnvoll (natürlich unter Berücksichtung der Rechenfähigkeiten > des Targets). Er schrieb, was er tut, nicht was andere tun sollen. Was, wenn er immer nur 32-Bit Plattformen verwendet?
(prx) A. K. schrieb: > Er schrieb, was er tut, nicht was andere tun sollen. > Was, wenn er immer nur 32-Bit Plattformen verwendet? Dann ist das trotzdem Schwachsinn. Nämlich dann, wenn für die Anwendung die Genauigkeit von 32 Bit nicht ausreicht.
Beitrag #6569200 wurde vom Autor gelöscht.
Nein, auf AVR. 32 bit longit fuer Regelungsroutinen brauchen nicht so viel Leistung. Ich rechne mit einem Internen Tick von 10ms. Das beinhaltet die Messungen, Linearisierungen, Skalierungen, Algorithmen Speziell rechne ich nicht in Messwert Einheiten, sondern in ADC Einheiten. Eine Temperatur rechnet nicht in Celsius, oder aehnlich, sondern der Sollwert wird zu ACD Wert skaliert. > So kann man bespielsweise auch in Hundertsteln rechnen. Ist aber nur sinnvoll, wenn eine schnelle Division zur Verfügung steht. Deswegen rechnet man nicht mit 100-steln, sonder zB Hundertachtundzwanzigsteln, weil die schneller dividieren.
Pandur S. schrieb: > Deswegen rechnet man nicht mit 100-steln, sonder zB > Hundertachtundzwanzigsteln, weil die schneller dividieren. Nur, wenn du bzw. deine Plattform ein Binärsystem verwendet. Wenn du z.B. einen BCD-Rechner hast, dann bist du mit dem 10er-System besser bedient. Deswegen steht dort ja explizit "je nach Plattform".
:
Bearbeitet durch Moderator
Pandur S. schrieb: > Deswegen rechnet man nicht mit 100-steln, sonder zB > Hundertachtundzwanzigsteln, weil die schneller dividieren. Wenn es weniger auf Tempo als auf korrekte Rundung ankommt, kann dezimal sinnvoller sein.
Pandur S. schrieb: > BCD Platform ... wow, ein Beispiel wäre? Der 6502 konnte in BCD rechnen, auch die Saturn CPU der HP Taschenrechner
2⁵ schrieb: > Der 6502 konnte in BCD rechnen, ... Das Layout für den Chip wurde auch noch auf einem Zeichenbrett gemalt.
Pandur S. schrieb: > ein Beispiel waere ? Es geht nur darum, dass diese völlige Absolutheit mit "teile besser durch 128" eben einfach nicht uneingeschränkt stimmt, sondern nur für das Binärsystem gilt. Immerhin ist bislang völlig unklar, um welchen Assembler sich die Frage vom TO Thomas S. dreht...
Akzeptiert. Ich ging in meiner Limitiertheit von einer Binaeruebermacht in dieser Technologie aus.
2⁵ schrieb: > Der 6502 konnte in BCD rechnen Nicht wirklich. Er bietet nur die Unterstützung, um grundlegendste Operationen (Addition und Subtraktion) zumindest einigermaßen effizient hinzubekommen. Das tun allerdings fast alle µC und µP in irgendeiner Form. Allen gemeinsam ist: die BCD-Rechnerei ist weit weniger effizient als die native Rechnerei in pure binary. Sinnvoll ist der Einsatz von BCD-Arithmetik eigentlich nur dann, wenn Eingabe und Ausgabe Dezimal sein sollen (sprich: taschenrechnerartige Anwendungen). Das schließt die "Finanzmathematik" vollständig ein...
c-hater schrieb: > Das schließt die "Finanzmathematik" vollständig ein... Was spricht eigentlich dagegen, beispielsweise mit der üblichen binären Rechenweise in Cent statt Euros zu rechnen? Abgesehen von der Performance, aber schneller als BCD ist man auf 32/64-Bittern damit sicher.
:
Bearbeitet durch User
(prx) A. K. schrieb: > Was spricht eigentlich dagegen, beispielsweise mit der üblichen binären > Rechenweise in Cent statt Euros zu rechnen? Weil z.B. (wirklich nur fiktives Beispiel) ein 1µF X7 0805 Kondensator bei Mouser 1,12 Cent kosten kann.
> 1,23456¢ Eher 0,00456¢. Ich rechne auch gerne mit 27 oder 18 bit FP-Zahlen. Das nutzt die Multiplizierer/DSP/RAM von FPGA besonders gut aus. BCD ist was fuer BWLer!
(prx) A. K. schrieb: > Gibts auch Preise wie 1,23456¢, oder hört das irgendwo auf? Solche Zahlen entstehen schon, wenn der USD Preis noch EUR umgerechnet wird. Der offizielle Umrechnungsfaktor hat 5 gültige Stellen und wenn die BWLer sich nicht trauen zu runden, weil dann die Buchführung nicht stimmt, kommt soetwas raus.
Wolfgang schrieb: > (prx) A. K. schrieb: >> Gibts auch Preise wie 1,23456¢, oder hört das irgendwo auf? > > Solche Zahlen entstehen schon, wenn der USD Preis noch EUR umgerechnet > wird. Der offizielle Umrechnungsfaktor hat 5 gültige Stellen und wenn > die BWLer sich nicht trauen zu runden, weil dann die Buchführung nicht > stimmt, kommt soetwas raus. Der BWLer hat dafür das Konto "Rundungsdifferenzen".
Ahhhhhhhh, jetzt ist der Groschen gefallen. OK. Angenommen ich möchte etwas mit dem ADC experementieren, Spannungen und Strom messen. Erste grundsätzliche Frage: Würdet ihr mir Oversampling auf z.B 32 Bit empfehlen? Und wieviel Bit für die Festkommazahl würdet ihr mir empfehlen?
Thomas S. schrieb: > Ahhhhhhhh, jetzt ist der Groschen gefallen. OK. Angenommen ich möchte > etwas mit dem ADC experementieren, Spannungen und Strom messen. Erste > grundsätzliche Frage: Würdet ihr mir Oversampling auf z.B 32 Bit > empfehlen? Und wieviel Bit für die Festkommazahl würdet ihr mir > empfehlen? Oversampling bedeutet 4fach abtasten, um daraus ein weiteres Bit zu mitteln. Wenn du damit von 10 auf 32 Bit kommen willst und 10μs Wandlungszeit annimmst (100k/s), dann dauert die Messung 55Jahre. Dafür wäre ich schon zu alt. Oversampling benutzt man für 2..3 zusätzliche Bits, aber nicht 22. Mal ganz abgesehen von der Präzision eines Analogfrontends für 32-Bit. Das müssten einen Störabstand von 190dB haben. Sollte ein ADC 0..5V messen, dann wäre das unterste Bit ~1nV.
Mist, da ist mir ein kleiner Fehler unterlaufen den ich auch nach mehrmaligen durchlesen nicht gesehen habe. Ich wollte 12 Bit schreiben nicht 32. Entschuldigt bitte diesen kleinen Fehler
Thomas S. schrieb: > Mist, da ist mir ein kleiner Fehler unterlaufen den ich auch nach > mehrmaligen durchlesen nicht gesehen habe. Ich wollte 12 Bit schreiben > nicht 32. Entschuldigt bitte diesen kleinen Fehler Ok, 16fach macht die 2 fehlenden Bits. ;-)
OK. Mit 12 Bits habe ich 4096 Werte die verarbeitet werden können. Wie sollte dann die Festkommazahl aussehen? So Bitweise
Thomas S. schrieb: > OK. Mit 12 Bits habe ich 4096 Werte die verarbeitet werden können. Wie > sollte dann die Festkommazahl aussehen? So Bitweise Na, das kommt natürlich darauf an, was mit dem Wert getan werden soll.
Ok, als erstes sollen die Werte angezeigt werden und uu noch für weitere Berechnungen herangezogen bzw abgespeichert werden. Zur Anzeige würden 2 Nachkommastellen wsl optimal sein. Für abspeichern sollten es schon 4 Nachkommastellen sein, denke ich.
Thomas S. schrieb: > Ok, als erstes sollen die Werte angezeigt werden und uu noch für weitere > Berechnungen herangezogen bzw abgespeichert werden. Zur Anzeige würden 2 > Nachkommastellen wsl optimal sein. Für abspeichern sollten es schon 4 > Nachkommastellen sein, denke ich. Dein Rechner verwendet keine Dezimalzahlen. Meinst du mit Nachkommastellen die Nachkommastellen von Zahlen im Dual- oder im Dezimalsystem? Vier Nachkommastellen im Dezimalsystem würde etwa 13 Nachkommastellen im Dualsystem entsprechen. In welchem Wertebereich liegen deine Zahlen?
Wolfgang schrieb: > Vier Nachkommastellen im Dezimalsystem würde etwa 13 Nachkommastellen im > Dualsystem entsprechen Fast. Wenn man das ernst meint, ist Aufrunden angesagt.
Bevor du eine ganze Mathe Bibliothek in Assembler nachbildest, erwäge nochmal auf den Verzicht von Fließkommazahlen. Denn statt 1,48€ kann man auch mit 148 Cent rechnen. Statt 1,5 Volt kann man mit 1500mV rechnen. Das Komma ist dann nur noch eine Frage der Darstellung.
Carl D. schrieb: > Ok, 16fach macht die 2 fehlenden Bits. ;-) Oversampling funkioniert aber nur, wenn genügend Rauschen im Signal ist. Ist das Signal absolut sauber, gibt es im Ergebnis nur 2-Bit-Sprünge.
Stefan ⛄ F. schrieb: > Bevor du eine ganze Mathe Bibliothek in Assembler nachbildest, erwäge > nochmal auf den Verzicht von Fließkommazahlen. Es geht nicht um Fließkommazahlen, sondern um Festkommazahlen. Das bedeutet Ganzzahlrechnung und einen eingeschobenen Dezimalpunkt alleine bei der Ausgabe
Pandur S. schrieb: > Speziell rechne ich nicht in Messwert Einheiten, sondern in ADC > Einheiten. Eine Temperatur rechnet nicht in Celsius, oder aehnlich, > sondern der Sollwert wird zu ACD Wert skaliert. Gibt es dafür einen Grund? Ich kann mir irgendwie vorstellen, dass man Regelalgorithmen besser auf den physikalischen Einheiten (auch passend skaliert) entwickeln kann...?
S. R. schrieb: > Ich kann mir irgendwie vorstellen, dass man > Regelalgorithmen besser auf den physikalischen Einheiten (auch passend > skaliert) entwickeln kann...? Der Regelalgorithmus ist unabhängig von den Einheiten. Alles was sich ändert, sind Skalierungskonstanten. Wenn man mit Rechenzeit um sich schmeißen kann, ist das egal. Dann kann man sich aber auch die Umsetzung in Assembler sparen.
Wolfgang schrieb: > (prx) A. K. schrieb: >> Gibts auch Preise wie 1,23456¢, oder hört das irgendwo auf? > > Solche Zahlen entstehen schon, wenn der USD Preis noch EUR umgerechnet > wird. Oder wenn man davon: c-hater schrieb: > Weil z.B. (wirklich nur fiktives Beispiel) ein 1µF X7 0805 Kondensator > bei Mouser 1,12 Cent kosten kann. die Merwertsteuer ausrechnen will. Carl D. schrieb: > Der BWLer hat dafür das Konto "Rundungsdifferenzen". Das hat sich schon in Superman III einer zunutze gemacht. S. R. schrieb: > Pandur S. schrieb: >> Speziell rechne ich nicht in Messwert Einheiten, sondern in ADC >> Einheiten. Eine Temperatur rechnet nicht in Celsius, oder aehnlich, >> sondern der Sollwert wird zu ACD Wert skaliert. > > Gibt es dafür einen Grund? Ja, um den Wertebereich voll auszunutzen. > Ich kann mir irgendwie vorstellen, dass man Regelalgorithmen besser auf > den physikalischen Einheiten (auch passend skaliert) entwickeln kann...? Was meinst du mit "passend skaliert"? Das ist ja genau das, was gemacht wird.
Rolf M. schrieb: >> Ich kann mir irgendwie vorstellen, dass man Regelalgorithmen besser auf >> den physikalischen Einheiten (auch passend skaliert) entwickeln kann...? > > Was meinst du mit "passend skaliert"? > Das ist ja genau das, was gemacht wird. Beispielsweise mit mV oder kV statt Volt, wenn's besser passt. Aber trotzdem physikalisch.
S. R. schrieb: > Beispielsweise mit mV oder kV statt Volt, wenn's besser passt. Aber > trotzdem physikalisch. ADCV.... :) PS: Kauft euch doch nen µC mit "Komma-Marker" ;D
S. R. schrieb: > Rolf M. schrieb: >>> Ich kann mir irgendwie vorstellen, dass man Regelalgorithmen besser auf >>> den physikalischen Einheiten (auch passend skaliert) entwickeln kann...? >> >> Was meinst du mit "passend skaliert"? >> Das ist ja genau das, was gemacht wird. > > Beispielsweise mit mV oder kV statt Volt, wenn's besser passt. Aber > trotzdem physikalisch. Du kannst auch einfach die Einheit "Svenska" erfinden, und ein Svenska ist 4,8828125 Millivolt und passt zufällig perfekt auf den Zahlenbereich des ADCs. Dann hast du auch eine physikalische Einheit. ;-)
:
Bearbeitet durch User
Wolfgang schrieb: > Es geht nicht um Fließkommazahlen, sondern um Festkommazahlen. Nachdem wir nun festgestellt haben, dass der TO sich entweder völlig unglücklich ausgedrückt hat oder auch nur keine Ahnung hat, ist doch alles gesagt, was zu sagen ist! Wen interessiert es da noch, dass jemand mit einem 12-Bit-AD-Wandler ausgerechnet mit 4096 rechnet :-) Gruß Rainer
@Rainer V. Du hast mich voll durchschaut, ich habe keine Ahnung von Festkommazahlen. Darum wende ich mich an Euch. Könten wir ein Beispiel machen? z.B. ich habe vom ADC den Wert 1834 bekommen. Wie würde der in in Festkommaarithmetik aussehen?
Peter schrieb: > Könten wir ein Beispiel machen? z.B. ich habe vom ADC den Wert 1834 > bekommen. Wie würde der in in Festkommaarithmetik aussehen? Naja, in einer 16Bit-Variablen 1834 dec oder 072A hex oder 0000011100101010 bin Kommt drauf an, wie du dir das anzeigen läßt. All das ist aber auch eine Festkommazahl (mit 0 Nachkommastellen). Wenn aber jetzt die Aufgabe wären, die Hälfte davon zu berechnen, dann kannst du das ganz einfach tun und dabei 0 Rechenzeit verbrauchen. Du setzt einfach gedanklich das Komma in der Binärdarstellung eine Stellen nach links und erhältst: 000001110010101.0 Im Speicher steht nach wie vor dieselbe Zahl, du legst nur für dich (und dein Programm) fest, dass sie anders zu interpretieren ist. That's the main trick...
Peter schrieb: > @Rainer V. > Du hast mich voll durchschaut, ich habe keine Ahnung von > Festkommazahlen. Darum wende ich mich an Euch. Dann mach einen eigenen Thread auf, statt den hier zu kapern. > Könten wir ein Beispiel machen? z.B. ich habe vom ADC den Wert 1834 > bekommen. Wie würde der in in Festkommaarithmetik aussehen? Genauso. Festkomma-Arithmetik ist eine Art die Daten zu interpretieren. Und es gibt nicht nur eine, sondern beliebig viele.
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.