Hallo,

In einem meiner Projekte habe ich folgende Zuweisung:

scale ist vom Typ Extended, ansonsten sind alles Integers.
Um das unten beschriebene Problem zu umgehen, könnte ich die hintere Klammer auflösen und die entstehenden Divisionen ggf. etwas nach vorne ziehen (vielleicht auch die vordere Klammer (locX + shift) ausmultiplizieren). Wie gehe ich dabei vor, damit der Wert für x möglichst Stabil ist, d.h. damit er für möglichst viele Variablenbelegungen möglichst nahe am richtigen Ergebnis liegt?

Ich nehme an, dass für Überlauf-Stabilität die Zwischenergebnisse möglichst nahe an 1 liegen sollten (Exponent), ich für Genauigkeit aber möglichst viele der Zwischenergebnisse in Integer-Typen halten will (Mantisse), korrekt?




Auch wird hier spekuliert, dass die Zwischenergebnisse eine reduzierte Genauigkeit haben (statt einer erhöhten )

Zum Effekt:
Obwohl alle Variablen positiv sind, ist das Ergebnis negativ



Wenn ich diese Werte im Quelltext für die Variablen einsetze (x := Trunc(  (507 + 4578) * 300 * 1408 / ( 1408 * 1500 * 7.05219818923083 )  );, erhalte ich vom Compiler:


lg,
Daniel

Hidden hat folgendes geschrieben :

9818923083 )[/code] Wenn ich diese Werte im Quelltext für die Variablen einsetze (x := Trunc(  (507 + 4578) * 300 * 1408 / ( 1408 * 1500 * 7.05219818923083 )  );, erhalte ich vom Compiler: markieren Quelltext     1: [DCC Error] frmMain.pas(494): E2099 Overflow in conversion or arithmetic operation

Dein Compiler hat ja auch völlig recht, denn (507 + 4578) * 300 * 1408 = 2147904000 > MaxLongint. Dieser Ausdruck wird ja in Integer-Arithmetik berechnet und führt zum Überlauf. Bei diesen mikrigen Zahlen (und ohne Subtraktionen) braucht man sich nicht um Termumformungen und Statibilität zusorgen, wenn man die richtigen Datenrepresentationen verwendet: Entweder eine Deiner Konstanten als Float schreiben, zB 1408.0, oder eine temporäre extended Variable verwenden.
wobei eventuell je nach Datentypen und Wertebereich auch w * FullW * scale überlaufen kann, am sichersten wäre dann etwas wie

Der volle Divisor (also w * FullW * scale) sollte nicht überlaufen, besonders da scale bereits extended ist.

Gammatester hat folgendes geschrieben :

Edit: Mist - Statt edit auf Antwort geklickt, kann mit vorherigem Beitrag verschmolzen werden.

habe ebenfalls 1 Minute nach Thread-Erstellung den Komplett-Quote zwecks Löschen gemeldet, den ich statt eines Edits gemacht hatte

Edit: Das hier ist, wie man es wahrscheinlich in den meißten Fällen machen sollte (iirc)

Hidden hat folgendes geschrieben :

markieren Zwischenergebnisse nahe an 1 halten:     1: x := Trunc(  (locX + shift) * FieldW / FullW * BufW / w / scale )  );

Langweilige Info zuerst: wenn man alles in Extended rechnet, funktionierts.

In Delphi bestimmt immer der erste Ausdruck einer Kette, in welchen Typ der Compiler das zusammenfasst. Hier also die 507. Was hilft:


Mit Variablen wäre z.b. das eine Lösung:

Die 1.0 erzwingt dabei Fließkommaarithmetik, alles ab da passiert auf der FPU.

Oder einfach so:Es sollte auch reichen Int64 statt Integer für die Variablen zu nutzen.
Vorausgesetzt der Maximalwert von Int64 wird nicht überschritten, dann geht das natürlich so auch nicht.

Dda gibt es noch einen anderen Aspekt:

Die Reihenfolge der Berechnung und auch der "Zeitpunkt" der Typenumwandlung können von der Compilerversion und vielleicht sogar von Optimierungseinstellungen abhängen.

Wenn es also wirklich auf reproduzierbare Ergebnisse ankommt, dann sollte man alles selbst steuern, z. B. wie vorgeschlagen über Zwischenvariable. Diese Zwischenvariable würde ich sogar z. B. im PUBLIC-Teil der Klasse definieren, so dass der Compiler sie auf jeden Fall anlegen und berechnen muss. Evtl. kann man das auch mit einem Compiler-Schalter für den Code-Bereich erzwingen, dass weiß ich aber nicht.

Gruß
GuaAck

GuaAck hat folgendes geschrieben :

Diese Zwischenvariable würde ich sogar z. B. im PUBLIC-Teil der Klasse definieren, so dass der Compiler sie auf jeden Fall anlegen und berechnen muss. Evtl. kann man das auch mit einem Compiler-Schalter für den Code-Bereich erzwingen, dass weiß ich aber nicht.

Hmm, da wäre mir lieber dass andere sich beim Lesen des Programms und Verstehen der public-Variablen nicht wundern müssen.

Wenn es so kritisch wird, schaltet man vielleicht lieber Compier-Optimierungen für diese Quelltextstelle ganz aus.
Ich bin ja so wie so der Meinung, dass die kürzeste Lösung die leicht verständlichste und beste ist. Und Zwischenvariable deklarieren plus zuweisen sind schon wieder zwei Zeilen mehr*, wobei man wahrscheinlich mit einem expliziten Cast das selbe Ergebnis erhält(?).

lg,
Daniel

*Es sei denn, es erhöht bei einer langen Rechnung das Verständnis, z.B. durch mehr Übersicht oder Benennung eines Zwischenergebnisses.

Die Anzahl Zeilen im Sorcecode ist doch heutzutage mehr als nur irrelevant

Ich würds "ausführlich" - und damit richtig - programmieren und nen Kommentar dazusetzen, wieso ich so schwafelig bin