Definitionsbereich des Datentyp Real?

[Poison Nuke]

HI,
Ich hoffe, meine vielen Pascalfragen nerven ned :rolleyes:

Ich will eine Function erstellen, die eine Realzahl einliest (ähnlich der Stringeinlesefunction von mir).

Meine Frage: Wieviele Vorkomma und Nachkommastellen kann Real aufnehmen??? Denn ich habe bisher keine eindeutige Definition davon gefunden, die mir hilft.

Muss ich sonst noch was beachten bei Real, wenn ich so eine Function erstellen will???

[Felix Kaiser]

Afaik 8 Nachkommastellen, ideal wäre der Typ Extended, 80 Bit, da gehen 15 Nachkommastelle und 12 vorm Komma, wenn ich mich jetzt nicht täusche. Irgendwo stands jedenfalls, weiß aber nicht mehr wo. Kann man sich aber meist auch denken anhand der Bitgröße eines Typs. Wenn ich mich jetzt nicht irre kann die Anzahl auch variieren, je nach Tiefe der Zahl. Nimm die Zahl 1, du kannst diese sehr oft durch 10 Teilen, da er den Exponenten mit verrechnet und zählt. Ist jedenfalls relativ komplex, keine Ahnung wie genau das FPU da arbeitet.

[Diogenes]

Original geschrieben von Poison Nuke
HI,
Ich hoffe, meine vielen Pascalfragen nerven ned :rolleyes:


Dafür ist das Board da. Wenn hier was nervt :mauer: , dann ich mich selbst. ;)

Zum Thema:

Im Prinzip kann man beliebig viele Nachkommastellen bei einer Eingabe reinstopfen - es wird nur, wie Felix oben gezeigt hat, eine Genauigkeitsgrenze geben.

Das Hauptproblem ist allerdings die "Kapazität" einer Real-Variable. Wenn diese Variable tatsächlich vom Typ Real ist, dann ist die wird bei Abs( Variable) > 1e38 ein Überlauf/Overflow ausgelöst. Bei dem von Felix erwähnten Typ Extended ist die Grenze bei etwa 1e4932 erreicht.

Es gibt noch die Typen Single, Double und Comp. Letztere ist ein Integer-Typ, der vom Mathe-Prozessor verwaltet wird demnach eine Real-Variable honoris causa ist.

Weiteres steht in der Hilfe, dem Referenzhandbuch oder dem Programmierhandbucgh unter den oben fett gesetzten Begriffen.

Have a nice Byte!

[Poison Nuke]

thx ihr beiden, für eure antworten.

wie es scheint, kann ich einfach soviele Stellen eingeben lassen, wie es mir beliebt. Real wird dann schon die übermäßigen Stellen abschneiden.

Aber leider steht in der Hilfe auch nicht viel.
Lediglich, das Real in diesem Bereich definiert ist:
2,9e-38...1,7e38.

Aber des hilft mir nich viel. Oder soll das heißen, das Real immer nur max. 38 Stellen aufnehmen kann, egal an welcher Stelle das Komma ist????

[Diogenes]

Original geschrieben von Poison Nuke
wie es scheint, kann ich einfach soviele Stellen eingeben lassen, wie es mir beliebt. Real wird dann schon die übermäßigen Stellen abschneiden.


Genau das kann man. Beschränke, wenn's geht, die Eingabe jedoch auf 20 Nachkommastellen, den mehr hat absolut keinen Sinn.

Original geschrieben von Poison Nuke
Aber leider steht in der Hilfe auch nicht viel.
Lediglich, das Real in diesem Bereich definiert ist:
2,9e-38...1,7e38.

Aber des hilft mir nich viel. Oder soll das heißen, das Real immer nur max. 38 Stellen aufnehmen kann, egal an welcher Stelle das Komma ist???? [/B]
Das heißt, daß der Absolutwert der Zahl in diesem Bereich liegen muß. wenn sie 2.9e-38 unterschreitet, wird das in 0 umgewandelt. Wenn das 1.7e+38 überschreitet, gibt's einen Datenüberlauf (Overflow error).
Probier einmal folgendes:

program Overflow;

var
a: Real;

begin
a := 1;
repeat
WriteLn( a);
a := a * 10;
until a = 0; {Weil's eh vorher abbricht}
end;

Die letzte ausgegebene Zahl müßte 1.000e38 oder so ähnlich sein. Dann kommt eine Fehlermeldung.

Wenn du die Mulitplikation mit 10 durch eine division durch 10 ersetzt, müßte die letzte ausgegebene Zahl 0 sein.

Ich denke, Du wirst dann verstehen, was ich meine.

[Poison Nuke]

ok, thx

ich hab es mal getestet.

Aber woher kommt bitte diese ungenauigkeit bei Real???
Denn ich habe z.B. mal a:=1e37 gemacht und habe es ausgeben lassen, aber es kam was bei 9.9999992347e36 raus.

[Diogenes]

Das sind Rundungsfehler. Die Zahle wird intern geteilt in Mantisee und Exponent, sodaß Zahl = Mantisse * 2 ^Exponent. Sowohl Mantisse als auch Exponent sind Binärzahlen und Exponent ist eine "Integer"-Zahl. Das Dumme dabei ist, daß 0.1 im binären Zahlensystem eine periodische Zahl ist. da müssen Rundungsfehler komen... :(

[Poison Nuke]

nagut, also sollte man sich beim berechnen von Nachkommazahlen nicht 100% verlassen.

Nur das macht sich irgentwie unpraktisch, beim berechnen längerer Algotihmen, wenn man da einige Zahlen vergleichen muss....ohje. :(

Obwohl ich noch nie solche genauen Zahlen vergleichen musste (außer in einem Testproc, wo nat. nix mehr stimmte), aber man weiß ja nie, wann man des wieder braucht.

[Diogenes]

Ich verwende normalerweise den Trick, die zu vergleichenden Zahlen weiter hinunter zu runden, bevor ich vergleiche: Das mache ich aben nur, wenn ich keine Näherungen berechne, denn dort gehe ich einfach her, zu prüfen, ob Abs( Wert1 - Wert2) < GenauigkeitsGrenze gilt.