FREE RPG Extender H für aufrunden

[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