Warum manche Rechen-Apps mit den Nachkomma-Stellen seine Probleme haben
Zuerst möchte ich mich kurz für die vielen positiven Bewertungen/Reaktionen zum „Mobilen MwSt-Rechner” (iPhone/iPad) bedanken. Die Bewertungen sind für mich ein absoluter Ansporn die App weiter zu entwickeln und mit neuen Funktionen zu versehen. Vielen Dank dafür :-)
Aber nun zum eigentlichen Grund für den Blog-Eintrag. Zwei Kommentatoren hab in den letzten Tagen folgendes geschrieben:
Perfekt — Läuft einwandfrei auf Pad und Phone. Habe von *App* (Name der App entfernt) gewechselt, da *App* FALSCH rechnet. (Hosale)
Für jeden der mit MwSt- und Prozent rechnen muss, eine absolute Empfehlung! Eines der wenigen Apps, die beim Runden nicht ins straucheln kommt. (_BüroMensch_)
Hierzu möchte ich heute doch etwas schreiben. Auch wenn erfahrene Entwickler den Grund für die Ungenauigkeit bei der Berechnung von Kommazahlen kennen (bzw. kennen sollten), dürften auch normale Nutzer das Thema sicherlich interessieren.
Viele Entwickler nutzen in ihren Anwendung zum verarbeiten von Komma-Zahlen den Speicher-Typ Float (Gleitkommazahl). Der Datentyp erlaubt das einfache verarbeiten sowie speichern von Komma-Zahlen und Berechnungen sind ebenso einfach durchzuführen. Ein weiterer Vorteil ist, dass der Datentyp praktisch in allen Programmiersprachen vorkommt. Dies ist auch der Grund, warum oft bei Float von einem „primitiven Datentyp” die Rede ist. Was würde also näher liegen als Float zu verwenden. Selbst die in Computern und natürlich auch Smartphones verbauten CPUs sind für das schnelle durchführen von Float-Berechnungen optimiert und Benchmarks geben oft die Leistung eines Prozessors in FLOPs (Anzahl der Float-point Operationen je Sekunde) an.
Man darf bei der Verwendung von Float allerdings nicht vergessen, dass nicht in jedem Fall dieser Datentyp angebracht ist. Float arbeitet intern nur mit einer bestimmten Anzahl von Stellen (abhängig vom unter anderem vom Prozessor) und verarbeitet die Zahlen als Binär-Werte. Beides zusammen führt dazu, dass bei Berechnungen Float-Werte ungenau werden können, was einigen Entwicklern nicht bewusst ist (mehr technische Details). Gerade in Einsteiger-Literatur wird auf diese Problematik nicht immer hingewiesen.
Für Berechnungen von Grafiken oder ähnlichem sind diese kleinen Ungenauigkeiten in der Regel kein Problem. Aber im Finanzbereich ist Float ein absolutes No-Go, da die kuriosesten „Rechenfehler” auftreten können. Aus diesem Grund bieten die meisten modernen Programmiersprachen spezielle Datentypen die z.B. für Finanz-Berechnungen eine sehr hohe Genauigkeit bietet. Im Fall iOS-Anwendungen sollte man die Zahlen als NSDecimalNumber und bei Java als BigDecimal Objekt verarbeiten und beachten, dass der gewählte Werte-Bereich nicht überschritten wird.
Die Float-Problematik ist nur einer von vielen Fallstricken die beim Entwickeln einer Anwendung auftreten können. Auch wenn ich mir von Anfang an der Problematik mit „Float” bewusst war, so bin auch ich mit meiner App auch in die ein- oder andere Falle getappt. Dies lässt sich nicht vermeiden. Das richtige runden, das beachten der unterschiedlichen Dezimal-Schreibweisen (Punkt/Komma) sowie das „überleben” eines Wechsels zwischen beiden Schreibweisen sind nur einige der beliebtesten Fehlerquellen.
Da solche Fehler einfach passieren können und selbst z.B. automatisierte Tests während dem erzeugen der Anwendung sowie umfangreiche Beta-Tests Fehler nie ganz verhindern, so möchte ich einfach als App-Entwickler folgende Bitte anbringen: Solltet Ihr bei einer App bzw. normalen Anwendung einen Fehler finden, so kontaktiert bitte immer zuerst den/die Entwickler bevor Ihr eine Bewertung schreibt. Der Hintergrund ist einfach, dass bei „Bewertungen” im z.B. iTunes oder Google Play Store keine Möglichkeit existiert dem Nutzer zu antworten. Eventuelle Rückfragen oder Hilfestellungen zum Problem sind auf Bewertungen in den App-Stores nicht möglich obwohl in vielen Fällen damit eventuelle Probleme ausgeräumt werden könnten. Eine direkte Kontaktaufnahme ist daher einfach für beide Seiten von Vorteil.