Je kunt het probleem overigens ook oplossen door niet (alleen) de uitkomst op te slaan, maar tevens de oorspronkelijke aantallen en prijzen per stuk.
haha dat is precies waarom mijn systeem goud waard is volgens belastingdienst:P
in mijn boekhoudsoftware worden de bedragen waarmee gerekend moet worden opgeslagen in de database
en het script die ik heb gemaakt doet de rest in samenwerking met een cache systeem
anders duurt het rekenen heeeeeeeeeeeeeel lang
daarin staat precies wat ik dus ook zeg
[/quote]
Nee, daar staat iets heel anders. Er staat niet dat je tussentijds moet/mag afronden op 3 decimalen, maar alleen dat wanneer het onafgeronde bedrag meer dan 2 decimalen bevat, je bij het afronden op basis van de derde decimaal moet bepalen of je de tweede decimaal naar boven of naar beneden afrondt.
Tussentijds afronden, op hoeveel decimalen dan ook, kan altijd tot een 'verkeerde' afronding leiden. Stel dat je het bedrag 7,1445 afrondt op 3 decimalen. Je krijgt dan 7,145, wat bij afronding op 2 decimalen leidt tot 7,15. Terwijl het op basis van het onafgeronde bedrag 7,14 zou moeten zijn.
De kans dat je bij de tweede decimaal afrondingsverschillen krijgt neemt wel af als je tussentijds afrondt op drie decimalen, maar hij is dus niet nul. Het is daarom altijd het beste om te werken met onafgeronde getallen (of op zijn minst een stuk meer dan 3 decimalen te gebruiken). Waarom denk je dat Bitcoins tot op 8 decimalen nauwkeurig worden opgeschreven? En er zijn cryptocurrencies die nog veel preciezer worden uitgedrukt; de handelssites rekenen intern vaak al met 24 decimalen.
