Expertenfrage (Rundungsfehler des Makers umgehen - wie?)

[Cherry]

der PPC eignet sich dafür aber nicht, da es relativ lange zum Starten braucht, da externen Programm (bis zu 1 Sek.!), und das bei jedem Aufruf.

Der große Power Patch (v0.43b) kann dir da aber besser helfen, da er nebenher läuft.

Bzw. bist du ja auch PP0.85-Betatester, daher könnte man da vllt auch was für dich "drehen".

[Alan]

Bzw. bist du ja auch PP0.85-Betatester, daher könnte man da vllt auch was für dich "drehen".

...

??? Seit wann bin ich Betatester? Da weiß ich ja gar nix davon *lol*

[Cherry]

LOL. Du hast du doch ganz ganz zu Beginn gemeldet, wie es dann soweit war, habe ich dir EIGENTLICH die Zugangsdaten geschickt. O.o

[Alan]

Muss schon verdammt lange her sein, dass ich mich nicht mehr erinnern kann. Aber Zugangsdaten hab' ich garantiert keine bekommen, daran könnte ich mich nämlich mit Sicherheit erinnern.

[CapSeb]

Alan, warum machst du das so komplizert? ^^

Der Maker rechnet immer von links nach rechts, das heißt von links nach rechts summieren sich Rundungsfehler auf. Wenn du den Rundungsfehler erst ganz zum Schluss entstehen lässt, d.h. ganz rechts, dann kann sich da nichts aufsummieren:

Code:

position
= start + (ziel-start)/20(gerundet)*teilstueck
= (ziel-start)*teilstueck /20(gerundet) + start

Bei jedem Teilstück, das was du als "time" bezeichnet hast, wird die Gesamtstrecke erneut geteilt. Da brauchst du dann keinen Patch, kein Lua und auch keine durch mal-tausend entsehende Riesenzahlen. Guck dir die Umstellung der Formelstücke genau an. Das ist sehr komprimierte Information.

Im Maker heißt das dann:

Code:

position  = ziel;
position -= start;
position *= teilstueck;
position += 10;
position /= 20;
position += start;

das "plusgleich zehn" ist damit er nicht abschneidet sondern rundet.
10 ist die Hälfte von 20. Er soll "abrunden", wenn die Zahl, die geteilt wird, bis zu 10 zu groß ist. Das macht er immer, indem er abschneidet. Aber er soll "aufrunden", wenn sie um mehr als 10 zu groß ist. Das kann der Maker ja eigentlich nicht. Mit dem Plus-zehn-Trick geht beides.

Z.B. ist 47 um sieben zu groß. Er sollte eigentlich abrunden.
Wenn wir 10 zu der Zahl addieren, schneidet er zum Glück immer noch ab, denn 57/20 ist kleiner als 3. Tada, ein Abrunden simuliert. Und natürlich ist es kein Glück sondern normal.
Wenn sie mehr als 10 zu groß ist, sollte er eigentlich aufrunden. Aufrunden entspricht in den nächsten 20er-Bereich zu kommen und abzuschneiden. Wenn wir 10 z.B. zu 52 hinzuaddieren (52/20 müsste aufgerundet werden), kommen wir auf 62. Das befindet sich im nächsten 20er-Abschnitt und ergibt beim Durch-20-Teilen und Abschneiden 3. und 52/20 ist gerundet ja wirklich 3.
Funktioniert also.

Mathematisch lautet das Prinzip:

Code:

(Dividend+[Divisor/2])/Divisor
= Dividend/Divisor + [Divisor/2]/Divisor
= Dividend/Divisor + 0,5

für [(Dividend/Divisor modulo 1) < 0,5] gilt: Dividend/Divisor + Nachkommastelle
für [(Dividend/Divisor modulo 1) >= 0,5] gilt: Dividend/Divisor + 1,x

Ersteres ist die Abrundebedingung und enspricht beim Abschneiden dem Abrunden.
Zweiteres ist die Aufrundebedingung und enspricht beim Abschneiden dem Aufrunden.

Mathe statt Umstand.


