Rundungsfunktion FloatRound fehlerhaft

Wilfried · August 7, 2025 at 6:00 PM

Die Rundungsfunktion FloatRound macht das, was sie soll, solange die Dezimalstellenzahl größer als Null ist. Soll ganzzahlig gerundet werden, dann werden die Nachkommastellen einfach abgeschnitten.

Habe lange nach der Ursache für meine fehlerhaften Rechenergebnisse gesucht, weil ich natürlich dachte, dass meine eigenen Rechnungen fehlerhaft sind.

Rainer · August 8, 2025 at 11:09 AM

So ein Mist. Das ist jetzt ein issue wert.

Rainer

frehwagen · August 8, 2025 at 6:57 PM

Hi Wilfried

Hast Du einen Code-Schnipsel oder besser ein Beispielprogramm welches das Problem zeigt?
Welchen Emulator/Umgebung verwendest Du?

Viele Grüße,

Falk \\ blueway.Softworks

Wilfried · August 9, 2025 at 11:06 AM

Emulator: DosBox unter W10

Code

double round(double zahl1,byte zahl2)
{
  double zahl3;
  FloatIEEE64ToGeos80(&zahl1);
  FloatRound(zahl2);
  FloatGeos80ToIEEE64(&zahl3);
  return(zahl3);
}

round(3.86,1) ergibt 3.9
round(3.86,0) ergibt 3
round(-3.86,1) ergint -4
round(3.86,0) ergibt -3

Mit Watcom compiliert

Display More

Wilfried · August 9, 2025 at 5:32 PM

Da ich nur ganzzahlig runden will, behelfe ich mir so: Wenn die zu rundende Zahl positiv ist, addiere ich vor der Rundung 0.5, bei negativen subtrahiere ich 0.5. Das Abschneiden der Nachkommastellen führt so zur gewünschten Rundung.

sebi · August 9, 2025 at 9:28 PM

Quote from Wilfried

Emulator: DosBox unter W10

Code

double round(double zahl1,byte zahl2)
{
  double zahl3;
  FloatIEEE64ToGeos80(&zahl1);
  FloatRound(zahl2);
  FloatGeos80ToIEEE64(&zahl3);
  return(zahl3);
}

round(3.86,1) ergibt 3.9
round(3.86,0) ergibt 3
round(-3.86,1) ergint -4
round(3.86,0) ergibt -3

Mit Watcom compiliert

Display More

Das schweift zwar ab, aber ich hätte trotzdem eine Verständnisfrage zu diesem Code: Macht der überhaupt irgendwas?

Die Variable zahl3, die von der Funktion zurückgegeben wird, wird ja nirgends (explizit) belegt.

Oder passiert das alles indirekt?

FloatIEEE64ToGeos80() speichert zahl1 irgendwo
FloatRound() rundet zahl1 auf die mit zahl2 angegebene Zahl von Nachkommastellen
FloatGeos80ToIEEE64() fischt die gerundete zahl1 aus den nebulösen Speicheruntiefen heraus und gibt sie als zahl3 zurück

Sieht so native Geos-Programmierung aus?

Wilfried · August 10, 2025 at 10:57 AM

Hallo Sebi,

Code

bei der Benutzung des Borland-Compilers sah der Code verständlicher aus, weil durchweg mit dem FloatNum-Format gearbeitet werden konnte. 

FloatNum round(FloatNum zahl1,byte zahl2)
{
  FloatNum zahl3;
  FloatPushNumber(&zahl1);
  FloatRound(zahl2);
  FloatPopNumber(&zahl3);
  return(zahl3);
}

FloatIEEE64ToGeos80(&zahl1) wandelt vom double- ins FloatNum-Format um und legt die Zahl auf den FP-Stack. FloatRound macht die Rundung und legt das Ergebnis auf dem Stack ab. FloatGeos80ToIEEE64(&zahl3) holt sich das Ergebnis und wandelt zurück ins double-Format. So die Kurzform.

frehwagen · August 18, 2025 at 9:34 PM

Hallo Wilfried,

ich habe gerade Versuch das Problem nachzustellen. Ich sehe allerdings bei mir andere Ergebnisse:

Code

  330:        result1 = round(3.86,1);
(hello:0) 7 => print result1
@1: result1 = 3.900000

  331:        result1 = round(3.86,0);
(hello:0) 10 => print result1
@2: result1 = 4.000000

  332:        result1 = round(-3.86,1);
(hello:0) 12 => print result1
@3: result1 = -3.900000

  333:        result1 = round(-3.86,0);
