Irgendwie habe ich das Gefühl, das ein riessen Bug in FPC-round steckt.
In der Graphik kann durch das Bankers-Rounding der Fehler höchstens 1 Pixel betragen. Wenn das "extrem" ist, ok...
Ja, dies ist ein extremer Fehler. Dies ist viel störender, als wen 1 Cent auf dem Konto fehlt.In der Graphik kann durch das Bankers-Rounding der Fehler höchstens 1 Pixel betragen. Wenn das "extrem" ist, ok...
Dies ist mir schon klar, aber für die Ausgabe auf den Bildschirm muss man halt zum Schluss halt runden. Aber nicht einmal richtig und dann wieder falsch.und den Ingenieurswissenschaften ist Runden verpöhnt, weil es die Genauigkeit verschlechtert. Und wenn man mit gerundeten Zahlen weiterrechnet, wird alles viel schlimmer. Runden darf man nur, um das Endergebnis zu präsentieren, also in der Float-zu-String-Umwandlung,
Dicke Off-Topic-Flagge!!!!wp_xyz hat geschrieben: ↑Mi 20. Dez 2023, 13:43
...
Ehrlich gesagt, in der Mathematik wird kaum gerechnet, und in Physik und den Ingenieurswissenschaften ist Runden verpöhnt, weil es die Genauigkeit verschlechtert. Und wenn man mit gerundeten Zahlen weiterrechnet, wird alles viel schlimmer. Runden darf man nur, um das Endergebnis zu präsentieren, also in der Float-zu-String-Umwandlung, und dafür gibt es erprobte Routinen. Insbesondere spielt es dann keine Rolle mehr, wenn die Zahl 0.2 in der internen Darstellung als - ich sag mal - 0.200000000045 behandelt wird.
Die Genauigkeit ist mir beim Rendern nicht so wichtig, was mich nervt, ist das der PC sich nicht einigen kann, ob er bei x.5 auf oder abrunden soll.Als Physiker, der als Ingenieur arbeitet: das ist so nicht richtig. Die halbe Ingenieurarbeit besteht aus Abschätzen, Vereinfachen, Nachschauen, was welche DIN- oder EN-Richtlinie sagt ...
Was spricht hier gegen ceil oder floor? Dann hast du es immer gleich.Mathias hat geschrieben: ↑Mi 20. Dez 2023, 17:01Die Genauigkeit ist mir beim Rendern nicht so wichtig, was mich nervt, ist das der PC sich nicht einigen kann, ob er bei x.5 auf oder abrunden soll.
Wen er es wenigsten immer gleich machen würde, egal ob die linke Kommaseite ein gerade oder ungerade Zahl ist.
Ich kann mir einfach nicht vorstellen, das die in FPC nicht gehen soll, C kann es ja.
Der PC - genauer: die CPU - macht exakt das, was die Menschen ihr durch Programmierung aufgetragen haben. Und da scheint mir beim Runden in Free-Pascal einiges nicht in Ordnung zu sein.Mathias hat geschrieben: ↑Mi 20. Dez 2023, 17:01...
Die Genauigkeit ist mir beim Rendern nicht so wichtig, was mich nervt, ist das der PC sich nicht einigen kann, ob er bei x.5 auf oder abrunden soll.
Wen er es wenigsten immer gleich machen würde, egal ob die linke Kommaseite ein gerade oder ungerade Zahl ist.
Ich kann mir einfach nicht vorstellen, das die in FPC nicht gehen soll, C kann es ja.
Normalerweise runde ich nicht. Ich brauche das nicht, aber aus Neugier beschäftige ich mich einfach mal damit - es ist sehr seltsam gelöst, besonders seltsam ist der Typ "Currency". https://www.freepascal.org/docs-html/ref/refsu5.htmlwp_xyz hat geschrieben: ↑Mi 20. Dez 2023, 13:43In der Graphik kann durch das Bankers-Rounding der Fehler höchstens 1 Pixel betragen. Wenn das "extrem" ist, ok...
Ehrlich gesagt, in der Mathematik wird kaum gerechnet, und in Physik und den Ingenieurswissenschaften ist Runden verpöhnt, weil es die Genauigkeit verschlechtert. Und wenn man mit gerundeten Zahlen weiterrechnet, wird alles viel schlimmer. Runden darf man nur, um das Endergebnis zu präsentieren, also in der Float-zu-String-Umwandlung, und dafür gibt es erprobte Routinen. Insbesondere spielt es dann keine Rolle mehr, wenn die Zahl 0.2 in der internen Darstellung als - ich sag mal - 0.200000000045 behandelt wird.
CurrencyCheck.7z Naja. Die Frage ist halt, was ist x.5 denn genau? x.5000000000000001 oder x.49999999999999 (keine Ahnung, ob diese beiden Zahlen überhaupt darstellbar sind!!).
Da kann ich genauso gut Trunc erwenden.Ich934 hat geschrieben: ↑Mi 20. Dez 2023, 17:47Was spricht hier gegen ceil oder floor? Dann hast du es immer gleich.Mathias hat geschrieben: ↑Mi 20. Dez 2023, 17:01Die Genauigkeit ist mir beim Rendern nicht so wichtig, was mich nervt, ist das der PC sich nicht einigen kann, ob er bei x.5 auf oder abrunden soll.
Wen er es wenigsten immer gleich machen würde, egal ob die linke Kommaseite ein gerade oder ungerade Zahl ist.
Ich kann mir einfach nicht vorstellen, das die in FPC nicht gehen soll, C kann es ja.
Bin auch Physiker, und du hast mich wahrscheinlich nicht verstanden, weil das Wort "verpöhnt" natürlich irreführend ist. Natürlich muss in einem Bericht das Endergebnlis gerundet werden, je nach erlaubter Toleranz/Größe der Fehlerbalken, und ich weiß noch, wie ich in meiner aktiven Zeit auf die Studenten einreden musste, für das Ergebnis nicht blind alle 10 Stellen vom Taschenrechner abzuschreiben. Aber das betrifft die Float-zu-String-Konvertierung, denn in den Bericht schreibe ich den String "0.2" und nicht die 8 Byte der Double-Precision Zahl 0.2000000045, die der Computer intern verwendet. Was für mich verpöhnt ist, das ist das Round() mit Zahlen, bloß weil einem die vielen Dezimalstellen nicht gefallen, denn dabei wirft man die Dezimalstellen weg und hat ein ungenaues Ergebnis, (und selbst das kann der Computer oft nicht genauso vorstellen, wie sich der unbedarfte User es sich wünscht). Round verwende ich in der Regel nur, wenn ein Float in einen Integer konvertiert werden muss, so wie in der Graphik auf dem Monitor mit ganzzahligen Pixeln. Und da, ganz ehrlich, fällt es in den allermeisten Fällen nicht auf, wenn wegen Bankers-Rounding die Mitte eines Rechtecks um 1 Pixel nach oben rutscht, je nachdem ob die Rechteckhöhe gerade oder ungerade ist.photor hat geschrieben: ↑Mi 20. Dez 2023, 16:42Als Physiker, der als Ingenieur arbeitet: das ist so nicht richtig. Die halbe Ingenieurarbeit besteht aus Abschätzen, Vereinfachen, Nachschauen, was welche DIN- oder EN-Richtlinie sagt ...
Gerade als Ingenieur wird es niemanden interessieren, ob dein Ergebnis "0.2" oder "0.20000045" oder auch "0,199999933" heißt. Meist reicht esaber eh, unter (oder über) einem bestimmten "Sicherheitsfaktor" zu bleiben, der von der Richtlinie (und einem eventuellen Zertifizierer) vorgegeben wird.
ceil, floor, trunc - da heißt es genau aufpassen, wenn die Ausgangszahl wegen Rundungsfehlern ein bisschen vom Integer in der "falschen" Richtung abweicht, hat man im Nu einen Fehler um eine ganze Stelle, und bei negativen Zahlen ist es wieder anders...
Code: Alles auswählen
program Project1;
uses
Math;
procedure Test(x: Double);
begin
WriteLn('x=', x, ' --> round(x)=', round(x), ', aber: ceil(x)=', ceil(x), ' floor(x)=', floor(x), ' trunc(x)=', trunc(x));
end;
begin
Test(1.99999999999);
Test(2.00000000001);
Test(-1.99999999999);
Test(-2.00000000001);
ReadLn;
end.
----------------------------------
Output:
x= 1.9999999989999999E+000 --> round(x)=2, aber: ceil(x)=2 floor(x)=1 trunc(x)=1
x= 2.0000000000100000E+000 --> round(x)=2, aber: ceil(x)=3 floor(x)=2 trunc(x)=2
x=-1.9999999989999999E+000 --> round(x)=-2, aber: ceil(x)=-1 floor(x)=-2 trunc(x)=-1
x=-2.0000000000100000E+000 --> round(x)=-2, aber: ceil(x)=-2 floor(x)=-3 trunc(x)=-2 Das ist wohl das eigentlichen Problem: die Trennung von GUI (= Anzeige) und Daten (= der gespeicherte Wert).wp_xyz hat geschrieben: ↑Mi 20. Dez 2023, 20:15Bin auch Physiker, und du hast mich wahrscheinlich nicht verstanden, weil das Wort "verpöhnt" natürlich irreführend ist. Natürlich muss in einem Bericht das Endergebnlis gerundet werden, je nach erlaubter Toleranz/Größe der Fehlerbalken, und ich weiß noch, wie ich in meiner aktiven Zeit auf die Studenten einreden musste, für das Ergebnis nicht blind alle 10 Stellen vom Taschenrechner abzuschreiben. Aber das betrifft die Float-zu-String-Konvertierung, denn in den Bericht schreibe ich den String "0.2" und nicht die 8 Byte der Double-Precision Zahl 0.2000000045, die der Computer intern verwendet.
Richtig. Wenn man Round() nutzt wird wieder ein Float draus, der selbst wieder nur schlecht dargestellt werden kann (siehe mein vorheriger Post). Wenn man schon irgendwie "rundet" (ab- auf-, kaufmännisch, Bankers round ...) dann erst da, wo es gebraucht wird und dann in einem Format, dass das auch so darstellt (z.B. Integer). Sonst fängt man sich Nebeneffekte ein.wp_xyz hat geschrieben: ↑Mi 20. Dez 2023, 20:15Was für mich verpöhnt ist, das ist das Round() mit Zahlen, bloß weil einem die vielen Dezimalstellen nicht gefallen, denn dabei wirft man die Dezimalstellen weg und hat ein ungenaues Ergebnis, (und selbst das kann der Computer oft nicht genauso vorstellen, wie sich der unbedarfte User es sich wünscht). Round verwende ich in der Regel nur, wenn ein Float in einen Integer konvertiert werden muss, so wie in der Graphik auf dem Monitor mit ganzzahligen Pixeln. Und da, ganz ehrlich, fällt es in den allermeisten Fällen nicht auf, wenn wegen Bankers-Rounding die Mitte eines Rechtecks um 1 Pixel nach oben rutscht, je nachdem ob die Rechteckhöhe gerade oder ungerade ist.
So sehe ich das auch ...photor hat geschrieben: ↑Do 21. Dez 2023, 10:13
...
Richtig. Wenn man Round() nutzt wird wieder ein Float draus, der selbst wieder nur schlecht dargestellt werden kann (siehe mein vorheriger Post). Wenn man schon irgendwie "rundet" (ab- auf-, kaufmännisch, Bankers round ...) dann erst da, wo es gebraucht wird und dann in einem Format, dass das auch so darstellt (z.B. Integer). Sonst fängt man sich Nebeneffekte ein.
Ciao,
Photor
Sowie rintThese functions shall round their argument to the nearest integer value in floating-point format, rounding halfway cases away from zero, regardless of the current rounding direction.
Der Grund dafür ist, das die FPUs verschiedene Rounding Modes implementieren und damit rint, was das Implementierungsspezifische Runden der FPU ausnutzen kann deutlich effizienter ist als round, was zwar "konsistent" ist, dafür emuliert werden muss.These functions shall return the integral value (represented as a double) nearest x in the direction of the current rounding mode. The current rounding mode is implementation-defined.
If the current rounding mode rounds toward negative infinity, then rint() shall be equivalent to floor. If the current rounding mode rounds toward positive infinity, then rint() shall be equivalent to ceil. If the current rounding mode rounds towards zero, then rint() shall be equivalent to trunc. [MX] [Option Start] If the current rounding mode rounds towards nearest, then rint() differs from round in that halfway cases are rounded to even rather than away from zero. [Option End]
Code: Alles auswählen
#include <stdio.h>
#include <math.h>
#include <time.h>
int main()
{
int acc=0;
clock_t start = clock();
for(int i=0;i<100000000; ++i) {
acc += (int)round(i+0.5);
}
clock_t end = clock();
printf("round: %d: %f\n", acc, (float)(end-start)/CLOCKS_PER_SEC);
acc=0;
start = clock();
for(int i=0;i<100000000; ++i) {
acc += (int)rint(i+0.5);
}
end = clock();
printf("rint: %d: %f\n", acc, (float)(end-start)/CLOCKS_PER_SEC);
return 0;
}Code: Alles auswählen
round: 987459712: 0.669109
rint: 937459712: 0.295144Code: Alles auswählen
program Project1;
{$mode objfpc}{$H+}
uses
sysutils, math;
function RoundAway(d: Double): Integer;
begin
if d < 0 then
Result := trunc(d-0.5)
else
Result := trunc(d+0.5);
end;
function RoundError(Iters: Integer): Double;
var
Sum, rnd: Double;
RoundedSum, i: Int64;
begin
Sum := 0;
RoundedSum := 0;
for i:=1 to Iters do
begin
rnd := Random(100)/10;
Sum += rnd;
RoundedSum += Round(rnd);
end;
Result := Sum - RoundedSum;
end;
function RoundAwayError(Iters: Integer): Double;
var
Sum, rnd: Double;
RoundedSum, i: Int64;
begin
Sum := 0;
RoundedSum := 0;
for i:=1 to Iters do
begin
rnd := Random(100)/10;
Sum += rnd;
RoundedSum += RoundAway(rnd);
end;
Result := Sum - RoundedSum;
end;
begin
Randomize;
WriteLn('RoundError(1000): ', RoundError(1000).ToString);
WriteLn('RoundError(10000): ', RoundError(10000).ToString);
WriteLn('RoundError(100000): ', RoundError(100000).ToString);
WriteLn('RoundAwayError(1000): ', RoundAwayError(1000).ToString);
WriteLn('RoundAwayError(10000): ', RoundAwayError(10000).ToString);
WriteLn('RoundAwayError(100000): ', RoundAwayError(100000).ToString);
end. Code: Alles auswählen
RoundError(1000): 11,7000000000062
RoundError(10000): -19,199999999837
RoundError(100000): -8,19999999884749
RoundAwayError(1000): -55,8000000000002
RoundAwayError(10000): -507,600000000035
RoundAwayError(100000): -5056,80000000255Da muss man aber auch dazu sagen das das mehr eine Limitation des Canvas in Lazarus ist als alles andere. Moderne Grafikbibliotheken unterstützen Subpixel rendering, womit man Problemlos auch halbe Pixel ansteuern kann ohne das man Hässliche Sprünge oder Knicks hat. Zum Beispiel das HTML5 Canvas das Browser unterstützen:wp_xyz hat geschrieben: ↑Mi 20. Dez 2023, 20:15Round verwende ich in der Regel nur, wenn ein Float in einen Integer konvertiert werden muss, so wie in der Graphik auf dem Monitor mit ganzzahligen Pixeln. Und da, ganz ehrlich, fällt es in den allermeisten Fällen nicht auf, wenn wegen Bankers-Rounding die Mitte eines Rechtecks um 1 Pixel nach oben rutscht, je nachdem ob die Rechteckhöhe gerade oder ungerade ist.
Code: Alles auswählen
<canvas id="myCanvas" width="200" height="100" style="border:1px solid #d3d3d3;">
Your browser does not support the HTML canvas tag.</canvas>
<script>
var pos = 0;
function line() {
var c = document.getElementById("myCanvas");
var ctx = c.getContext("2d");
ctx.clearRect(0,0,c.width,c.height);
ctx.beginPath();
ctx.moveTo(pos,0);
ctx.lineTo(pos,100);
ctx.stroke();
pos+=0.5;
if (pos>c.width) pos=0;
window.setTimeout(line, 1);
}
line();
</script>Ich habe vorhin das Round von pas2js ausprobiert. Dies rundet korrekt, so wie wir es in der Schule gelernt haben.Aber: Das eine rundet auf, das andere ab. DAS hängt auch von der internen Zahlendarstellung ab. Aber auch davon, wie z.B. das Runden selbst implementiert wird.
Verein
Links Suche
