in anderen Sprachen teilweise die Floats den Doubles entsprechen. Aber
Single kommt wohl wegen .s nicht mehr in Frage
f.f=0.000000000000000006 : Debug f
-
ts-soft
- Beiträge: 22292
- Registriert: 08.09.2004 00:57
- Computerausstattung: Mainboard: MSI 970A-G43
CPU: AMD FX-6300 Six-Core Processor
GraKa: GeForce GTX 750 Ti, 2 GB
Memory: 16 GB DDR3-1600 - Dual Channel - Wohnort: Berlin
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
in anderen Sprachen teilweise die Floats den Doubles entsprechen. Aber
Single kommt wohl wegen .s nicht mehr in Frage
PureBasic 5.73 LTS | SpiderBasic 2.30 | Windows 10 Pro (x64) | Linux Mint 20.1 (x64)
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
Nutella hat nur sehr wenig Vitamine. Deswegen muss man davon relativ viel essen.
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
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.)
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.)
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
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.
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.
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
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.
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...
ZeHa hat bisher kein Danke erhalten.
Klicke hier, wenn Du wissen möchtest, woran ihm das vorbeigeht.
-
Kaeru Gaman
- Beiträge: 17389
- Registriert: 10.11.2004 03:22
> 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
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
Der Narr denkt er sei ein weiser Mann.
Der Weise weiß, dass er ein Narr ist.
Der Weise weiß, dass er ein Narr ist.
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.
@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.