CapSeb

[Alan]

Whoa jetzt kommen wieder die Mathematiker daher, ellenlange Formeln im Gepäck und behaupten, ihre Lösung sei einfacher xD

Ne, Spaß beiseite. Dein Rundungs-"Trick" ist sicherlich schön und gut. Aber. Das Runden an sich ist - as said - nie das Problem gewesen. Das habe ich ja schon vorher mit Makenshi besprochen. Der Titel des Threads ist vielleicht etwas... ungünstig gewählt, da der Rundungsfehler nicht das Kernproblem darstellt, wie sich im weiteren Verlauf der Diskussion herausgestellt hat. Der Maker rundet nämlich durchaus richtig, nur hat mein usprünglicher Code den Rundungsfehler immer wieder "mitgeschleppt" und ihn durch nichts wieder ausgleichen können. De facto ist meiner Meinung nach die Multiplikation mit 10.000 (oder einer noch höheren Zahl) die einzig wirklich gangbare Möglichkeit zur effektiven Lösung dieses Problems mit den Mitteln, die einem im RPG-Maker zur Verfügung stehen, da somit das Rechnen mit Kommazahlen zumindest soweit "simuliert" wird, dass die maximale Abweichung vom vorausberechneten Ergebnis höchstens 1 Pixel betragen kann. Natürlich tritt der Fehler nach wie vor auf, wenn man dann mit den gerundeten Koordinaten weiterrechnet, aber wenn man für die weitere Berechnung auf die exakten, mit 10.000 multiplizierten, Koordinaten zurückgreift, beträgt der maximale Rundungsfehler nur 1 Pixel.

Trotzdem vielen Dank für deine Anregungen!


Greetz!


Alan

[Kyuu]

[...] Der Maker rundet nämlich durchaus richtig [...]

...

Das ist falsch, wurde vor mir aber auch schon angemerkt. Alle mathematischen Operationen im RPG Maker sind Integeroperationen, d.h., nach einer Division entsteht ein ganzzahliges Ergebnis und ein ganzzahliger Rest (Assembler-Programmierern müsste das bekannt vorkommen), wobei nur das Ergebnis verwendet wird und der Rest verworfen. Das entspricht dem Abschneiden der Nachkommastellen bei einer Gleitkommazahl, oder - für positive Gleitkommazahlen - dem Abrunden (Gaußklammer).

Bei deiner bisherigen Lösung verwendest du Festkommazahl-Arithmetik, d.h., du skalierst die Zahlen vor den Berechnungen mit einem Faktor, führst die Berechnungen bei einer höheren Präzision durch und konvertierst das Ergebnis dann in eine Gleitkommazahl mit dem Teilen durch den Skalierungsfaktor, wobei automatisch eine Ganzzahl entsteht, da die Division eine Integeroperation ist.
Das ist im Grunde die Standard-Vorgehensweise, die so auch in Sprachen wie C/C++ Einsatz findet, wenn die hohe Ausführungsgeschwindigkeit von Integeroperationen gewünscht wird, man aber nicht auf die Präzision von Gleitkommaoperationen verzichten will (wobei man da aber aus Optimierungsgründen mit Zweierpotenz-Faktoren rechnet).

Insofern ist dein Ansatz schon richtig, allerdings (wie schon oben gesagt) gehst du falsch in der Annahme aus, dass das Ergebnis gerundet wird. Um tatsächlich zu runden, musst du, wie CapSeb schon offenlegte, eine Korrektur vor der Konvertierung durchführen, indem du die Hälfte des Divisors hinzuaddierst.
Aufpassen musst du aber bei negativen Zahlen, denn dann musst du abziehen, statt addieren.

[Alan]

Oh, der Maker schneidet die Nachkommastellen also einfach ab? War mir auch neu - ich dachte immer, er rundet ab x,5 auf und darunter ab. Aber - man lernt nie aus! Von daher könnte es durchaus sein, dass man einmal auf den Trick von CabSeb zurückgreifen muss... ich werde ihn im Hinterkopf behalten, thx!



Greetz!


Alan