T-Rex: PHP: zwei identische Zahlen vergleichen bringt ein false

Moin,

ich sehe den Fehler nicht und bitte um Hilfe ...

		var_dump( 1023.75 );
		var_dump( 985.95 );
		var_dump( 1023.75 - 985.95 );
		var_dump( 1023.75 - 985.95 == 37.8 );

Ausgabe: float(1023.75) float(985.95) float(37.8) bool(false)

Wieso ist 1023.75 - 985.95 für PHP nicht 37.8 ? Sowas hatte ich noch nie ... Ich hab nur noch Fragezeichen über meinem Kopf.

Gruß ?-???

  1. Hallo T-Rex,

      	var_dump( 1023.75 );
      	var_dump( 985.95 );
      	var_dump( 1023.75 - 985.95 );
      	var_dump( 1023.75 - 985.95 == 37.8 );
    

    Ausgabe: float(1023.75) float(985.95) float(37.8) bool(false)

    Wieso ist 1023.75 - 985.95 für PHP nicht 37.8 ? Sowas hatte ich noch nie ... Ich hab nur noch Fragezeichen über meinem Kopf.

    über die Problematik von Fließkommaarithmetik und die damit verbundenen Stolperfallen hat Janosch mal einen ausführlichen Artikel geschrieben.

    Make the most of your time
     Martin

    --
    Es gibt Tage, da gelingt dir einfach alles. Aber keine Sorge, das geht schnell vorbei.
    1. Hallo T-Rex,

        	var_dump( 1023.75 );
        	var_dump( 985.95 );
        	var_dump( 1023.75 - 985.95 );
        	var_dump( 1023.75 - 985.95 == 37.8 );
      

      Ausgabe: float(1023.75) float(985.95) float(37.8) bool(false)

      Wieso ist 1023.75 - 985.95 für PHP nicht 37.8 ? Sowas hatte ich noch nie ... Ich hab nur noch Fragezeichen über meinem Kopf.

      über die Problematik von Fließkommaarithmetik und die damit verbundenen Stolperfallen hat Janosch mal einen ausführlichen Artikel geschrieben.

      Make the most of your time
       Martin

      hmmm ... der Artikel erklärt einiges. Mich verwundert, wieso ich auf dieses Problem in den letzten 20 Jahren noch nicht einmal gestoßen bin ... naja zumindest nicht in php. In Javascript ist das wieder eine andere Sache :D.

      Ich habe es jetzt gelöst in dem ich die Berechnung runde.

      Gruß round(!-!!!)

      1. n'Abend,

        über die Problematik von Fließkommaarithmetik und die damit verbundenen Stolperfallen hat Janosch mal einen ausführlichen Artikel geschrieben.

        hmmm ... der Artikel erklärt einiges.

        nicht wahr? 😉

        Mich verwundert, wieso ich auf dieses Problem in den letzten 20 Jahren noch nicht einmal gestoßen bin ... naja zumindest nicht in php. In Javascript ist das wieder eine andere Sache :D.

        Nö, das ist in allen Programmiersprachen dasselbe, die mit IEEE-754-Fließkommaformaten arbeiten (und das sind die allermeisten).

        Ich habe es jetzt gelöst in dem ich die Berechnung runde.

        Das ist die eine Möglichkeit. Die andere ist, nicht auf Gleichheit zu prüfen, sondern die Differenz zu bilden, und den Absolutwert davon auf einen ausreichend kleinen Wert zu überprüfen.

        Make the most of your time
         Martin

        --
        Es gibt Tage, da gelingt dir einfach alles. Aber keine Sorge, das geht schnell vorbei.
      2. Hallo T-Rex,

        der Klassiker ist:

        echo 100.1 - 100.0;
        

        Rolf

        --
        sumpsi - posui - obstruxi
        1. der Klassiker ist:

          echo 100.1 - 100.0;
          

          ???

          ~> echo 100.1 - 100.0;
          100.1 - 100.0
          

          verbessern wir das:

          ~> echo '100.1 - 100.0' | bc;
          .1
          
          1. Hallo,

            der Klassiker ist:

            echo 100.1 - 100.0;
            

            ???

            Gemeint war z.B. echo 100.1-100.0

            verbessern wir das:

            Erstaunlicherweise kriegt ein Computer es trotzdem hin, wenn man ihm vorgaukelt, er sei ein Taschenrechner...

            Gruß
            Kalk

            1. Erstaunlicherweise kriegt ein Computer es trotzdem hin, wenn man ihm vorgaukelt, er sei ein Taschenrechner...

              Der dann wieder eigene Rundungsfehler produziert. Normalerweise rechnet ein Taschenrechner mit dem weiter, was er anzeigt.

              Lustig wird das bei programmierbaren Rechnern, die sich mal so und mal so verhalten, also bei der Taschenrechner-Nutzung mit den angezeigten Stellen rechnen, im Programm dann aber je nach Programmiersprache. (Ich hatte mal einen, der konnte ein BASIC-Derivat…)

          2. Hallo Raketentester,

            ja, sorry, das Forum zeigt nicht an, dass ich dieses Code-Snippet als PHP markiert hatte.

            Und bc rechnet nicht in IEEE754, die man-Page sagt:

            Numbers are arbitrary precision numbers. This precision is both in the integer part and the fractional part. All numbers are represented internally in decimal and all computation is done in decimal.

            D.h. es verwendet eine eigene, nicht von der Hardware unterstützte Zahlendarstellung und ist demnach für die Fragestellung des Threads nicht repräsentativ.

            DATA DIVISION.
            WORKING-STORAGE SECTION.
            01  RESULT    PIC ZZZ9.99999;
            
            PROCEDURE DIVISION.
                COMPUTE RESULT = 100.1 - 100.0.
                DISPLAY RESULT.
                STOP RUN.
            

            gibt auch 0.1 aus (genauer: ___0.10000). Weil COBOL im Normalfall mit COMPUTATIONAL-3 (gepackte Zahlen, ein BCD-Format) rechnet und die Ausgabe gerundet ist. Auch nicht repräsentativ 😉

            Rolf

            --
            sumpsi - posui - obstruxi