(hello:0) 14 => print result1
@4: result1 = -4.000000

Display More

Ist die Emulation/das Target ein aktueller FreeGEOS-Built? Verwendest Du eine aktuelle Version von Staging DosBOX oder ein älteres Original?

Viele Grüße,

Falk \\ blueway.Softworks

Wilfried · August 19, 2025 at 11:09 AM

Hallo Falk,

interessant! Hast du in "Hello" die round-Funktion genau so definiert wie ich?

Ich habe mir heute die aktuelle DosBox-Version (0.74-3) und die aktuelle Geos-Version heruntergeladen: Es zeigt sich keine Veränderung des beschriebenen Rundungsfehlers. Ob ich das neueste Target habe, weiß ich nicht. Meins ist vom Nov 24 (Syhra). Auch damit (Swat wird mitgestartet) zeigt sich der Fehler.

Gruß

Wilfried

frehwagen · August 19, 2025 at 4:19 PM

Hallo Wilfried,

könntest Du zum Vergleich mal die Staging DosBOX probieren: https://www.dosbox-staging.org/

Viele Grüße,

Falk \\ blueway.Softworks

Wilfried · August 19, 2025 at 6:07 PM

Mit Staging DosBox dasselbe Ergebnis.

Jirka Kunze · August 20, 2025 at 8:29 PM

Ich habe nun auch ein wenig mit dem geposteten Codeschnipsel experimentiert und auch in meinen Fällen wird durch round() das korrekte Ergebnis geliefert.

Eine Idee wäre da noch: Die Funktionen FloatPushNumber(), FloatPopNumber() und FloatRound() delegieren an den Coprozessor, wenn ein solcher erkannt wird, dann wird zu jeder dieser Funktionen die korrespondieren x87 Instruktion aufgerufen. Falls kein Copro gefunden wird, dann werden diese Funktion durch x86 Instruktionen 'emuliert'. Vielleicht wird bei Wilfried der Copro nicht erkannt und die Emulation ist hier das Problem. Das ist aber nur Spekulation.

Jirka

frehwagen · August 21, 2025 at 8:33 AM

Bei mir gibt es auch die richtigen Ergebnisse, wenn ich den Copro so ausstelle:

[math]
coprocessor = none

LG,

Falk \\ blueway.Softworks

Rainer · August 21, 2025 at 9:09 AM

Hi,

ich hab jetzt nicht mit dem Code gespielt, aber in R-BASIC nutze ich auch die Float~ Routinen, mit dem FP Stack und da wird auch richtig gerundet.

Noch ne ganz dumme Idee - sowas in der Art hatte ich nämlich auch schon: Kann es sein, dass die Rechnung an sich korrekt ist, aber die Konvertierung in einen String schief geht? Ich weiß, dass ist unwahrscheinlich ...

Rainer

jpolzfuss · August 21, 2025 at 9:47 AM

So unwahrscheinlich ist das gar nicht…

(s. Java, wo z.B. bei einem Zeitstempel mit Nanosekunden bei einem truncatedTo(ChronoUnit.MILLIS) mit anschließendem println trotzdem keine Millisekunden angezeigt werden, wenn die Uhrzeit nach dem Truncate genau 0 Millisekunden hat.)

Wilfried · August 21, 2025 at 12:00 PM

Vielen Dank für eure Hilfe!

@Jirka: Wenn es so wäre wie du sagst, wie erklärst du dann, dass der Fehler nur bei Rundung auf 0 Dezimalstellen auftritt?

Rainer: Tatsächlich tritt der Fehler in den Rechnungen auf. Bei Verschiebungen von Grafikobjekten traten immer Ungenauigkeiten auf, die ich mir nicht erklären konnte. Mit meinem Workaround sind sie weg.

Wilfried

Rainer · August 21, 2025 at 4:54 PM

Gut, dann machen wir mal Nägel mit richtigen Köpfen. Im Anhang ein Programm, das bei mir funktioniert

Mit im Archiv ist die compilierte Geode, die bei mir geht, sowohl unter BBX 4.13 als auch unter dem aktuellen Target

Wilfried Was sagt die geode (aus dem Archiv, von mir compiliert) bei dir?
Was passiert, wenn du das Ding selbst compilierts?

Rainer

Wilfried · August 21, 2025 at 6:44 PM

Rainer, deine Geode zeigt auch bei mir die richtigen Rundungswerte (auch nach Neucompilierung).

Ich benutze seit Ewigkeiten MessageNumberBox aus lmacros.goh zur Kontrollanzeige von Variablen (hab ich mal von dir bekommen?). Ich habe die Datei in die process.goc eingebunden und den Code um MessageNumberBox - Zeilen ergänzt. Jetzt zeigen deine PrintNum und "meine" MessageNumberBox beide die falschen Rundungswerte. Was ist da los

Wilfried

Code

Print("\rRunde 3.86, 1 -> Wilfried: 3.9");
result = round(3.86,1);
PrintNum(result);
MessageNumberBox(result);

Print("\rRunde 3.86,0 -> Wilfried: 3");
result = round(3.86,0);
PrintNum(result);
MessageNumberBox(result);

Print("\rRunde -3.86,1 -> Wilfried: -3.9");
result = round(-3.86,1);
PrintNum(result);
MessageNumberBox(result);

Print("\rRunde -3.86,0 -> Wilfried: -3");
result = round(-3.86,0);
PrintNum(result);
MessageNumberBox(result);

Display More

Rainer · August 21, 2025 at 10:16 PM

Hallo Wilfried,

ja, MessageNumberBox und lmacros.goh hast du wohl mal von mir, vermute ich. Allerdings kann meine MessageNumberBox eigentlich nur mit ganzen Zahlen umgehen (wegen der LocalFixedToAscii-Zeile), nicht mit Real-Zahlen. Angewendet auf result sollte a) eine Compilerwarung (type-fehler) kommen und b) nicht das richte Ergebnis angezeigt werden. Immer vorausgesetzt du nutzt meine MessageNumberBox().
Außerdem hat die usprüngliche Variante aus lmacros.goh (die du wahrscheinlich hast) einen Bug, der buffer txt[] für LocalFixedToAscii war in bestimmten Situationen zu klein. Damit überscheibt LocalFixedToASCII igendwelchen Speicher auf dem Stack - das Ergebnis ist völlig unvorhersehbar. Das ist die aktuelle Version (mit txt[20]):

Code

#ifndef MessageNumberBox
#define  MessageNumberBox(number) { \
        char txt[20]; \
        LocalFixedToAscii(txt,MakeWWFixed(number),0); \
        UserStandardDialog ( (char *)0,(char *)0,(char *)0,(char *)0,txt, \
        (( CDT_NOTIFICATION << CDBF_DIALOG_TYPE_OFFSET) | \
         ( GIT_NOTIFICATION << CDBF_INTERACTION_TYPE_OFFSET)) ); \
         }
#endif

Wenn ich richtig liege solltest du am Anfang (vor dem ersten Aufruf von MessageNumberBox) mal die Zeilen

Code

Print("\rRunde 3.86, 1 -> Wilfried: 3.9");
result = round(3.86,1);
PrintNum(result);

Ändern in (minuszeichen hinzugefügt)

Code

Print("\rRunde -3.86, 1 -> ..");
result = round(-3.86,1);
PrintNum(result);

Und das Ergebnis sollte richtig sein.

Außerdem sollte die Korrektur des Macros MessageNumberBox() zumindest dazu führen, das PrintNum in der ganzen Sequenz die richtigen Ergebnisse liefert.

Bis dahin erst mal
Rainer

P.S. Das Macro MakeWWFixed() ist wohl auch nicht perfekt, insbesondere wenn es um negative Zahlen geht.

P.P.S. Du kannst dir gar nicht vorstellen, wie oft es mir schon passiert ist dass ein Programmabsturz oder ein anderer Fehler eigentlich gar nicht da war, sondern nur durch meinen "Ich-check-das-mal-zur-Sicherheit-gegen" Debuging Code hervorgerufen wurde. Das kostet oft Stunden! Trotzdem liebe ich das System

frehwagen · August 21, 2025 at 10:57 PM

Hi Rainer,

bezüglich MakeWWFixed gab es im Kontext zu Watcom ein Thema und einen Fix. Er akzeptiert da tatsächlich auch Floats/double und läßt diese den Compiler in ein dword casten, korrekterweise in ein sdword, was ich aber erst Fixen mußte. Borland hat binär beim cast nach dword/sdword immer mit Vorzeichen gearbeitet, Watcom beachtet den Zieltyp. Deswegen muß das MakeWWFixed-Makro korrigiert werden:

943 fp math lib integration (#946) · bluewaysw/pcgeos@dd27ea5

* Add dword unsigend conversion with float because Watcom integration will need it #943 * Add DLL to link for float runtime dependencies of Watcom C Compiler…

github.com

Viele Grüße,

Falk \\ bluway.Softworks