spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »BlueCobold«

Zitat von »Spiele Programmierer«

Mit 64Bit Werten wie ich sie heute verwenden würde, kaum noch. Bei einer Genauigkeit von einem Nanometer, würde der Wertebereich für bis zu 18 446 744km Abstand reichen. Das reicht locker, als das von der Erde aus, auch noch der Mond mit in den Wertebereich passt.

Ich glaube da unterliegst Du einem Irrtum. Wenn Du Abstände zwischen Mond und Erde korrekt modellierst, wirst Du feststellen, dass sich Nanometer eben nicht mehr bestimmen lassen. Sogar mit Zentimetern wird es dann schon problematisch. Double kann zwar große Wertebereiche abdecken, aber die Genauigkeit ist relativ zum absoluten Wert des Doubles. Große Zahlen führen dazu, dass Nachkommastellen oder sogar die unteren Stellen vor dem Komma nicht mehr dargestellt werden können. Bei Double sind das in etwa 15 Stellen. Da wird bei den 18.446.744km nix mehr die Nanometer aufzulösen, die stolze 20 Stellen bräuchten.

Ich denke, er bezieht sich auf 64-Bit-Festkommazahlen. Aber auch da bringt das nichts: Möchte man die Länge eines Vektors, der sich über so eine Distanz erstreckt, berechnen, muss man die 18 Millionen km zum Quadrat nehmen. Dann hat man eine Präzision von 36 Metern (besser als mit double, das dann auf einen Kilometer aufgelöst wäre, aber immernoch etliche Bits von Nanometern entfernt).

Ich erinnere mich, dass ich beim Testen eines 40 km langen Strahls gegen ein 4×4 km großes Raster schon an 63 Bits gekratzt habe. Die Bits schwinden halt eben unglaublich schnell.

Ich denke dass man sich auf float und double beschränken kann. Int sehe ich nicht als Sinnvoll, das ist bei 2D schon viel zu ungenau wenn es um Kollisionen mit zeitbasierten Bewegungen geht. Ich habe es immer versucht mit int und Kollisionen und bin dann immer auf float umgestiegen, weil das einfach besser funktioniert. Man spart sich das ständige gecaste von float-Positionen nach Int-Kollisionsrechtecken und ermittelten int-Kontaktpunkten nach float-Positionen zurück. Nervt mich persönlich ziemlich.

Zitat von »Krishty«

Möchte man die Länge eines Vektors, der sich über so eine Distanz erstreckt, berechnen, muss man die 18 Millionen km zum Quadrat nehmen.

Ich vermute die FPU rechnet nur bei Fließkommazahlen mit vierfacher (also intern 128 Bits) Genauigkeit - Festkomma kann sie ja außer bei SSE/Konsorten ja eigentlich gar nicht? Oder wie sehen da die aktuellen Generationen aus? Ich bin da schon eine ganze Weile nicht mehr groß interessiert dran (eigentlich ging an mir alles nach SSE 1 vorbei). Wenn ich Recht habe, dann hat man mit Fixkomma natürlich ziemlich schnell verloren, wie Du ja auch schon sagst. Allerdings dürfte eine Längen-Berechnung auf der FPU mit 64-Bit-Fließkomma doch ziemlich genau ausfallen wegen der internen Vergrößerung des Wertebereichs auf 128 Bit. Oder nicht? Und selbst wenn nicht, sehe ich da kein Problem, da die Multiplikation und Wurzel ja eigentlich numerisch stabil ist. Damit müsste man doch eigentlich immer gut eine Länge berechnen können. Mehrere Vektoren zu addieren hingegen stellen wohl eher ein Problem gerade bei iterativen System wie Physik-Engines dar. Die würden da ganz schnell nur noch Mist ausrechnen. Ich lasse mich hier gern korrigieren, sehe nämlich das Problem nicht. Box2D rechnet allerdings beispielsweise schon bei sehr kleinen Werte-Spannen schnell nur noch Quatsch aus (Welt der Größe 100x100 Metern lässt oft schon kaum noch Zentimeter-Werte sinnvoll erscheinen).

