System.Frac / System.Int / Math.SimpleRoundTo - komische Ergebnisse

[Bodenseematze]

Hallo zusammen,

ich verzweifle gerade an den Methoden System.Frac und System.Int und auch an Math.SimpleRoundTo

Die liefern bei mir für manche Zahlen in meinen Augen komplett irrsinnige Werte zurück.
Woran liegt das?

Code:

var
  val  : Extended;
  frac : Extended;
  frac2 : Extended;

Code:

  val := 22.649;
  val := val * 100;              // 2264.9 drin
  val := System.Int( val );      // 2264.0
  frac := System.Frac( val );    // 0.9
  frac2 := frac * 10.0;          // 9.0
  frac2 := System.Int( frac2 );  // Ergebnis ist 8.0 - wieso das?????
  // auch komisch: 
  frac2 := frac * 10.0           // 9.0
  frac2 := System.Frac( frac2 ); // Ergebnis ist 1.0 - wieso das?????

Ich kann mir diese Ergebnisse überhaupt nicht erklären; dass es mal durch Bit-Darstellung / Umwandlungen zu kleinen Abweichungen kommt, verstehe ich ja noch - aber so krass? :shock:

Achja, das ganze ist mit Delphi7 (ist ein Alt-Programm, muss ich leider immer noch verwenden), das dann unter Win10-x64 ausgeführt wird...


EDIT: noch ein Ergänzung: eigentlich brauche ich das ganze, um eine eigene Methode für das Runden von Nachkommastellen zu schreiben, weil die Bibliotheksfunktionen alle für mich nicht brauchbare Sachen (z.B. "Banker's rounding") machen:

Code:

  val := 22.65;
  val := Math.SimpleRoundTo( 22.65, -1 );  // erwartet hätte ich 22.7 als Ergebnis, ich bekomme aber 22.6 - warum???

Eigentlich ganz trivial: ich möchte beim runden auf eine bestimmte Nachkommastelle, dass wenn die nächste Stelle < 4 ist abrunden und wenn sie 5 oder größer ist, aufrunden.
Und zwar unabhängig davon ob die zu rundende Stelle eine gerade oder ungerade Zahl ist oder ob die gesamte Zahl positiv oder negativ ist oder ob heute schönes oder schlechtes Wetter ist...

[Olli73]

Result := trunc((aval * power(10, astellen)) + 0.5) / power(10, astellen)

Suchst du sowas?

Edith: hatte + 0.5 vergessen!

[Uwe Raabe]

Vielleicht ist hier ja was Passendes für dich dabei. Die Unit ist schon lange weit verbreitet und allgemein anerkannt.
https://github.com/vkorshun/vklib/bl...unding_JH1.pas

Gibt's sogar noch im alten Code Central: https://cc.embarcadero.com/Item/21909 (dauert nur 'ne Weile bis es lädt)

[jaenicke]

Zitat:

Zitat von Bodenseematze (Beitrag 1524382)

Achja, das ganze ist mit Delphi7 (ist ein Alt-Programm, muss ich leider immer noch verwenden), das dann unter Win10-x64 ausgeführt wird...

Ja, Delphi 7 hat einige Bugs und komische Verhaltensweisen, sowohl bei Rechenoperationen als auch bei visuellen Komponenten. Diese gehört dazu. Wenn du eine aktuellere Delphiversion verwendest, wirst du diese Ergebnisse nicht mehr bekommen.

Daher bleibt unter Delphi 7 wirklich nur eine Fremdbibliothek oder eigene Funktionen zu verwenden. Alternativ schreibst du DLLs in einer neuen Delphiversion und bindest diese ein.

[Andreas13]

Hallo Bodenseematze,
Du könntest auch die Unit AMath.pas (= Accurate floating point math unit) von unserem einstigen Gammatester (Wolfgang Ehrhardt) verwenden. Seinen umfangreichen Nachlaß mit exzellenten Routinen für präzises Rechnen findest Du entweder hier:

http://web.archive.org/web/*/wolfgang-ehrhardt.de
und auch dort:
https://github.com/maelh/www.wolfgang-ehrhardt.de

AMath.pas ersetzt komplett Delphi’s System.Math.pas und verbessert zahlreiche Fehler und Unzulänglichkeiten. Es ist kompatibel mit

"REQUIREMENTS : BP7, D2-D7/D9-D10/D12/D17-D18/D25, FPC, VP, WDOSX"

