Fliesskommazahlen und Ungenauigkeiten

[Warf]

Es ist kein Bug, das kommt aus der IEEE 754 Spezifikation: https://en.wikipedia.org/wiki/IEEE_754#Rounding_rules

Die Spezifikation sagt explizit:

"Round to nearest, ties to even" is the default for binary floating point and the recommended default for decimal. "Round to nearest, ties to away" is only required for decimal implementations

Da haben sich Ingeneure im Standardisierungsgremium schon was bei gedacht. Round to nearest even reduziert, wie ich oben beschrieben habe, den Rundungsfehler. Wenn das Ziel also ist möglichst korrekt zu rechnen (was in den meisten Situationen vermutlich der Fall ist), ist es die richtige Wahl.
Und das ist nunmal wie es auf der Hardware in der FPU verlötet ist. Programmiersprachen wie C oder JavaScript die ein eigenes Rundungsverhalten einbauen müssen das selbst implementieren, nicht nur auf Kosten der Genauigkeit sondern gleichzeitig auch mit geringerer Leistung.

Das Problem ist das in der Schule halt eine vereinfachte Form des Rundens beigebracht wird die einfach zu Merken für Kinder ist, aber leider falsch (bzw. falscher als gewollt) rechnet. Wenn man aber eine Maschine hat deren Ziel es ist so wenig falsch wie möglich zu rechnen, dann kann man da auch vernünftige Rundung einbauen.

Ich verstehe nicht was so schwer daran zu begreifen ist das man weniger Rechenfehler machen möchte. Wer rechnet gerne falsch?

[Joh]

Das Problem ist das in der Schule halt eine vereinfachte Form des Rundens beigebracht wird die einfach zu Merken für Kinder ist, aber leider falsch (bzw. falscher als gewollt) rechnet. Wenn man aber eine Maschine hat deren Ziel es ist so wenig falsch wie möglich zu rechnen, dann kann man da auch vernünftige Rundung einbauen.

Ich verstehe nicht was so schwer daran zu begreifen ist das man weniger Rechenfehler machen möchte. Wer rechnet gerne falsch?

Es mag ja sein, das der durchschnittliche Rundungsfehler besser wird.
Aber ich berechne nicht tausende von Artikeln mit Mehrwertsteuer und hätte dann den besten gerundeten Wert, sondern möchte, das meine Cents richtig abgerechnet werden und nicht auf die nächste gerade Zahl.

Ja ich weiß, das anderswo die einzelnen Cents abgeschafft werden.

Wenn jemand meint, seine Statistiken sind bei "nearest even" besser: ok, meinen Segen sollt ihr haben. Aber meine (Finanz-)Berechnungen sollen durchaus 99 ct ergeben können.

[Warf]

Es mag ja sein, das der durchschnittliche Rundungsfehler besser wird.
Aber ich berechne nicht tausende von Artikeln mit Mehrwertsteuer und hätte dann den besten gerundeten Wert, sondern möchte, das meine Cents richtig abgerechnet werden und nicht auf die nächste gerade Zahl.

Selbst wenn du pro Kunde/Transaktion nur einmal rundest, wenn über die Laufzeit deiner Software du eine Millionen Kunden/Transaktionen bedienst, hast du über diese Lebenszeit hinweg trozdem tausende Euros zu viel genommen. Ich mein klar, von jedem einzelnen Kunden stiehlst du im durchschnitt nur einen zehntel cent, aber in summe läppert sich das schon.

Ich glaube zwar das es Rechtlich zumindest für kleiner Unternehmen keine konsequenzen gibt, aber wenn man seine bewusst so baut das sie im Durchschnitt 0,05 ct zu viel abrechnet (was der statistische Fehler ist) würde ich persönlich das als Betrug bezeichnen. Pro Individuum vielleicht klein, aber auf Masse kann man damit schon gut Geld machen

Die einzige Situation in der der Akkumulative Rundungsfehler nicht relevant ist, ist wenn deine Software nur ein einziges mal in ihrer ganzen Lebenszeit rundet. Also wenn deine Software nie benutzt wird ist egal das sie falsch rechnet

