Wozu braucht man noch float und double?
-
Bashar schrieb:
Genau deshalb nicht. Deshalb heißt es ja "floating point", weil es das automatisch macht. Dein Vorschlag heißt entsprechend "fixed point", das kann man auch machen. Ist halt etwas mühsam, vorher die ganzen Wertebereiche auszutüfteln, um möglichst genau und ohne Überläufe zu rechnen.
Das ist ja jetzt kein Hexenwerk.
In 64 Bit passen so viele Stellen rein.
Das sind 64 Binärstellen, vergiß das nicht.
Denke an das Beispiel mit der Zeit oben. Da hast du troztdem noch Jahre.
Da wirste kaum einen Überlauf haben wenn du mit Sekunden rechnest.Und wenn du in großen Maßstäben, also viele Jahre rechnest, dann nimmst du halt nicht ne Pikosekunde als Basiseinheit, sondern z.b. ne Millisekunde.
Das reicht und du kannst ein paar Millionen Jahre hochrechnen.
-
Integer vs. Double schrieb:
Denke an das Beispiel mit der Zeit oben. Da hast du troztdem noch Jahre.
Da wirste kaum einen Überlauf haben wenn du mit Sekunden rechnest.Aber man kann den Fall konstruieren, dass du zwei Werte nicht sinnvoll vergleichen kannst, weil einer der beiden zu gross ist, um in 64 Bits exakt dargestellt zu sein. Z.B. kann man den Quotienten $$\frac {1} {21!}$$ in IEEE 754 näherungsweise darstellen. Wie machst du das mit deinen Fixkomma-Zahlen?
Edit: es reicht 21! statt 26!.
-
Integer vs. Double schrieb:
Bashar schrieb:
Genau deshalb nicht. Deshalb heißt es ja "floating point", weil es das automatisch macht. Dein Vorschlag heißt entsprechend "fixed point", das kann man auch machen. Ist halt etwas mühsam, vorher die ganzen Wertebereiche auszutüfteln, um möglichst genau und ohne Überläufe zu rechnen.
Das ist ja jetzt kein Hexenwerk.
Exakt, deshalb versteh ich nicht, wieso du dich daran so aufhängst. Festkommaarithmetik ist eine uralte Idee, die aber etwas aus der Mode gekommen ist, weil man bei jeder Rechnung die ganzen "Einheiten" (also Skalierungsfaktoren und ggf. Offsets) mit berücksichtigen muss.
Wie das Geschwindigkeitsmäßig aussieht, weiß ich gar nicht. Bevor es auf PCs üblich wurde, FPUs serienmäßig mit zu verbauen (etwas mehr als 15 Jahre her) hat man ganz gerne aus Geschwindigkeitsgründen Festkommazahlen benutzt. Danach plötzlich nicht mehr, wahrscheinlich lohnt es nicht den Aufwand.
-
mngbd schrieb:
Integer vs. Double schrieb:
Denke an das Beispiel mit der Zeit oben. Da hast du troztdem noch Jahre.
Da wirste kaum einen Überlauf haben wenn du mit Sekunden rechnest.Aber man kann den Fall konstruieren, dass du zwei Werte nicht sinnvoll vergleichen kannst, weil einer der beiden zu gross ist, um in 64 Bits exakt dargestellt zu sein. Z.B. kann man den Quotienten $$\frac {1} {21!}$$ in IEEE 754 näherungsweise darstellen. Wie machst du das mit deinen Fixkomma-Zahlen?
Edit: es reicht 21! statt 26!.
In dem man sich eine Art Übertragsrechnung ausdenkt.
Mit der könnte man dann sogar beliebige 64 Bit breite Ketten bilden.
Oder man wandelt alles in einen String um und rechnet auf Ziffernebene. Das geht auch. bc macht's vor.
-
Bashar schrieb:
Außerdem rechnet Int genau, double tut das nicht.
3/2 == 1
3.0/2.0 == 1.5
Wenn das deine Vorstellung von Genauigkeit ist ...Hatten wir dieses Thema nicht erst gerade?
-
Integer vs. Double schrieb:
In dem man sich eine Art Übertragsrechnung ausdenkt.
Mit der könnte man dann sogar beliebige 64 Bit breite Ketten bilden.Und dabei du kommst wirklich drum herum, das Fliesskomma neu zu erfinden? Erst hast du beliebig grosse Ganzzahlen, dann hast du Brüche daraus, dann definierst du eine Normalform für die Brüche -- und schon hast du das Fliesskomma erfunden.
Integer vs. Double schrieb:
Oder man wandelt alles in einen String um und rechnet auf Ziffernebene. Das geht auch. bc macht's vor.
Cool, da kann man mit 10 multiplizieren, indem man eine Null anhängt. Klingt richtungsweisend.
-
Nexus schrieb:
Bashar schrieb:
Außerdem rechnet Int genau, double tut das nicht.
3/2 == 1
3.0/2.0 == 1.5
Wenn das deine Vorstellung von Genauigkeit ist ...Hatten wir dieses Thema nicht erst gerade?
Sehr gut, hab ich gar nicht gesehen
Ich bleibe aber dabei. Eine solch absolute Aussage ("int ist genau, double nicht") ist Käse.
-
Integer vs. Double schrieb:
Und wenn du in großen Maßstäben, also viele Jahre rechnest, dann nimmst du halt nicht ne Pikosekunde als Basiseinheit, sondern z.b. ne Millisekunde.
Das reicht und du kannst ein paar Millionen Jahre hochrechnen.Man kann bestimmte ne Menge. Die Einheitensysteme, mit denen die Leute denken, sind aber längst festgelegt. Warum sollten die geändert werden, nur um Festkommaarithmetik ausnutzen zu können. Man hat doch angenehme Fließkommaarithmetik. Berechne doch mal die Kraft, mit der sich Sonne und Erde anziehen. Da hast Du irgendwo das Produkt der beiden Massen und das ist etwa 10^55kg². Warum sollte man sich bei so einer harmlosen Rechnung überlegen müssen, dass man die Einheit kg nicht nehmen kann, weil eine 128 Bit Ganzzahl so große Zahlen nicht darstellen kann. Das wäre doch ein echter Rückschritt.
-
Gregor@Home schrieb:
Integer vs. Double schrieb:
Und wenn du in großen Maßstäben, also viele Jahre rechnest, dann nimmst du halt nicht ne Pikosekunde als Basiseinheit, sondern z.b. ne Millisekunde.
Das reicht und du kannst ein paar Millionen Jahre hochrechnen.Man kann bestimmte ne Menge. Die Einheitensysteme, mit denen die Leute denken, sind aber längst festgelegt. Warum sollten die geändert werden, nur um Festkommaarithmetik ausnutzen zu können. Man hat doch angenehme Fließkommaarithmetik. Berechne doch mal die Kraft, mit der sich Sonne und Erde anziehen. Da hast Du irgendwo das Produkt der beiden Massen und das ist etwa 10^55kg². Warum sollte man sich bei so einer harmlosen Rechnung überlegen müssen, dass man die Einheit kg nicht nehmen kann, weil eine 128 Bit Ganzzahl so große Zahlen nicht darstellen kann. Das wäre doch ein echter Rückschritt.
Wie das Programm das intern in Integer macht kann dem Anwender doch egal sein.
Der gibt seine 55 kg ein und fertig.Genauso wie du beim Euro deine 2,50 € eingibst obwohl das Programm intern in Cent rechnet.
-
Integer vs. Double schrieb:
Wie das Programm das intern in Integer macht kann dem Anwender doch egal sein.
Der gibt seine 55 kg ein und fertig.Einer muss es ja programmieren.
-
Wie baust du einen Taschenrechner, bei dem du nicht vorher sagen kannst, mit welchen Größenordnungen du zu rechnen hast. Dann müsstest du bei jeder weiteren eingegebenen Zahl und bei jedem Rechenschritt prüfen, ob deine Skalierung noch passt. Ganz schön umständlich, wo du doch eigentlich nur die Funktionsweise der Fließkommazahlen nachbaust.
-
Fließkomma ist doch nix anderes als festkomma mit ner variablen 10er potenz
.
Und wenn das komma "im sinne" immer nach der ersten ziffer stellst,... naja,...Die frage sollte eigentlich lauten:
Warum gibt es noch keine handelsüblichen ALU's mit achtfacher genauigkeit ?grüße
-
Bashar schrieb:
Integer vs. Double schrieb:
Außerdem rechnet Int genau, double tut das nicht.
3/2 == 1
3.0/2.0 == 1.5
Wenn das deine Vorstellung von Genauigkeit ist ...naja, wenn man 3 durch 2 teilt, bleibt ein rest 1. Eins geteilt durch 2 geht nicht, also rechnet man 10 geteilt durch 2...
also in asm.......:)
(arme 8bit-Welt, konnte immer nur mit Zahlen bis 255 bwz +127 oder -127 rechnen...;))
-
Selbst bei der besten realistisch machbaren fixed point Arithmetik ist dein Wertebereich winzig gegenüber Fließkommazahlen. Oftmals hat man eben Rechnungen in denen sehr kleine und sehr große Zahlen gleichzeitig vorkommen oder man eben nicht vorher weiß, in welcher Größenordnung das Ergebnis liegt. Einfaches Beispiel: Zeichne ein Diagramm von 1/x in logarithmischen Skalen. Hier will ich mal sehen wie du das ohne Fließkomma löst.
-
zeusosc schrieb:
Die frage sollte eigentlich lauten:
Warum gibt es noch keine handelsüblichen ALU's mit achtfacher genauigkeit ?Manchmal ist vierfache Genauigkeit eben genau genug. Und mit manchmal meine ich immer.
-
schonwiedarausgeflogngrrr schrieb:
(arme 8bit-Welt, konnte immer nur mit Zahlen bis 255 bwz +127 oder -127 rechnen...;))
ganz so schlimm wars nicht, in 8 Bit kommt man (mit 2er Komplement Darstellung) von +127 bis -128
-
übrigens:
ob man mit Fix- oder Fließpunkt auskommt, hängt sehr von der Anwendung ab - auch 4-fach genaue Fließpunkt-Arithmetik reicht nie für alle Zwecke aus, ebenso wenig wie 8- oder 65536-fach genaue.
In der Zahlentheorie beispielsweise wäre jeder Rundungsfehler fatal, und die Zahlen können riesig sein. Dort ist es ein gewaltiger Unterschied, ob man beweisen kann, daß eine Zahl gleich 2.00000.....000000004839276123 ist oder exakt 2.
Dafür reicht dann weder Fix- noch Fließpunkt, man braucht Arithmetik mit beliebiger Genauigkeit wie bignums. Eine ALU, die so was kann, wäre mal hübsch.
-
!rr!rr_. schrieb:
Dafür reicht dann weder Fix- noch Fließpunkt, man braucht Arithmetik mit beliebiger Genauigkeit wie bignums. Eine ALU, die so was kann, wäre mal hübsch.
Na, wie soll die denn zum Beispiel 1./3.0 berechnen? Irgendwann ist der Speicher voll...
-
edit: nix
-
otze schrieb:
Na, wie soll die denn zum Beispiel 1./3.0 berechnen? Irgendwann ist der Speicher voll...
na indem rationale Zahlen vollständig gekürzt gespeichert werden. 1./3.0 wird gespeichert als 1/3, 2/10 dagegen wird gespeichert als 1/5. "Rationale Arithmetik" heißt dann "Bruchrechnung".
Diese Arithmetik mit beliebiger Genauigkeit ist schon in manchen Programmiersprachen eingebaut, in manchen seit Jahrzehnten, also ein alter Hut,
auch für C++ gibt es Bibliotheken dafür, und letztendlich unvermeidlich, falls Rundungsfehler inakzeptabel sind wie in der Zahlentheorie.