und auch mit noch neuereren Delphi-Versionen.

Ich benutze es seit vielen Jahren und bin vollkommen zufrieden damit. :-D

[Bodenseematze]

Vielen Dank für Eure Antworten - ich bin begeistert, dass man hier noch so aktiv ist :-D

Zitat:

Zitat von Olli73 (Beitrag 1524384)

Result := trunc((aval * power(10, astellen)) + 0.5) / power(10, astellen)

Sowas in der Art hatte ich bereits bei mir am Laufen - das hat durch die Umwandlung in Integer (durch das Trunc)
und wieder Rückwandeln in Extended auch einige Werte, bei denen es zu falschen Ergebnissen kam;
deswegen bin ich ja umgeschwenkt auf Frac() und Int() - die aber noch schlechtere Ergebnisse gebracht haben :pale:

Momentan habe ich eine Variante programmiert, die ist sozusagen von hinten durch's Knie...
...da ich in den Ergebnissen meiner Berechnungen maximal 4 Nachkommastellen (meistens nur zwei oder drei) brauche,
teile ich die Zahlen jetzt (in einer eigenen Klasse) in einen Vorkomma-, einen Nachkommateil auf - jeweils als 32-Bit unsigned integer plus einem Flag als Vorzeichen.
Die Extraktion der Vor- und Nachkommateile erfolgt dadurch, dass ich das per Format (mit definierten FormatSettings) in einen String schreibe und dort die Einzelteile parse (deswegen die Aussage "von hinten durch's Knie") :stupid:
Funktioniert ganz gut - ist aber eigentlich ein übler Hack...

Ich werde mir auf jeden Fall die von Euch vorgeschlagenen Code-Bibliotheken mal anschauen.


Etwas Offtopic: in dem Projekt war der ursprüngliche Code noch in Delphi5 verfasst (mit noch älteren Teilen, die noch aus Turbo Pascal für DOS-Zeiten stammen) - das habe ich inzwischen auf Delphi7 "hochgeschoben".
Ich würde das ja auch gerne auf noch neuere Delphi-Versionen bringen - aber ich denke, das wird schwierig:
- es ist natürlich noch 32-Bit Code
- es wird noch Crystal Reports v9 mit deren VCL-Wrapper verwendet (bzw. einer stark gepatchten Version)
- es sind Datenbankzugriffe enthalten, die über die BDE an eine MS-SQL Server Instanz gehen (diese ist inzwischen aktuell)
- teilweise greift Crystal Reports in den Reports auf direkt auf diese MS-SQL Server-Instanz für die Daten zu aber
- teilweise erfolgt der Austausch vom Programm an Crystal Reports auch über aufbereitete Daten, die ebenfalls über BDE an lokale Paradox-Tabellen erfolgen
Und ich denke, da ist die größte Schwierigkeit - Crystal braucht weiterhin Paradox und ich habe noch nichts gefunden, mit dem ich in Delphi (einfach) die Paradox-Zugriffe, die über die BDE gehen, ersetzen könnte, so dass die Reportdateien nicht (oder nicht wesentlich) geändert werden müssen...


Ich habe schonmal Versuche mit RAD Studio 11 Alexandria gemacht - da hat aber zum Einen nichts (mit dem Projekt) funktioniert und zum Anderen hatte ich schon beim Testen einige Abstürze der IDE (mal ganz abgesehen von der schwierigen Handhabung wg. Lizenzserver) - was mir kein gutes Gefühl vermittelt hat...

[jaenicke]

Die BDE funktioniert schon noch mit Delphi 11 (es gibt dafür einen separaten Installer im Downloadcenter). Auch Crystal Reports funktioniert noch mit neueren Delphiversionen, es gibt nur keinen neueren Wrapper mehr, so dass man die alte Unit selbst anpassen muss.

Dass das keine ideale und zukunftsgerichtete Konstellation ist, ist dir ja selbst klar. Der Umstieg von Delphi 7 erfordert aber eher aus anderen Gründen viel Arbeit. Je nachdem wie sauber zwischen PChar und PWideChar usw. getrennt wurde, ist der Umstieg auf ein Unicode-Delphi ein hoher Aufwand und birgt Risiken hinsichtlich bei der Umstellung nicht erkannter Probleme. Wir haben damals zwar den Umstieg relativ schnell geschafft, aber haben noch lange danach noch Bugs gefunden, die darauf zurückzuführen waren. Das lag aber auch an Strings, die als Bytepuffer missbraucht wurden, und ähnlichen Punkten.

