PureBoard

Eigentlich wäre es einleuchtender wenn die Floats Single heissen würden, weil
in anderen Sprachen teilweise die Floats den Doubles entsprechen. Aber
Single kommt wohl wegen .s nicht mehr in Frage

was eigentlich auch kein problem sein sollte, wenn man weiß, wovon man redet...
single und double ist sowieso willkürlich.


> Du wirst lachen, aber genau so werden sie gespeichert, nur zur Basis 2 und mit ein paar Tricks.

eben genau an der speicherung mit basis 2 liegt eine der ungenauigkeiten begründet.
der mensch denkt zur basis 10, und drückt sich in solchen zahlen aus.
die andere ungenauigkeit liegt in der anzahl der stellen die zur verfügung stehen.

wie von hardfalcon schon in anderen worten angedeutet,
zerfällt eine exponentialzahl in Vorzeichen, Mantisse und Exponent.

z.b.: 2.997925 * 10^8 (wer erkennt was es ist?)

hier ist 10 die Basis, 8 der Exponent und 2.997925 die Mantisse.
genauso aufgeteilt kann man sie jetzt auch im RAM speichern, nur das sie dazu eben in eine binärzahl umgewandelt wird.
aber bleiben wir mal bei exponential dargestellten zahlen mit Basis 10.

der exponent 8 bedeutet, dass das komma 8 stellen nach links verschoben ist,
die zahl ist also: 299792500

ein anderes beispiel wäre 6.0221 * 10^23

das wäre ausgeschrieben: 602210000000000000000000

und da wird auch deutlich, warum man überhaupt exponential-darstellung benutzt.

stellen wir uns mal nen taschenrechner vor, der 8 stellen für die Mantisse hat und 2 für den exponenten.

dann würde er unseren ersten wert oben so speichern:
29979250 08

und den zweiten:
60221000 23

wenn wir beide werte jetzt addieren wollen, kommen wir an das kernproblem.
schreiben wir die zahlen mal aus:

+602210000000000000000000
+000000000000000299792500
-----------------------------------
=602210000000000299792500

wenn ich jetzt das ergebnbis wieder in den imaginären taschenrechner packen will:
60221000 23
verschwindet der zweite wert einfach, als wäre er niemals da gewesen.

egal, wie groß ich die mantisse auch immer mache, es kann vorkommen,
dass eine zahl so groß und eine andere so klein ist, dass die ungenauigkeit
beim speichern der großen größer ist als die kleine zahl.

deswegen bevorzugen manche programmierer integerzahlen oder fixkomma.
(bei fixkomma werden integers verwendet, bei der darstellung wird ein komma eingefügt, für alle zahlen an der gleichen stelle. wenn man z.b. mit geldbeträgen rechnen will, genügen meistens 4 nachkommastellen. also rechnet man alles mit hundertstel cent, und stellt in euro dar.)

ein x86 rechnet gleitkommazahlen schon mit 80 bit genauigkeit. Java sogar it 96 bit. Die "bittigkeit" der cpu ist für die floats und doubles auch eher zweitrangig, da die fpu zwar inzwischen auf dem chip aber noch immer eine sehr seperate einheit ist.

mag ja sein, trotzdem nihiliert das nicht deine eigene aussage über die unmöglichkeit unendlicher genauigkeit in endlichen systemen.

außerdem ist es egal, mit wieviel bit die fpu rechnet, das ergebnis der rechnung wird immer in der genauigkeit der entsprechenden variable übergeben.
d.h. die fpu kann mit 1024bit rechnen, wenn mein compiler 64bit-variablen benutzt, ist die genauigkeit des ergebnisses stets auf 64bit beschränkt.

sollte auch eher eine antwort sein auf eine seite davor, wo es hieß es wären 4byte.

es wundert mich das purebasic laut hilfe nur 4 byte verwenden soll, denn ich würde denken, dass es mehr aufwand ist als einfach im nativen format der fpu register zu arbeiten.

naja, fred wird sich schon was bei gedacht haben.

GENAU DAS hat doch der Kaeru gerade erklärt?? Oder versteh ich das jetzt falsch...

> es wundert mich das purebasic laut hilfe nur 4 byte verwenden soll, denn ich würde denken, dass es mehr aufwand ist als einfach im nativen format der fpu register zu arbeiten.

vielleicht ist es "tradition"?

variablen wurden immer in grundgrößen gespeichert:
1xCPU-register-breite und 2xCPU-register-breite, manchmal auch 4xCPU-register-breite.

z.b. auf dem QBasic der 16bit systeme war eine Single 16bit-float und eine double 32bit-float.

ursache dafür ist möglicherweise der wunsch zur gleichförmigkeit bei tabellen/datensätzen:
für numerische werte kann ich 2/4/8 byte reservieren, ob der wert float oder integer ist, ist zweitrangig.

wenn ich mich nach dem nativen format der FPU-register richte, bekomme ich kompatibilitäts-probleme:
ist die FPU bei allen 32bit systemen gleich breit?
wenn nein, wie portiere ich programme sinnvoll?
etc,etcpp

> ist die FPU bei allen 32bit systemen gleich breit?
ja

nein, nur bei allen x86 basierten... pb gibt es ja auch für PPC.

@Zeha:

PB verwendet gleitkomma zahlen, keine fixkomma zahlen, also ist das keine erklärung für die 4byte oder hab ich da was falsch verstanden?

ich könnte mir höchstens vorstellen, dass fred es besser fand bei allen versionen gleich zu rechnen und dafür das kleinste vorstellbare gemeinsame format zu nutzen.