Vermutlich ältester GM-Bug. Bitte testen!

    • Original von Nobody-86
      ich habe das experiment jetzt nicht gemacht, da ich auch winxp home besitze und es warscheinlihc das gleiche ergebniss geben wird. aber mir komt da eine vermutung auf, kan sie allerdings noch nicht beweisen bzw. überhaubt aufstellen da ich nciht weiß wie die zahk 0.2 als binärzahl aussieht. möglicherweise ist es eine sehr ungenaue zahl, bei der die nachkommastellen fehler auftreten ohne das man was dagegen machen kan.
      was dagegenspricht ist natürlich die akktuelle erkentniss das es auf ME wohl ohne probleme zu gehen scheint.

      Meines Erachtens nach spricht das mit ME nicht zwingend dagegen.
      Ich kenne die genaue Implementation nicht, aber evtl. benutzt der GM auf ME nen größeren float.

      Außerdem denke ich, dass dieses Problem unter die Kategorie "It's not a bug, it's a feature!" fällt, da es nunmal eine Eigenschaft von Floats ist.

    • Hab noch mal geschaut. Diese Ungenauigkeit fängt auch schon beim ersten Addieren an, allerdings zeigt der Debugger das nicht an, der scheint bis 1,4 zu runden.

      Hier auch mal die Datei mit der das geprüft werden kann, lasst euch im Debugger object0.testvar anzeigen und beobachtet analog den gezeichneten Wert.
      Dateien

      • realtest.zip

        (1,65 kB, 200 mal heruntergeladen, zuletzt: )
      "Die Erde ist ein Irrenhaus. Dabei könnte das bis heute erreichte Wissen der Menschheit aus ihr ein Paradies machen. Dafür müsste die weltweite Gesellschaft allerdings zur Vernunft kommen."
      - Joseph Weizenbaum

    • Hier noch das C/C++ Pendant zu Windapples "Spiel": (Die Datei im Anhang ist die Win32.exe dieses Programms.

      Quellcode

      1. #include <stdio.h>
      2. int main() {
      3. float foo, bar;
      4. foo = 0.0;
      5. bar = 0.2;
      6. while(foo < 30.0) {
      7. foo += bar;
      8. printf("%.20f\n", foo);
      9. }
      10. scanf("%f", foo);
      11. }
      Alles anzeigen


      Daran sieht man sehr schön, dass es eine Eigenart der floats ist.

      Eine Lösung wäre eventuell, die Zahl mit dem Kehrwert einer angegebenen Genauigkeit zu multiplizieren, dann zu runden und wieder mit der Genauigkeit malzunehmen.

      Hier das Script dazu:

      GML-Quellcode

      1. //argument0: zu rundende Zahl
      2. //argument1: Genauigkeit
      3. return round(argument0/argument1)*argument1;


      Edit: Man kann dieses Script dann z.B. folgendermaßen aufrufen:
      "scr_runde_float(1.4000001, 0.0001)"
      Das Ergebnis wäre dann 1.4000.

      Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von Agnahim ()

    • Benutzer online 1

      1 Besucher