DOOM III mit Framebremse ?
-
Hi
aber beide haben 5 ziffern uns sind somit auf 5 dezimalstellen geanu. egal wo bei flot das komma steht das ist nu mal bei flot egal.
Bei flieskomma zahlen ist der interne aufbau für die genauigkeit entscheident.
1234.5 wird in 1.2345 * 10^3 dargestellt und
1.2345 wird in 1.2345 * 10^0 dargestellt.und wo ist nun bitte genauer 1.2345 (*10^4) oder 1.2345 (*10^0) ?
auserdem jester. du vergleicht gerade zwei verschiedene sachen. einmal die beiden 5 stelligen zahlen. und einmal den kleinsten Wert den sie darstellen können. (wird glaub ich auch als maximaler Fehler bezeichnet)
beide zahlen können bei 5 Dezimalstellen maximal 10000 verschieden Werte annehmen. Egal wo das Komma steht. Damit haben beide Zahlen eine Genauigkeit von 1/100.000 auf ihren Wertebereich. der eine geht von 9.9999 bis 0.0000 der ander von 9999.9 bis 0.0
ok man kann nun die genauigkeit auf einen absoluten Wert umrechnen der wie du richtigt sagst 0.1 oder 0.00001 ist. und 0.00001 ist besser als 0.1 nur kann man bei einer kleinen absoluten Wert keine grossen zahlen darstellen.
versuch nun mal mit 5 dezimalziffern und 4 nachkommastellen auf 1.2345 sagen wir mal 8.7656 drauf zu addieren. sollte 10.0001 ergeben. was leider laut definition nicht mehr darstellbar ist. Entweder oben oder unten eine 1 wechlassen. was ist besser ?
gruss Termite
-
ihr streitet euch um 2 verschiedene dinge.
1. genauigkeit von float, die ist immer gleich da standard
2. rechengenauigkeit wenn man mit float arbeitet. das hängt von der fpu und dem verwendetem code ab, wenn man da pech hat, dann gibt es abweichungen die weit größer sind als man von float erwarten würde einfach weil die verwendete fpu anders arbeitet.
rapso->greets();
-
Termite schrieb:
@ Trienco beides ist gleich genau, da die genauigkeit von der anzahl der Ziffern der Mantisse abhängig ist und nicht von der grösse ( was dem exponenten gleichkommen würde).
aber auch nur, wenn man die genauigkeit einer zahl als die gesamtanzahl der stellen sieht. rechnen in 1/10 schritten wird wohl kaum jemand ernsthaft als besonders genau bezeichnen, denn in dem moment ist es mir schnurz, ob vor dem komma 1 oder 8 stellen stehen.
und übrigens wer rechnet mit zahlen mit über 300 oder 4900 Stellen (egal ob vor oder nach dem Komma)? nicht mal Physiker. Somit sind double und long double total neben der realität.
bitte was? mit 23bit mantisse komme ich maximal auf was, 8.388.607? das sind lächerliche sieben stellen und wenn die mal nicht zufällig aufeinanderfolgen haben floats ausgeschissen. 20000,001? hoppla, da bekommt mein weltraum spiel aber recht ruckelige positionswechsel, wenn ich nicht zusätzlich trickse und naiv die position als float speichere, denn allein so ein sonnensystem hat ja gerne mal 10.000mio km durchmesser und die position wird ja dann doch eher mindestens in m gerechnet. 10.000.000.000.000m ? ich glaube der float bröckelt grade ein wenig bei einem exp von 14 und einer schrittweite von entsprechend 10km. ein double kommt auf 15 stellen und siehe da, wir brauchen sogar nur 14 und kommen locker aus oder können in dezimeter rechnen ohne uns nen kopf zu machen. natürlich könnte man auch gleich nen 64bit integer nehmen und in mm rechnen ,-)
daß uns das rendern am ende um die ohren fliegt, weil die karten mit floats rechnen ist eine andere sache.
ein fehler war trotzdem drin, die genauigkeit von float ist zur 0 hin besser, nicht für kleine zahlen.
-
Trienco schrieb:
eher umgekehrt, floats werden genauer je kleiner die werte sind:
1,2345
1234,5
was ist genauer?sorgen gibts erst, wenn wirklich mal 0,0000000001 rauskommen würde und ein float daraus 0 macht
Ist schon klar...
Bye, TGGC (Der Held bei Dir!)
-
Termite schrieb:
aber beide haben 5 ziffern uns sind somit auf 5 dezimalstellen geanu.
das scheitert schon daran, daß meine definition von dezimalstelle (die ich so auch im netz finde) wohl eine andere ist, nämlich stellen _hinter_ dem komma.
-
Trienco schrieb:
Termite schrieb:
aber beide haben 5 ziffern uns sind somit auf 5 dezimalstellen geanu.
das scheitert schon daran, daß meine definition von dezimalstelle (die ich so auch im netz finde) wohl eine andere ist, nämlich stellen _hinter_ dem komma.
die stimmt auch, float hat _immer_ 23bit hinter dem komma.
rapso->greets();
-
TGGC schrieb:
Ist schon klar...
wobei mein beispiel bescheuert war, weil ein float es sogar ohne weiteres darstellen könnte. das problem taucht erst auf, wenn ich meine gesamtzeit von bisher 2 sekunden um 0.000000001 sekunden erhöhen will. ergebnis ist aber das gleiche, plötzlich steht die zeit still... schade nur, daß es in der realität nicht auch so einfach geht *fg*
-
rapso schrieb:
die stimmt auch, float hat _immer_ 23bit hinter dem komma.
nicht ganz, die mantisse vielleicht, aber wenn der exp dazwischenpfuscht hab ich am ende sogar vor dem komma erstmal lange nichts *g* das ekelhaft an floats ist ja grade die ungleichmäßige verteilung. solange sich alles auf kleinem raum abspielt ist das ding super, aber wenn ich einen großen raum abdecken will gibts ärger (wieso muß ich grade an den z-buffer denken, der grundsätzlich zu wenig genauigkeit hat? *fg*)
-
Trienco schrieb:
rapso schrieb:
die stimmt auch, float hat _immer_ 23bit hinter dem komma.
nicht ganz
leider schon, per definition ist es so.
_eins_ _komma_ _23bitnachkomma_ * _2^8bit_, somit ist bei float die genauigkeit immer gleich, weshalb auch eure beispiele von z.b. 1,2345 nicht darstellbar sind, lediglich 1.2345001. dass ihr euch als menschen ersparrt irgendwelche unnötigen stellen zu schreiben, heißt nicht, dass sie in der float-variable nicht drinn stehen. float ist immer gleich genau. berechnungen sind natürlich nicht gleich genau, das hängt von den beiden float-werten ab.
und da wäre ich auch schon bei meinem vorherigen posting. berechnungen mit floats sind dann natürlich was ganz anderes als die genauigkeit von float.
das ist ja aber das bei dem ihr aneinander vorbeilabert... (wozu muss ich mich eigentlich wiederhollen?
)
wenn ihr es nicht schafft den standpunkt des anderen zu sehen, werdet ihr an diesem definitions-auslegungs-problem ewig kauen.
rapso->greets();
-
Play it again, rapso.
Bye, TGGC (Der Held bei Dir!)