Wozu braucht man noch float und double?
-
Wenn man heute in 64 Bit bzw. 128 Bit Integer fast jede Rechnung reinpacken kann und dann z.b. bei Physik für die Sekunde als Einheit die Pikosekunde nimmt,
dann kann man damit immer noch:(264-1)*10-9 = 18446744073.71 Sekunden darstellen.
Das entspricht 5124095 h bzw. 213503 Tage bzw. 584 Jahre.Wozu braucht man da noch double?
Da kann man ja gleich alles in großen 64 bittigem Integers rechnen und nur darauf achten die Einheit klein zu machen oder entsprechend am Ende bei der Ergebnisausgabe das Komma verschieben.
Außerdem rechnet Int genau, double tut das nicht.
Und schneller wäre es vermutlich auch noch.Wozu also noch double und Co?
PS: In der Frage ignorieren wir mal, daß es Bibliotheken und Hardware wie OpenGL & Grafikkarten gibt, die double Werte erwarten.
Die Fragestellung bezieht sich allein auf normalen CPUs berechnete Anwendungen
und von der Prämisse, daß man alle Bibliotheken selber schreibt oder entsprechende Bibliotheken findet, die mit Integer rechnen.
-
Auf eine 2 Meter hohe Latte soll eine weitere Latte mit einem Winkel von 32° zum Boden aufgelegt werden. Wie lang muß diese weitere Latte sein?
-
Wieviel ist Null durch Null?
-
mngbd schrieb:
Wieviel ist Null durch Null?
∞ (laut tangens und arcustangens
)
-
X.DarkForce.X schrieb:
mngbd schrieb:
Wieviel ist Null durch Null?
∞ (laut tangens und arcustangens
)Nö, das ist ganz klar 37, weil mit $$0 * 37 = 0$$ die Probe stimmt.
-
Jaja, genug, man sollte Witze nicht überstrapazieren. Ich wollte den Thread nicht sprengen, sondern ein Beispiel geben, wo die Rechnung mit double komfortabel ist.
Wer schon mal Sinus-/Cosinus mit Fixkomma-Arithmetik rechnen mußte weiß nämlich, wie spaßig das ist... (z.B. FFT auf DSP in Assembler).
-
Marc++us schrieb:
Auf eine 2 Meter hohe Latte soll eine weitere Latte mit einem Winkel von 32° zum Boden aufgelegt werden. Wie lang muß diese weitere Latte sein?
Wieso sollte das nicht gehen?
Einfach den Winkel in integer umrechnen also Komma verschieben
und anschließend entsprechend als Teiler verwenden.Bsp.
int a = 2000; // meine 2 m in mm
int w = 32; // Winkel von 32°
int wbig; //umgerechneter wbig int
sin(w); // meine Integerkonforme Sinusfunktion die auf 9 Stellen genau den Wert nach dem Komma zurückliefert z.B. 766044443.a = a / (a / wbig); // Komma verschieben muß natürlich noch angepaßt werden. Usw.
-
mngbd schrieb:
Wieviel ist Null durch Null?
Du darfst nicht durch 0 teilen. basta
-
Marc++us schrieb:
Jaja, genug, man sollte Witze nicht überstrapazieren. Ich wollte den Thread nicht sprengen
Ich auch nicht. Fixkomma-Trigonometrie hab ich nie versucht, aber die über die Unendlichkeiten und NaN's von IEEE 754 hab ich mich schon manchmal gefreut.
-
Integer vs. Double schrieb:
und nur darauf achten die Einheit klein zu machen oder entsprechend am Ende bei der Ergebnisausgabe das Komma verschieben.
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.
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 ...
-
Marc++us schrieb:
Wer schon mal Sinus-/Cosinus mit Fixkomma-Arithmetik rechnen mußte weiß nämlich, wie spaßig das ist... (z.B. FFT auf DSP in Assembler).
Naja, da schreibt man einfach einmal ne Sin oder Cos Funktion und dann sollte die für immer verwendbar sein und das gewollte Funktionieren.
-
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 ...Das ist genau, weil du ja viel kleinere Einheiten nimmst.
Aus deinen 3 m und 2 m rechnest du ja in Nanometer und erhälst dann entsprechend am Ende eine 1500.....
Dann noch richtig ausgeben, um das Nanometer wieder wegzukriegen und schon hast du 1,5 wie es sein sollte.
-
Der Rest meines Postings war eigentlich wichtiger.
-
D.h. selbst wenn du so winzige Größen wie die Planklänge hast, dann machste daraus halt eine gedachte noch kleinere Länge als die Planklänge.
Sagen wir mal fiktiveinheit bzw. fm "Fiktivmeter" und schon kannst du sogar mit Planlängen genau rechnen.
Wobei sich ne Planklänge wohl sowieso nicht teilen dürfte, da kannst du also die Planklänge selbst als Atomic Größeneinheit nehmen.
-
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.