CPUs (meintest du die?) rechnen intern nicht mit 128 Bits pro Zahl, sondern mit 128 Bit für den gesamten Vektor – also 4 Komponenten à 32 Bits oder 2 à 64 Bits. Mit dem neuen AVX-Befehlssatz gibt es 256 Bits breite Register für 8×32 Bits oder 4×64 Bits. GPUs rechnen superskalar mit einzelnen 32- und 64-Bit-Werten. In jedem Fall bleibt die Präzision auf 32 oder 64 Bits beschränkt; 128-Bit-Rechnung gibt es nicht (mit Ausnahme der 128-Bit-Integer-Multiplikation und -Division auf x86-64-CPUs, die aber auch nicht weiterhilft).

Wer nicht auf Bignum-Bibliotheken umsteigen will, bleibt also erstmal auf 64 Bits beschränkt.

Nein, ich meinte eigentlich FPUs (und damit heutige CPUs, da das alles eins ist). Das Ergebnis der Multiplikation zweier 64-Bit-Operanden sollte intern doch auf 128 Bit erweitert ausgerechnet werden. Klar, nach der Quadrierung geht nach dem "Runterrechnen" auf 64 Bit erst mal wieder was verloren, das sollte doch die nachfolgende Wurzel aber wieder ausgeglichen werden. Nicht vollständig, das ist wohl richtig. Aber die relative Anzahl Stellen (und damit die relative Genauigkeit) sollte identisch bleiben. Multiplikation und Division ist eben numerisch stabil, Strichrechnung ist instabil. Die 15 signifikanten Stellen sollten eigentlich erhalten bleiben. Mir ist nicht ganz klar, wo da bei der Längenberechnung mit Fließkomma ein Problem besteht. Bei Fixkomma ganz sicher. Das habe ich aber auch nicht angezweifelt.

Zitat von »BlueCobold«

Nein, ich meinte eigentlich FPUs (und damit heutige CPUs, da das alles eins ist). Das Ergebnis der Multiplikation zweier 64-Bit-Operanden sollte intern doch auf 128 Bit erweitert ausgerechnet werden.

Nope, wir reden hier ja von Gleitkommazahlen und nicht einfachen Integern. Du brauchst in diesem Fall nur die vordersten 64 Stellen der neuen Mantisse; vom Rest interessiert nur die Anzahl der Stellen für den neuen Exponenten, nicht aber, was genau für Werte die haben...

Naja; FPUs haben intern mit 80 Bits gearbeitet. Die Rundung am Ende bedeutete aber mehr Schmerz als Gewinn (cos(a) != cos(a)). Auf 64-Bit-CPUs gibt es keine FPU mehr und aktuelle Compiler nutzen auch in 32-Bit-Versionen SSE statt der FPU, falls sie können.

Oha. Da hat sich ja doch eine ganze schöne Diskrepanz zwischen meinem Wissen und dem aktuellen Stand gebildet.

@dot: Das stimmt. Aber höhere Genauigkeit gab es intern. Gut, es waren nur 80 Bit und nicht 128, aber völliger Unfug war meine Aussage dann nicht.

Da Ihr beide meine eigentliche Frage aber übersehen habt, ich sehe selbst, wo das Problem bei der Längen-Berechnung liegt. Das Problem ist weder das Quadrat, noch die Wurzel, sondern natürlich die Addition aller Achsen, die ich komplett vergessen hatte. Sind alle Werte ähnlich groß, ist auch die berechnete Länge sehr genau. Ist eine Komponente aber sehr klein im Vergleich zu den anderen, so wird die berechnete Länge in etwa um diese Größe verfälscht. Also Beispielsweise die Berechnung der Länge des Vektors von (0,0,0) zu (100.000.000,100,0) wird Grütze liefern, da 100^2 im Vergleich zu 10^(8*2) viel zu klein ist und bei der Addition unter den Tisch fällt, womit angeblich eine Länge von 100.000.000 berechnet wird. Das ist aber offensichtlich falsch, wenn auch nur sehr gering. Wo da jetzt aber 6km verloren gehen, sehe ich bei Fließkomma irgendwie nicht