Mehr als 15stellige Euro- aber auch Centbeträge darf man bei einem Kassenbuch wohl durchaus als unrealistisch betrachten
. Grundsätzlich hat Excel aber auch kein Problem damit Zahlen mit noch mehr Stellen richtig zu verrechnen. Lediglich mit der Darstellung und wenn man sich rein auf die Formelebene beschränkt kann es mit so großen Zahlen eben zu Problemen kommen.
Auch wenn es in Excel eben standardmäßig leider nicht vorgesehen ist mehr als 15 Stellen einer Dezimalzahl darzustellen, kann man damit genauer rechnen (zumindest mit bis zu 29 Stellen). Allerdings geht das dann eben nicht mehr ohne die bereits diskutierten workarounds wie die Umwandlung in Strings bzw. die VBA-Nutzung.
Das ist meines Erachtens aber der Ausrichtung des Programms geschuldet, denn Excel wendet sich ja nicht primär an Naturwissenschaftler, sondern ist eine Mainstream-Software die mehrheitlich für viel simplere Zwecke genutzt wird. Allein die Tatsache, dass Matrixfunktionen nutzbar sind, dürfte der überwiegenden Mehrheit der Excel-User nicht mal bekannt sein.
Mit der Möglichkeit VBA-Makros zu nutzen, lässt sich die Stellenbegrenzung jedenfalls auf 29 Stellen ausweiten. Speziell wenn bei reiner Formelschreibweise bereits Matrix-Formeln notwendig sind, ist es aber ohnehin empfehlenswert auf VBA-Makros zu setzen, da die Rechenzeiten sonst vor allem bei komplexeren Tabellen mit mehreren Matrix-Funktionen und/oder großen Arrays, sogar mit schnellen Rechnern absurd lang werden können. Excel rechnet ja immer die ganze Mappe durch. Hab jedenfalls schon Tabellen gehabt, die deshalb fast unbedienbar wurden, wenn man nicht die automatische Berechnung abgeschaltet, oder ggfls. die Iterationstiefe beschränkt hat. Große Arrays sollte man in Excel deshalb immer mittels VBA-Makros verrechnen - oder sie noch besser einfach vermeiden. Für so was gibt´s wirklich bessere Programme.
Für die Rundungsproblematik beim Kassenbuch ist das aber wie gesagt nicht wirklich relevant und wenn man in Cent rechnet fällt die Genauigkeitsbeschneidung bei den Nachkommastellen eben auch nicht mehr ins Gewicht.
Wenn man Genauigkeitsbeschränkungen bestmöglich vermeiden will, muss man halt professionellere Software verwenden und im Vorfeld vernünftige Abschätzungen treffen welche Genauigkeit überhaupt benötigt wird. Spätestens bei der Verrechnung irrationaler Zahlen (z. B. Zahlen wie Pi oder e, aber auch bei Dezimalzahlen mit periodischen Nachkommastellen) stößt man aber eigentlich immer an Grenzen. Da hilft es nur auf algebraische Methoden auszuweichen (z. B. mit Hilfe von MathCad).