Ein weiteres großes Problem war, dass in den Quelltexten oft with benutzt wurde, was bei einer solchen Umstellung die Hölle sein kann (einer der Gründe, weshalb ich dringendst von der Nutzung in neuen Quelltexten abrate).

Insofern hängt das weitere Vorgehen sehr davon ab, wie lange das Programm noch genutzt werden soll und wie wichtig es ist. Da du von "Alt-Programm" gesprochen hast, würde ich eher zur schon angesprochenen DLL-Lösung raten, sprich neue Teile in neueren Delphiversionen schreiben und in das alte Programm einklinken.

Dabei fällt mir ein, dass eine Version für ältere Delphiversionen für mein AppCentral-Projekt sinnvoll wäre, mit dem man eine solche Plugin-Situation sehr komfortabel lösen kann. Ich schreibe mir das einmal auf die ToDo-Liste.

[Incocnito]

Probier mal das Ganze mit dem Datentyp Currency.
Vielleicht ist das genau das, was du brauchst.
Ich hoffe Delphi 7 hat schon Currency als Datentyp gehabt.

Liebe Grüße
Incocnito

[himitsu]

Den Typen gibt es schon ewig.

Intern ist es einfach ein umgebogener Int64, wo die letzten 4 Dezimalstellen als Nachkommastellen benutzt werden.

[Bodenseematze]

Zitat:

Zitat von Andreas13 (Beitrag 1524395)

Du könntest auch die Unit AMath.pas (= Accurate floating point math unit) von unserem einstigen Gammatester (Wolfgang Ehrhardt) verwenden.

Ich habe mir die jetzt mal angeschaut.

Zitat:

Zitat von Andreas13 (Beitrag 1524395)

AMath.pas ersetzt komplett Delphi’s System.Math.pas und verbessert zahlreiche Fehler und Unzulänglichkeiten.

Das ist nicht so ganz richtig - es fehlen z.B. CompareValue, SimpleRoundTo und auch der "Typ" TRoundToRange - damit braucht man die System Math-Unit leider immer noch.

Außerdem kommt auch bei dieser beim Aufruf

Code:

AMath.Frac( 9.0 )

als Ergebnis

Code:

1.0

Wieso? Ich verstehe das nicht :(

Ich habe die Enterprise-Version von Delphi7 - da ist ja der Quellcode dabei, aber ich finde den Code von Frac() dort nicht...
(nur in der von SynopseRTL gepatchten Version - und dort steht "{$IFDEF NEWRTL}" drüber, was erst ab Delphi 2005 definiert ist...)

[Uwe Raabe]

Vermutlich lässt sich 9.0 nicht exakt im erforderlichen Type (Single, Double, Extended) unterbringen und es wird intern als 8.9999xxx dargestellt. Damit wird

Delphi-Quellcode:

Trunc(9.0)

zu 8 und

Delphi-Quellcode:

Frac(9.0)

zu 0.9999xxx,was wiederum als 1.0 angezeigt wird.

[Bodenseematze]

Zitat:

Zitat von Incocnito (Beitrag 1524431)

Probier mal das Ganze mit dem Datentyp Currency.

Ich dachte ursprünglich, der Typ wäre explizit für Ausgaben monetärer Art, d.h. fest mit zwei Nachkommastellen gedacht - als ich mir das jetzt mal kurz angeschaut habe, habe ich gesehen, dass ich mich irre :wink:

Muss ich mir mal genauer anschauen - Danke für den Tipp!

Zitat:

Zitat von Uwe Raabe (Beitrag 1524454)

Vermutlich lässt sich 9.0 nicht exakt im erforderlichen Type (Single, Double, Extended) unterbringen und es wird intern als 8.9999xxx dargestellt.

Das könnte natürlich sein - wäre aber für meinen Anwendungsfall natürlich blöd, da das dann die Rundung wieder verfälscht.

Ich glaube langsam wirklich, ich bleibe bei meinem Hack - der funktioniert nämlich ziemlich gut :)
(ist aber natürlich wg. der Rumkonvertierererei von und nach String ziemlich langsam - spielt bei mir aber keine große Rolle)

[himitsu]

Im Grunde liegt es wohl eher an Rundungsfehlern bei der Verwendung von Fließkommazahlen.

