kleine Rundungsfrage

[Andreas Korthaus]

Hoi!

Andreas Lindig ist weitgehend mit Dir einverstanden, siehe https://forum.selfhtml.org/?t=92388&m=557019.

hmm, verblueffend wie sehr das verlinke posting meinen worten gleicht. evtl. liegt es daran, dass es meine worte sind. ;-)

Vielleicht ein 2. Ich? ;-)

hier ist doch die einzige voraussetzung, dass die anzahl der vorkommastellen nicht zu hoch ist.

Sehr schön, dass Du Einschränkungen machst :-)

die je nach anwendungsbereich (wurde jener eigentlich schon explizit irgendwo genannt?) irrelevant sind.

Also, die DB-Felder für die Werte mit denen gerechnet wird, haben alle DECIMAL (20,10), das heißt insgesamt 20 Stellen, davon 10 Nachkommastellen. In der Praxis werde nicht alle verwendet werden, aber 12 Stellen werden durchaus vorkommen, im Extremfall vielleicht 15. Bei dem konkreten Problem geht es darum, dass ich ein Feld vorbelegen will, und zwar mit der nächst möglichen, kleineren Zahl. Ich habe z.B. irgendwas gerechnet, und habe dann in PHP ein Ergebnis von 1.999999999. Jetzt soll der nächst mögliche niedrigere, auf 2 Nachkommastellen beschränkte Wert ausgegeben werden, also 1.99, bzw. 1,99. Die Anzahl der Nachkommastellen ist nicht fest, sondern kann zwischen 0 und 10 liegen. Meistens sind es 2-5. Hierbei darf ich mich nicht verrechnen, denn wenn jetzt aus Versehen ein Wert von 2,00 eingetragen würde, dann würde dieser am Ende durch die Validierung fallen, und es gibt eine häßliche Fehlermeldung. Bei den konkreten Zahlen sehe ich noch kein Problem, Aber was wenn man sowas hat wie

12,345,678.12345 ?

auf http://www.php.net/manual/en/language.types.float.php steht geschrieben: "The size of a float is platform-dependent, although a maximum of ~1.8e308 with a precision of roughly 14 decimal digits is a common value (that's 64 bit IEEE format)"
14 stellen... bei den meisten anwendungen sollte also diese einschraenkung keine rolle spielen. ansonsten ist von konventionellen float abzuraten.

"precision of roughly 14 decimal digits" von diesem _roughly_ bekomme ich ja gerade meine Bauchschmerzen ;-)

ich sehe das risiko bei *100 und /100 nicht (abgesehen von den bereits genannten langen zahlen). vorteil koennte neben der bequemlichkeit die geschwindigkeit sein. wie viele zahlen sollen denn gerundet werden?

Performance ist absolut vernachlässigbar.

hmm, wobei die zahlen ja zunaechst als string (aus der datenbank) vorliegen, oder?

ja, und damit wird gerechnet. Oder es wird schon in der DB gerechnet (im SQL-Statement), ich weiß gar nicht wieviele Nachkommastellen dann zurückgegeben werden.

und wieder draengt sich mir die frage nach der anwendung auf.

immer noch?

Grüße
Andreas