View Full Version : FREE RPG Extender H für aufrunden
loeweadolf
03-11-04, 12:00
Hallo Birgitta,
noch mal eine Frage zum alten Thema:
Definiert die Angabe der Dezimalstellen beim %decH die Größe des internen Rechenfeldes ?
Bei der Built-in-Funktion %DecH können die Länge und die Anzahl der Dezimal-Stellen angegeben werden. (Parameter 2/3)
Dies ist gerade bei komplexen Rechenoperationen sinnvoll,
da intern mit Gleit-Komma gerechnet wird.
Die Parameter können als Variable verwendet werden.
Allerdings muss das Format zur Compile-Zeit bekannt sein.
Am besten hinterlegt man eine Konstante:
Länge: Const(%Size(RefFeld))
Anzahl Dezimalstellen: Const(%DecPos(RefFeld)
Birgitta
mfg. Ludger
Nur die Größe des Endergebnisses. Intern wird mit Fließkomma gerechnet.
loeweadolf
03-11-04, 12:22
Nur die Größe des Endergebnisses. Intern wird mit Fließkomma gerechnet.
Dann verstehe ich nicht, warum Dezimalstellen im %decH angegeben werde müssen, da diese doch bereits durch die Angabe des Ergebnisfeldes definiert sind.
??
mfg. Ludger
Dann verstehe ich nicht, warum Dezimalstellen im %decH angegeben werde müssen, da diese doch bereits durch die Angabe des Ergebnisfeldes definiert sind.
??
mfg. Ludger
Du kannst aber auch Built-in-Funktionen dazu benutzen, um innerhalb einer Formel zu runden.
Oder aber Dein Standard-Feld ist zwar 15,5 aber es sollen nur 2 Nachkommastellen ausgewiesen werden.
Birgitta
loeweadolf
03-11-04, 12:52
Du kannst aber auch Built-in-Funktionen dazu benutzen, um innerhalb einer Formel zu runden.
Oder aber Dein Standard-Feld ist zwar 15,5 aber es sollen nur 2 Nachkommastellen ausgewiesen werden.
Birgitta
Aha,
ist denn immer gewährleistet, dass bei der interne Rechnung
die internen Rechenfelder eine ausreichende Größe haben ?
mfg. Ludger
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
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.php?t=5009&highlight=Zwischenergebnis
loeweadolf
03-11-04, 14:03
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.php?t=5009&highlight=Zwischenergebnis
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
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.
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