eine 0,9 könnte genau 0,9000000000 sein, aber wenn sich das nicht genau darstellen lässt oder es bei der Berechnung nicht ganz genau rauskommt,
könnte es quasi 0,899999999999 aber auch 0,9000000000001 sein. (vereinfachtes Beispiel, damit man sieht, was ich meine)

Und dann liefert es nachfolgend eben auch andere Werte,
z.B. bei Trunc oder Int(0,899999999999 * 10) eben 8 anstatt 9.

https://de.wikipedia.org/wiki/Gleitkommazahl
https://de.wikipedia.org/wiki/Doppelte_Genauigkeit
https://de.wikipedia.org/wiki/IEEE_754
...




Bei mir geht's und es sind wirklich ganz genau 0,000000. (aber muß eben nicht)

Double und Extended

Code:

type MyFloat = Double;  //Extended;

procedure TForm25.FormCreate(Sender: TObject);
procedure DebugLog(Val: MyFloat);
  begin
    var S := string.Create(' ', SizeOf(Val) * 2);
    BinToHex(@Val, PChar(S), Length(S));  // Val.Bytes[i] for 0..9

    { knallt beim zweiten Durchlauf
    S := S + ' / '  + Val.ToString
           + ' / s' + Val.Sign.ToString
           +   ' e' + Val.Exp.ToString
           +   ' f' + Val.Frac.ToString;
           + ' / e' + Val.Exponent.ToString
           +   ' f' + Val.Fraction.ToString
           +   ' m' + Val.Mantissa.ToString
    }

    S := S + ' / '  + Val.ToString;
    S := S + ' / s' + Val.Sign.ToString;
    S := S +   ' e' + Val.Exp.ToString;
    S := S +   ' f' + Val.Frac.ToString;
    S := S + ' / e' + Val.Exponent.ToString;
    try S := S + ' f' + Val.Fraction.ToString;  except  S := S + ' peng';  end;  // k.A. was es gegen 1/3 hat
    try S := S + ' m' + Val.Mantissa.ToString;  except  S := S + ' peng';  end;

    OutputDebugString(PChar(S));
  end;
var
  Val, Frac, Frac2: MyFloat;
begin
  Val   := 22.649;              DebugLog(Val);    // A01A2FDD24A63640 / 22,649 / s0 e1027 f1871527120149152 / e4 f1,4155625      m6375126747519648
  Val   := Val * 100;           DebugLog(Val);    // CDCCCCCCCCB1A140 / 2264,9 / s0 e1034 f476968144129229 / e11 f1,105908203125 m4980567771499725
  Val   := System.Int(Val);     DebugLog(Val);    // 0000000000B0A140 / 2264   / s0 e1034 f474989023199232 / e11 f1,10546875     m4978588650569728
  Frac  := System.Frac(Val);    DebugLog(Frac);   // 0000000000000000 / 0 / s0 e0 f0 / e0 f0 m0
  Frac2 := Frac * 10.0;         DebugLog(Frac2);  // 0000000000000000 / 0 / s0 e0 f0 / e0 f0 m0
  Frac2 := System.Int(Frac2);   DebugLog(Frac2);  // 0000000000000000 / 0 / s0 e0 f0 / e0 f0 m0
  // auch komisch:
  Frac2 := Frac * 10.0;         DebugLog(Frac2);  // 0000000000000000 / 0 / s0 e0 f0 / e0 f0 m0
  Frac2 := System.Frac(Frac2);  DebugLog(Frac2);  // 0000000000000000 / 0 / s0 e0 f0 / e0 f0 m0

  Val   := 1 / 3;               DebugLog(Val);    // 555555555555D53F / 0,333333333333333 / s0 e1021 f1501199875790165 / e-2 peng peng
  Val   := 1 / 5;               DebugLog(Val);    // 9A9999999999C93F / 0,2               / s0 e1020 f2702159776422298 / e-3 f1,6 m7205759403792794
end;

[freimatz]

Zitat:

Zitat von Bodenseematze (Beitrag 1524455)

Das könnte natürlich sein - wäre aber für meinen Anwendungsfall natürlich blöd, da das dann die Rundung wieder verfälscht.

Was wäre denn der Anwendungsfall? Ich kann mir gerade nichts vorstellen wo man nur die Nachkommstellen braucht. Vielleicht kann man den Anwendungsfall auch ganz anders lösen.

[Andreas13]

Zitat:

