Ich brauche dringen eure Hilfe. Realtypen unter Delphi.
- Ersteller J-BRO
- Erstellt am
J-BRO
Vice Admiral Special
Hey Leute, kommt grad echt mal drauf an, ich weiß, dass ich das selber auf die Reihe kriegen sollte, aber ich packs einfach nicht.
Ich muss morgen ein Referat in Informatik halten, das Thema lautet.
" Darstellung von Dezimalzahlen; Datentypen von Delphi und Fähigkeiten des Mikroprozessors "
Also wie geht der Mikroprozessor mit Dezimalzahlen um?
Ich habe mir bis jetzt Informationen um die Realtypen aus Büchern und dem Internet zusammengesucht aber irgendwie bekomme ich hier nix handfestes auf die Reihe... Hat vielleicht jemand ein brauchbares Dokument oder einen guten Link, der mir weiterhelfen könnte, eigentlich versteh ich nichmal den Sinn davon, und wie z.B. beim Typ Double der Bereich 5.0e-324..1.7e308 zustande kommt.
Ich bin für jede Hilfe dankbar...
Jo
Ich muss morgen ein Referat in Informatik halten, das Thema lautet.
" Darstellung von Dezimalzahlen; Datentypen von Delphi und Fähigkeiten des Mikroprozessors "
Also wie geht der Mikroprozessor mit Dezimalzahlen um?
Ich habe mir bis jetzt Informationen um die Realtypen aus Büchern und dem Internet zusammengesucht aber irgendwie bekomme ich hier nix handfestes auf die Reihe... Hat vielleicht jemand ein brauchbares Dokument oder einen guten Link, der mir weiterhelfen könnte, eigentlich versteh ich nichmal den Sinn davon, und wie z.B. beim Typ Double der Bereich 5.0e-324..1.7e308 zustande kommt.
Ich bin für jede Hilfe dankbar...
Jo
Such mal nach BCD Zahlen, da stellt jeweils ein Nibble (also eine Hex-Ziffer) nur eine Dezimalzahl dar (hat nur die Möglichkeitne 0..9, A..F wird nicht benutzt).
Glücklicherweise wurde der Mist noch nie großartig benutzt. Bringen tut das nämlich genau garnix, war vielleicht vor 30 Jahren mal ganz hilfreich, damit man nicht alle Zahlen erst in Hex umrechnen muss.
Glücklicherweise wurde der Mist noch nie großartig benutzt. Bringen tut das nämlich genau garnix, war vielleicht vor 30 Jahren mal ganz hilfreich, damit man nicht alle Zahlen erst in Hex umrechnen muss.
Was meinst du mit Dezimalzahlen? Das Zahlensystem (Dezimal, Binär, Hex, Oktal, ...), oder einfach nur gebrochene Zahlen? Da musst du dich schon klar ausdrücken
. Den Vortrag (sofern es soeinen schon gibt) wird dir hier niemand raussuchen, sondern nur Tipps geben, wo du was finden könntest.
Die BCD Zahlen bezogen sich auf das Zahlensystem - die CPU kennt mal von BCD Zahlen abgesehen keine Dezimalzahlen, sondern nur Binär (und damit verbunden auch Hex und Oktal).
Darstellung von Dezimalzahlen ist eigentlich kein großes Thema, die CPU speichert sowas als Mantisse (die Ziffern selbst) und Exponent (*10^yxz). Da suchst du dir am besten mal die verschiedenen Float-Formate raus (wenigstens single und double precision) und vergleichst die gegeneinander mit ihren jeweiligen Grenzen. Wenn du Lust hast, kannst du ja auch noch auf fixed point Zahlen eingehen, also Festkommazahlen, mit ihren Vor- und Nachteilen.
Datentypen von Delphi guckst du in die Delphi Hilfe, sind alle erklärt.
Und Fähigkeiten der CPU bezieht sich ja wohl eindeutig auf die FPU bzw. die diversen SIMD Implementierungen für Floats die es so gibt (3DNow, SSE2, AltiVec, ...).
Chris_Bear
Admiral Special
J-BRO schrieb:
Das hängt damit zusammen wie die Daten intern (binär codiert) dargestellt werden. Kann dir jetzt leider keine genaue Quelle nennen da ich grad auf Arbeit bin, aber vielleicht bring ich dich ja auf die richtige Spur:
Um mal bei deinem Beispiel zu bleiben: Double ist ein 64 Bit breites Datenformat. Dabei hat jedes Bit seine Funktion:
Das erste stellt dar ob's ne positive (=0) oder negative zahl ist (=1). Die Null selbst ist hierbei ne positive Zahl, deswegen geht der Bereich bei den negativen Zahlen etwas weiter. Schau auch mal nach dem Begriff "Zweierkomplement", um die negativen Zahlen deuten zu können.
Dann kommen ein paar Bits für die (normalisierte) Mantisse, ich glaub das waren etwas mehr als 30. Diese geben den eigentlichen Wert an. Normalisiert heißt hierbei daß immer das Komma soweit verschoben wird bis 1,xxx rauskommt und der Exponent entsprechend angepaßt wird (xxx können hierbei nur 0 oder 1 sein, eben Binärformat). Dann braucht man nämlich die 1 nicht mit abspeichern und gewinnt 1 Bit zur Zahlendarstellung. Außerdem braucht man dann bei 0,0000000000000xx die Nullen nicht mit abspeichern, frißt nur Platz.
Die letzten Bits stellen den Exponenten dar (auch wieder binär codiert), wobei auch wieder 1 bit für das Vorzeichen steht.
Daher kommt von dir angegebene der Bereich. Übrigens ich auch um die Null herum ne "tote Zone", da Zahlen nicht unendlich klein dargestellt werden können, die werden dann einfach Null. Kann man ein paar lustige Spielchen mit treiben, oder auch lustige Bugs hervorrufen mit
.Um das zu veranschaulichen könntest du mal ein Zahl immer weiter durch 2 teilen, irgendwann kommt Null raus, dann hast du die kleinste mögliche Zahl rausgefunden im Double. Bei Float (oder heißt das bei Delphi Real?) ist diese Zahl übrigens etwas größer, probier's mal aus.
Eine andere Sache die vielleicht interessant ist, ist die Addition einer sehr großen (5e100) und einer sehr kleinen Zahl (5e-100). Da siehst du daß die Mantisse nur endlich lang ist, da der kleine Teil einfach "weggerundet" wird. Es kommt raus 5e100 + 5e-100 = 5e100, was ja mathematisch falsch ist. Falls das Beispiel jetzt doch noch nicht klappt probier mal größere Zahlen. Aber jetzt drifte ich langsam in Richtung Numerik ab...
Hoffe ich konnte dir etwas helfen und hab dich jetzt nicht komplett verwirrt!
@ all: korrigiert mich falls hier etwas falsch sein sollte, ich hatte das auch nicht grad erst gestern und bin nicht sicher ob ich mich jetzt an alles 100% korrekt erinnere.
Gruß,
Chris
![mtb][sledgehammer](/data/avatars/m/1/1883.jpg?1596828194){kind=avatar}
mtb][sledgehammer
Grand Admiral Special
Für die beiden Standard FP Variablen single und double habe ich die Werte der Mantisse und des Exponenten bei Wiki gefunden:
http://de.wikipedia.org/wiki/IEEE_754
Die Mantisse gibt AFAIK dabei einen Wert zwischen 1und 2 an, dieser wird mit 2^(Exponent) multipliziert. und dann eben das Vorzeichen.
Ein Sonderfall ist der 80 Bit genaue Extended Wert (laut Delphi Hilfe: "Extended 3.6 x 10^?4951 .. 1.1 x 10^4932"), wenn ich mich nicht verrechnet habe (mein TR kann das nicht mehr), dann müsste das Format 15 Bit Exponent und 64 Bit Mantisse haben, aber das sollte noch jemand nachrechnen.Ich weiß auch nicht, welche Architektur außer dem x86 Rechner das x87 FPU das Format unterstützt
http://de.wikipedia.org/wiki/IEEE_754
Die Mantisse gibt AFAIK dabei einen Wert zwischen 1und 2 an, dieser wird mit 2^(Exponent) multipliziert. und dann eben das Vorzeichen.
Ein Sonderfall ist der 80 Bit genaue Extended Wert (laut Delphi Hilfe: "Extended 3.6 x 10^?4951 .. 1.1 x 10^4932"), wenn ich mich nicht verrechnet habe (mein TR kann das nicht mehr), dann müsste das Format 15 Bit Exponent und 64 Bit Mantisse haben, aber das sollte noch jemand nachrechnen.Ich weiß auch nicht, welche Architektur außer dem x86 Rechner das x87 FPU das Format unterstützt
Chris_Bear
Admiral Special
i_hasser schrieb:
Stimmt, aber alles außer der Addition ist hier schmückendes Beiwerk. Falls der Compiler hier nicht zu viel "optimiert" und die Reihenfolge der Addition und Subtraktion vertauscht (was ja mathematisch noch korrekt wäre) kommt dann div by 0 raus für den Fall daß die Zahlenbereiche zu groß sind. AFAIR versessert ne Division sogar die Genauigkeit wieder...
Gruß,
Chris
Eine Division verbessert die Genauigkeit eigentlich nicht. Die Division soll nur zeigen, wie so eine triviale Rechnung auf einmal ein völlig schwachsinniges Ergebnis liefert.
In C könnte man die Optimierungen des Compilers so umgehen:
Durch das volatile wird jede Zuweisung in der angegebenen Reihenfolge ausgeführt.
In C könnte man die Optimierungen des Compilers so umgehen:
Code:
volatile double a;
a=1e20;
a+=1e-20;
a-=1e20;
a=1e-20/a;Durch das volatile wird jede Zuweisung in der angegebenen Reihenfolge ausgeführt.
Chris_Bear
Admiral Special
OK, das wird mir dann langsam doch etwas hoch. Hab selbst noch nicht aktiv den Compiler beeinflußt. Nur in dem Beispiel reicht es schon sich a einfach mal nach a+=1e-20; ausgeben zu lassen. Sollte 1e20 dastehen, was ja mathematisch schon falsch ist. Der Rest ist dann schönrechnen...
Gruß,
Chris
Gruß,
Chris
mtb][sledgehammer
Grand Admiral Special
Klar, das könnte man selbst mit 80 Bit nicht rechnen, da die Mantisse eben in Dezimalzahlen auch dann nur knapp 20 Stellen hergibt, während diese Rechnung eben 40 braucht. Aber genau deshalb beschäftigen sich ja genügend Mathematiker mit der Numerik, um solche Rechnungen sinnvoll durchzuführeni_hasser schrieb:
