FREE RPG Extender H für aufrunden

[B.Hauser]

Aha,

ist denn immer gewährleistet, dass bei der interne Rechnung
die internen Rechenfelder eine ausreichende Größe haben ?

mfg. Ludger

Reicht Dir der Bereich zwischen ca. 2,2 *10 hoch -308 bis 1,8 *10 hoch +308?

Ungenauigkeiten kann es allerdings geben, wenn mit mehr als 16 Nachkommastellen gerechnet werden muss.

Birgitta

[Fuerchau]

Die Ungenauigkeit trifft generell bei mehr als 16 Ziffern zu.
Bei Nachkommastellen ist die Genauigkeit ggf. auch nicht die gewünschte, da Dezimale als Brüche zur 2er-Potenz gerechnet werden.
Möchte man unbedingt genaue Nachkommastellen, so sind die Zwischenergebnisse entsprechend zu berücksichtigen:
Siehe auch http://www.rlpforen.de/showthread.ph...ischenergebnis

[loeweadolf]

Die Ungenauigkeit trifft generell bei mehr als 16 Ziffern zu.
Bei Nachkommastellen ist die Genauigkeit ggf. auch nicht die gewünschte, da Dezimale als Brüche zur 2er-Potenz gerechnet werden.
Möchte man unbedingt genaue Nachkommastellen, so sind die Zwischenergebnisse entsprechend zu berücksichtigen:
Siehe auch http://www.rlpforen.de/showthread.ph...ischenergebnis

Ich habe mir den langen Roman kurz angesehen, auf den
im Link hingewiesen wird.

Das heisst doch aber:
entweder man rechnet in Einzelschritten (wie in der guten alten Zeit)
oder mann muss mit unter Umständen gewissen Ungenauigkeiten leben.


mfg. Ludger

[Fuerchau]

Eindeutig NEIN. Dies gilt im Normalfall für PC-Programme, da diese generell mit Double (also 16 Stellen) rechnen (siehe auch Excel). Man benötigt teilweise schon zusätzliche Funktionen um GENAU zu rechnen (Currency-Typ erlaubt 28 Ziffern), was von Buchhaltungsprogrammen i.d.R. auch genutzt wird.

Werden an Funktionen (Prototypen, BuiltIns) Fließkommawerte übergeben oder zurückgegeben gilt dies.
Im normalen EVAL(H) bzw EVAL(RH) mit Dezimalfeldern (gepackt/gezont) hat man diese Probleme eben nicht. Man muss halt nur bei Zwischenergebnissen aufpassen, da diese ja nach obigen Kriterien ggf. abgeschnitten werden. Also bei komplexeren Formeln lieber EVAL(RH) als enfach weglassen (Freeform).
Sobald jedoch eine einzige Fließkommavariable im Spiel ist, wird der gesamte Ausdruck in Fließkomma berechnet und dann ggf. als Decimal konvertiert.

In der H-Bestimmung gibts auch noch irgend einen Schalter der die Genauigkeit betrifft.

Was die Genauigkeit angeht kann man mit SQL (STRSQL) rumspielen, in dem man numerische Werte mal nach DOUBLE castet und dann damit rechnet.
Bei Summenbildung kommt man schon auf unterschiedliche Ergebnisse.

[loeweadolf]

Ist es denn besser, bei "normalen Werten" (gepackt/gezont) mit eval(hr) zu arbeiten als mit %decH ?

[Fuerchau]

Auf jeden Fall, da an %dec-Funktionen ja Double übergeben werden. Ausserdem, wozu den Umweg über %dec, wenn der eval(hr) verfügbar ist !
%dec dient eher dazu, aus Zeichenfeldern numerische Werte zu machen, zumal ja die Argumente 2/3 nur konstant erlaubt sind.

[loeweadolf]

Danke für die Antworten.

mfg. Ludger

[BenderD]

Hallo Ludger,

genauer gesagt: man vermeide implizite Deklarationen durch den Compiler.
Sprich: Einzelschritte und Literale vermeiden, das ist immer noch die einfachste Strategie.

mfg

Dieter Bender

Ich habe mir den langen Roman kurz angesehen, auf den
im Link hingewiesen wird.

Das heisst doch aber:
entweder man rechnet in Einzelschritten (wie in der guten alten Zeit)
oder mann muss mit unter Umständen gewissen Ungenauigkeiten leben.


mfg. Ludger