[PascalDragon]

Ich habe immer mehr das Gefühl, das dies ein Bug von FPC ist. Vor allem weil man es nicht mal mit SetRoundMode() richtig umstellen kann.

Das funktioniert alles so wie es soll. Wenn du der Ansicht ist, dass es das nicht tut, dann werf bitte nicht einfach nur eine Aussage in den Raum, sondern bring bitte ein explizites Beispiel.

[Joh]

Ich habe immer mehr das Gefühl, das dies ein Bug von FPC ist. Vor allem weil man es nicht mal mit SetRoundMode() richtig umstellen kann.

Das funktioniert alles so wie es soll. Wenn du der Ansicht ist, dass es das nicht tut, dann werf bitte nicht einfach nur eine Aussage in den Raum, sondern bring bitte ein explizites Beispiel.

Na ja, ich finde es schon einen Bug, wenn ich den Roundmode umstelle um meine Finanzmathematischen Berechnungen korrekt zu berechnen und dabei bemerke, wie die Pixel sich auf dem Bildschirm bewegen.
Bei Linien, Objekten. Eventuell auch bei den Fonts, aber da mag sich mein Gedächtnis täuschen.

Wie eine Linie bei einem 45°-Winkel gezeichnet wird, mag ja durchaus andere Rundungswerte erfordern, als meine MwSt-Berechnungen.

[PascalDragon]

Ich habe immer mehr das Gefühl, das dies ein Bug von FPC ist. Vor allem weil man es nicht mal mit SetRoundMode() richtig umstellen kann.

Das funktioniert alles so wie es soll. Wenn du der Ansicht ist, dass es das nicht tut, dann werf bitte nicht einfach nur eine Aussage in den Raum, sondern bring bitte ein explizites Beispiel.

Na ja, ich finde es schon einen Bug, wenn ich den Roundmode umstelle um meine Finanzmathematischen Berechnungen korrekt zu berechnen und dabei bemerke, wie die Pixel sich auf dem Bildschirm bewegen.
Bei Linien, Objekten. Eventuell auch bei den Fonts, aber da mag sich mein Gedächtnis täuschen.

Wie eine Linie bei einem 45°-Winkel gezeichnet wird, mag ja durchaus andere Rundungswerte erfordern, als meine MwSt-Berechnungen.

Dann darfst du den Rundungsmodus eben nur für die Dauer deiner Berechnung umstellen. Oder führe die Berechnung in einem Thread durch, da der Rundungsmodus threadspezifisch ist.

[Mathias]

Na ja, ich finde es schon einen Bug, wenn ich den Roundmode umstelle um meine Finanzmathematischen Berechnungen korrekt zu berechnen und dabei bemerke, wie die Pixel sich auf dem Bildschirm bewegen.
Bei Linien, Objekten. Eventuell auch bei den Fonts, aber da mag sich mein Gedächtnis täuschen.

Und genau da wird auch wieder der liebe geldgierige Banker jammern, wen durch einen Rundungsfehler der Dezimalpunkt fehlt (Pixelfehler).

[Warf]

Und genau da wird auch wieder der liebe geldgierige Banker jammern, wen durch einen Rundungsfehler der Dezimalpunkt fehlt (Pixelfehler).

Subpixelrendering mit dem man auch halbe Pixel rendern kann gibt es ja auch erst seit 30 Jahren (und Anti Aliasing seit 50). OpenGL und SDL können Subpixel bereits seit Jahrzehnten. Wenn man ein Problem mit Pixelsprüngen aufgrund von Rundungsfehlern hat, dann ist das kein Problem beim Runden, sondern das Problem ist das man eine inadequate Grafikbibliothek benutzt.

Das ist ein bisschen als würdest du dich beschweren das auf der Autobahn eine Mindestanforderung für Fahrzeuge von 60 km/h gibt, weil die Pferdekutsche die man hat deshalb nicht drauf dürfen. Das Problem ist nicht die Autobahn