Problematisch ist aber, dass man bei schwach typisierten Sprachen wie PHP und Perl nunmal keinen Einfluss darauf hat, in welchem internen Datentyp die Zahlen abgelegt werden.

Und wenn dann noch die Darstellung intern irgendwie herumrundet (obwohl man das explizit nicht wünscht), wird’s echt blöd.

Dieses Problem hier ist lediglich ein Darstellungsproblem (und der Fehler ist wohl eher, dass PHP die Zahlen bei der Darstellung rundet, sogar bei var_dump - das ist zugegeben verwirrend).

Aber mal ehrlich: man benutzt für Preisberechnungen keine Floating Point Zahlen! Niemals. Dummerweise wird das trotzdem viel zu oft gemacht… und da redet man und erklärt man, und am Ende machen sie den Fehler doch immer wieder - ging mir gerade bei einem Projekt so

Es hilft nur lesen, lernen, verstehen:…

http://www.c2.com/cgi/wiki?FloatingPointCurrency
http://docs.sun.com/source/806-3568/ncg_goldberg.html

Input: 34.04148
Schritt 1: 680.82960
Schritt 2: 681
Schritt 3: 34.0500000000
Schritt 4: 3405.0000000000
string(15) “3405.0000000000″
Schritt 5: 3405

Wieso packst du die Zahl eigentlich in einen String?

Rein arithmetisch verhält sich o.g. Beispiel in Perl oder C natürlich genauso, und Schritt 5 würde (bei floor() statt intval()) auch “3404″ ausgeben. Nur würde ich das da auch so erwarten.

http://de.wikipedia.org/wiki/Principle_Of_Least_Surprise

PHP zeigt genau den Wert an, den die Variable haben sollte. Durch die interne Ungenauigkeit kommt es beim Abschneiden der Nachkommastellen dann leider zu dem Ungenauigkeitsfehler.

Wäre aber natürlich schöner, wenn PHP bei einem intval intern von alleine ein floor macht.

Zu der Problematik siehe auch PHP Dokumentation: http://de2.php.net/manual/de/language.types.float.php#warn.float-precision

Ich habe gerade kein JDK griffbereit, behaupte aber mal, dass Java beim PrintfFormat().sprintf() die Zahl tatsächlich “vollständig” ausgeben würde - unabhängig von der internen Rechenungenauigkeit.

Gebe nach jeder Zeile per var_dump die Variable aus, Ergebnis:

Input: $betrag\nstring(8) “34.04148″
Schritt 1: 680.8296
float(680.8296)
Schritt 2: 681
float(681)
Schritt 3: 34.05
float(34.05)
Schritt 4: 3405
float(3405)
Schritt 5: 3404
int(3404)

Was man sieht ist das selbe Float-Ungenauigkeits-Problem! Das Runden ändert den Variablentyp (natürlich) nicht auf int, sondern er bleibt bei float. In dem Moment wo du es zu int castest (und intval macht nichts anderes) fällt die Ungenauigkeit ins Gewicht.

Bei meinem 1-1-Java-Beispiel konnte man die Variablen auch ausgeben und Java behauptete auch da, dass beide Variablen den Wert 1 haben und eben nicht 0,9999…99 bzw. 1,0000…01!

Daher immer beim casten von float auf int: intval(round($var))!

Das selbe gilt für jede andere Programmiersprache!

PHP macht den Fehler, dass es eigenständig die Zahlen mit einer anderen Genauigkeit ausgibt, als es für interne Berechnungen verwendet.