Zitat von Bodenseematze (Beitrag 1524453)

Zitat:

Zitat von Andreas13 (Beitrag 1524395)

AMath.pas ersetzt komplett Delphi’s System.Math.pas und verbessert zahlreiche Fehler und Unzulänglichkeiten.

Das ist nicht so ganz richtig - es fehlen z.B. CompareValue, SimpleRoundTo und auch der "Typ" TRoundToRange - damit braucht man die System Math-Unit leider immer noch.

Fehlende und von Dir benötige Routinen kannst Du aus System.Math.pas rauskopieren... :-D

Zitat:

Zitat von Bodenseematze (Beitrag 1524453)

Außerdem kommt auch bei dieser beim Aufruf

Code:

AMath.Frac( 9.0 )

als Ergebnis

Code:

1.0

Wieso? Ich verstehe das nicht :(

"Mein" Delphi liefert den korrekten Wert:

Delphi-Quellcode:

AMath.Frac(9.0) =  0.00000000000000E+0000

Zitat:

Zitat von Bodenseematze (Beitrag 1524453)

Ich habe die Enterprise-Version von Delphi7 - da ist ja der Quellcode dabei, aber ich finde den Code von Frac() dort nicht...
(nur in der von SynopseRTL gepatchten Version - und dort steht "{$IFDEF NEWRTL}" drüber, was erst ab Delphi
2005 definiert ist...)

Frac(..) ist in System.pas deklariert:

Delphi-Quellcode:

function Frac(const X: Extended): Extended;
begin
  Result := X - Int(X);
end;

[Andreas13]

Zitat:

Zitat von Bodenseematze (Beitrag 1524453)

val := 22.65;
val := Math.SimpleRoundTo( 22.65, -1 ); // erwartet hätte ich 22.7 als Ergebnis, ich bekomme aber 22.6 - warum???

Das kann ich leider nicht nachvollziehen: Wenn ich aus System.Math.pas SimpleRoundTo(..) direkt in mein Projekt kopiere

Delphi-Quellcode:

function SimpleRoundTo(const AValue: Extended; const ADigit: TRoundToRange = -2): Extended;
var
  LFactor: Extended;
begin
  LFactor := IntPower(10.0, ADigit);
  if AValue < 0 then
    Result := Int((AValue / LFactor) - 0.5) * LFactor
  else
    Result := Int((AValue / LFactor) + 0.5) * LFactor;
end;

erhalte ich in beiden Fällen den exakt gerundeten Wert:

Delphi-Quellcode:

System.Math.SimpleRoundTo(22.65, -1 ) =  2.27000000000000E+0001
SimpleRoundTo(22.65, -1 ) =  2.27000000000000E+0001 // lokale Kopie

[Andreas13]

Versuche mal das obige Beispiel ganz ohne Math.pas mit diesem Code:

Delphi-Quellcode:

function SimpleRoundTo(const AValue: Extended; const ADigit: TRoundToRange = -2): Extended;
var
  LFactor: Extended;
begin
  LFactor := AMath.IntPower(10.0, ADigit);
  if AValue < 0 then
    Result := AMath.Int((AValue / LFactor) - 0.5) * LFactor
  else
    Result := AMath.Int((AValue / LFactor) + 0.5) * LFactor;
end;

[Andreas13]

Es könnte natürlich auch sein, daß bei Dir die Rundungsart des Prozessors verstellt/falsch eingestellt ist. Bitte folgenden Code mal testen:

Delphi-Quellcode:

VAR 
  MyRoundingMode   : TRoundingMode;
  MyRoundingModeStr: String;

...

  MyRoundingMode:= GetRoundMode;

  Case MyRoundingMode Of  
    rmNearest:  MyRoundingModeStr:= 'rmNearest';

    rmUp:       MyRoundingModeStr:= 'rmUp';

    rmDown:     MyRoundingModeStr:= 'rmDown';

    rmTruncate: MyRoundingModeStr:= 'rmTruncate';
  End;

WriteLn('MyRoundingMode = ', MyRoundingModeStr);

Es sollte rmNearest rauskommen! Das sollte eigentlich die Standard-Einstellung sein.
Falls nicht, kanns Du

Delphi-Quellcode:

SetRoundMode(rmNearest);

verwenden.

[jaenicke]

Bei mir kommen unter Delphi 7 jedenfalls die erwarteten Ergebnisse heraus.

[Bodenseematze]

Zitat:

Zitat von Andreas13 (Beitrag 1524471)

Es könnte natürlich auch sein, daß bei Dir die Rundungsart des Prozessors verstellt/falsch eingestellt ist.

Du meintest TFPURoundingMode in AMath?

Da kommt bei mir "rmNearest" zurück :wink:

Ich bin meinen Code und v.a. meine Logging-Ausgaben nochmal durchgegangen - da war so einiges falsch.
Durch die Ausgaben z.B. mit %f oder %.4f kamen einige bereits gerundete Ergebnisse zurück.
Zudem war an manchen Stellen meine Ausgabe nicht synchron mit der tatsächlichen Berechnung (z.B. * 10 im Wert, im Text aber ohne * 10).

Ich habe das jetzt alles mal korrigiert - der Wert, um den es dann ging war tatsächlich 22.648888888888 -> auf zwei Nachkommastellen dann ein Frac von 0.88888889 * 10 = 8.88888889 und hier ist Int() dann tatsächlich 8.00000

Ich habe allerdings immer noch den Fall, dass (angezeigt) aus Frac(9.0000000000) (1.00000000) wird - aber nur, wenn ich es innerhalb der Berechnung mit einer Variablen ausgebe.
Wenn ich von Hand (als fest kodiert), den Wert 9.00000000 an die Frac-Routinen gebe, kommt korrekt 0.0 raus.
Trotz allem sehr seltsam (0.00000001 oder so als Ergebnis würde ich ja noch verstehen, aber 1.00000000?)

Zitat:

Zitat von Andreas13 (Beitrag 1524467)

Versuche mal das obige Beispiel ganz ohne Math.pas mit diesem Code:

Der Code funktioniert perfekt - auch in den Fällen, in denen Math.SimpleRoundTo das falsche Ergebnis liefert! :-D

Zitat:

Zitat von jaenicke (Beitrag 1524477)

Bei mir kommen unter Delphi 7 jedenfalls die erwarteten Ergebnisse heraus.

Wie oben gesagt, das hängt tatsächlich von den berechneten Werten ab - mit manuellen, hart kodierten Werten kommen bei mir (meistens :wink:) auch die erwarteten Ergebnisse zurück.

Wie dem auch sei - ich bin aktuell ganz zufrieden mit meinen Lösungen und Danke Euch allen für Eure Hilfestellungen! :thumb:

[Bodenseematze]

Zitat:

Zitat von Andreas13 (Beitrag 1524465)

Frac(..) ist in System.pas deklariert:

Delphi-Quellcode:

function Frac(const X: Extended): Extended;
begin
  Result := X - Int(X);
end;

Bei mir nicht (direkt); da steht dann folgendes drin:

Delphi-Quellcode:

procedure       _FRAC;
asm
        FLD     ST(0)
        SUB     ESP,4
        FNSTCW  [ESP].Word     // save
        FNSTCW  [ESP+2].Word   // scratch
        FWAIT
        OR      [ESP+2].Word, $0F00  // trunc toward zero, full precision
        FLDCW   [ESP+2].Word
        FRNDINT
        FWAIT
        FLDCW   [ESP].Word
        ADD     ESP,4
        FSUB
end;

wie der dann zu "Frac" (ohne Unterstrich am Anfang) kommt, weiß ich nicht...

[himitsu]

Vieles Assemblerzeugs wurde "inzwischen" abgeschafft und druch Pure-Pascal ersetzt, bzw. mit alternativen Varianten versehen,

wegen dem 64 Bit-Compiler (Windows)
und auch für die anderen Platformen ala Linux, Android und iOS/OSX.

[jaenicke]

Zitat:

Zitat von Bodenseematze (Beitrag 1524514)

Zitat:

Zitat von jaenicke (Beitrag 1524477)

Bei mir kommen unter Delphi 7 jedenfalls die erwarteten Ergebnisse heraus.

Wie oben gesagt, das hängt tatsächlich von den berechneten Werten ab - mit manuellen, hart kodierten Werten kommen bei mir (meistens :wink:) auch die erwarteten Ergebnisse zurück.

Wie dem auch sei - ich bin aktuell ganz zufrieden mit meinen Lösungen und Danke Euch allen für Eure Hilfestellungen! :thumb:

Du könntest auch die binären Daten, sprich die einzelnen Bytes, zeigen. Dann ließe sich das auch ohne die Rechnung zu kennen reproduzieren.