[alg] Geldbedragen opslaan en bewerken

[flowerp]

Ik vroeg me af hoe de mensen hier in hun code met geld bedragen omgaan ivm de machine onnauwkeurigheid. Dit is eigenlijk een vrij bekend probleem, en er is dan ook enorm veel al over geschreven. Echter die hoeveelheid materiaal is ook een beetje het probleem. Via google stuit ik op talloze papers over de voordelen of juist nadelen van bijvoorbeeld binary coded decimals (BCD). Volgens de ene is het de oplossing van alle problemen, maar volgens de andere maskeer je het echte probleem juist en geven floats bij dezelfde aantal bits altijd de effecientste nauwkeurigheid.

Al die theoretische verhandelingen zijn erg interesant, maar wat doet iedereen nu in de praktijk?

Als ik nu bijvoorbeeld bedragen als floats opsla in de DB als duizendste centen, dan zou ik toch bijna nooit een probleem moeten hebben?

Dus, 1 cent = 1000 in de DB. In de range van 0 t/m 0.001 cent heb ik dan geen onnauwkeurigheid, en beneden die grens ben ik aan het binaire deel stelsel overgeleverd hoe exact ie een specificiek bedrag kan weergeven.

Nu lijkt me dit systeem bijna -te- simpel. Zie ik iets over het hoofd? Als het zo simpel was dan zou je zeggen dat er geen complete boeken over dit onderwerp geschreven hoeven te worden. Dus wat mis ik?

[Spixo]

Alles opslaan in centen? Dus 1,39 euro is gewoon 139 cent.

[MTWZZ]

Je zou eens kunnen kijken of er wetgeving of regelgeving is op dit gebied. Dat moet haast wel omdat banken ook met dit soort problemen te maken hebben.
Verder is het maar de vraag hoeveel zekerheid je wil hebben. Je kunt wel een cent in duizendste centen in de database opslaan maar dan ga je zeker problemen krijgen met grote bedragen en de limieten op datatype in je database (denk een miljoen)

[eamelink]

flowerp schreef op zondag 14 mei 2006 @ 20:35:
Al die theoretische verhandelingen zijn erg interesant, maar wat doet iedereen nu in de praktijk?

Waarschijnlijk alles opslaan in centen; dan heb je nooit een probleem toch? Hooguit bij dingen waar je een fractie van een geldbedrag nodig hebt (korting, BTW, dat soort fratsen), maar dan kan je gewoon weer afronden naar die centen.

Bij de belastingdienst ronden ze alles af naar hele euro's. Das nog makkelijk, al is het voor kleine bedragen niet altijd even praktisch

Dus, 1 cent = 1000 in de DB. In de range van 0 t/m 0.001 cent heb ik dan geen onnauwkeurigheid, en beneden die grens ben ik aan het binaire deel stelsel overgeleverd hoe exact ie een specificiek bedrag kan weergeven.

Mag ik vragen wat je aan het doen bent als je bedragen gebruikt die mogelijk kleiner zijn dan 1/1000 cent? . In de echte wereld is er zoiets sowieso niet; er wordt gewoon afgerond. Dus de onnauwkeurigheid in computers is helemaal geen probleem. 1 euro gedeeld door 3 is 33 cent. En dat was vroeger op papier ook zo

[flowerp]

MTWZZ schreef op zondag 14 mei 2006 @ 20:38:
Je zou eens kunnen kijken of er wetgeving of regelgeving is op dit gebied. Dat moet haast wel omdat banken ook met dit soort problemen te maken hebben.

Dat zal er gerust wel zijn ja, maar ik verwacht niet echt dat zoiets heel toegankelijk is. Een beetje googlen levert iniedergeval niet hele concrete practische dingen op.

Verder is het maar de vraag hoeveel zekerheid je wil hebben. Je kunt wel een cent in duizendste centen in de database opslaan maar dan ga je zeker problemen krijgen met grote bedragen en de limieten op datatype in je database (denk een miljoen)[/quote]

Ik zit inderdaad al naar dit laatste te kijken. Als ik in 1000ste centen opsla dan is bij een 64 bits datatype het maximale bedrag nog steeds enkele miljarden. Als ik dergelijke bedragen in mijn DB krijg dan kan ik wel een heel team aan wiskundigen gaan inhuren. (waarmee ik dit tegenovergestelde probleem absoluut niet wil afwimpelen, maar bedragen van enkele miljarden is absoluut een 100% veilige bovengrens in elke denkbare business case)

[flowerp]

eamelink schreef op zondag 14 mei 2006 @ 20:55:
[...]
Waarschijnlijk alles opslaan in centen; dan heb je nooit een probleem toch? Hooguit bij dingen waar je een fractie van een geldbedrag nodig hebt (korting, BTW, dat soort fratsen), maar dan kan je gewoon weer afronden naar die centen.

Het gaat om een soort online boek lees systeem waar er betaald wordt per gelezen blz (don't ask, de klant wil dit). Voor elke gelezen blz van het boek gaan er diverse vergoedingen naar diverse partijen (autheur, de publisher, en naar de partij die het systeem in de lucht houdt (wij dus). Het gaat hier dus om zeer veel fracties en erg kleine bedragen.

Op slaan in centen kan niet omdat een requirement al is dat de vergoeding per blz al minder als een cent kan zijn. Daarbij, ik heb even snel doorgerekend dat als ik met 10de centen reken het verschil over een hele maand bij slechts een paar klanten al een euro of 50 kan zijn. Ik heb dus zeker een hogere nauwkeurigheid nodig, maar dat was eigenlijk niet de vraag.

De vraag was (andersom beredeneerd), sla ik een duizendste cent op als 1 in de DB, gebruik ik een float (zodat het 0,001 wordt in de DB) of gebruik ik de combinatie duizendste cent + float (zodat die duizendste cent 1.0 wordt in de DB).

Natuurlijk is 1000'ste nu een redelijk willekeurig getal. 10de is te onnauwkeurig, maar het zou ook 100ste of 10.000ste kunnen worden.

[Verwijderd]

flowerp schreef op zondag 14 mei 2006 @ 21:11:
[...]
De vraag was (andersom beredeneerd), sla ik een duizendste cent op als 1 in de DB, gebruik ik een float (zodat het 0,001 wordt in de DB) of gebruik ik de combinatie duizendste cent + float (zodat die duizendste cent 1.0 wordt in de DB).

Natuurlijk is 1000'ste nu een redelijk willekeurig getal. 10de is te onnauwkeurig, maar het zou ook 100ste of 10.000ste kunnen worden.

Als je gegarandeerde nauwkeurigheid wilt houden, dan gebruik je nooit, maar dan ook nooit floats.

Sterker nog, als je wel floats gebruikt verschuif je het probleem gewoon: je kunt dan wel duizendste centen op gaan slaan als hele getallen (€0,00001 = 1.0), maar je nauwkeurigheid is precies hetzelfde als bij €0,00001 = 0.00001).

Gebruik in plaats daarvan integers, en plaats ze op een schaal die voldoet aan de grootte van de gegevens waar jij mee te maken hebt. Dus, €0,00001 = 1, €0,01 = 1000, etc). Optellen, vermenigdvuldigen etc. zijn gegarandeerd correct en je krijgt geen afrondfouten. Bij het nemen fracties verlies je wel precisie, maar die is waarschijnlijk beheersbaar en zal nooit meer dan een paar centen bedragen, afhankelijk van de schaal die je kiest.

[Soultaker]

Verwijderd schreef op zondag 14 mei 2006 @ 21:31:
Sterker nog, als je wel floats gebruikt verschuif je het probleem gewoon: je kunt dan wel duizendste centen op gaan slaan als hele getallen (€0,00001 = 1.0), maar je nauwkeurigheid is precies hetzelfde als bij €0,00001 = 0.00001).

Nee, het eerste is wel degelijk nauwkeuriger, omdat je 1.0 wél exact in een float of double kunt representeren en 0,00001 (of al 0,1 for that matter) niet.

Denk er wel aan dat je dan wel doubles moet gebruiken, want single precision floats hebben een 23-bits mantissa, wat goed is voor een schamel maximum van 83 euro (uitgaande van 1,0 is een duizendste cent). Met de 52-bits mantissa van de double kom je op 45 miljard euro maximaal; vermoedelijk voor dit doel wel voldoende.

Gebruik in plaats daarvan integers, en plaats ze op een schaal die voldoet aan de grootte van de gegevens waar jij mee te maken hebt. Dus, €0,00001 = 1, €0,01 = 1000, etc). Optellen, vermenigdvuldigen etc. zijn gegarandeerd correct en je krijgt geen afrondfouten. Bij het nemen fracties verlies je wel precisie, maar die is waarschijnlijk beheersbaar en zal nooit meer dan een paar centen bedragen, afhankelijk van de schaal die je kiest.

Dit is wel een goed advies. Verder hebben veel databases (juist om geld op te slaan) een ingebouwd 'decimal' type met een vast aantal decimale getallen achter de komma dat je ook kunt gebruiken. Als je je berekeningen dan zoveel mogelijk in de database doet, bespaar je jezelf een hoop gedoe.

[kenneth]

Welke backend gebruik je? Verschillende DBMSen hebben fixed point datatypes zonder onnauwkeurigheid, bijv decimal in MSSQL.

[DroogKloot]

flowerp schreef:
(...)

Al die theoretische verhandelingen zijn erg interesant, maar wat doet iedereen nu in de praktijk?

(...)

Fixed-point decimals gebruiken als met fractionele machten van 2 kan worden gerekend, en BCD's waar fractionele machten van 10 vereist zijn. Wat betreft het "maskeren" van het echte probleem, er is fundamenteel uberhaupt geen oplossing voor (hoe representeer je oneindige precisie met een eindig aantal bits? antwoord: niet), dus elke praktische aanpak zal dat in meer of mindere mate doen. Er wordt in serieuze applicaties in ieder geval NOOIT met de standaard real datatypes gewerkt.

[ Voor 10% gewijzigd door DroogKloot op 14-05-2006 21:44 ]

[flowerp]

Soultaker schreef op zondag 14 mei 2006 @ 21:41:
[...]
Nee, het eerste is wel degelijk nauwkeuriger, omdat je 1.0 wél exact in een float of double kunt representeren en 0,00001 (of al 0,1 for that matter) niet.

Inderdaad, dat was dus ook mijn stelling in de openings post. Binnen die range kan ik iniedergeval de opgegeven bedragen bedragen exact bewaren. Met enkel (double precision) floats zou dat nooit lukken. Zodra er percentages genomen gaan worden weet je natuurlijk nooit meer of het past.

kenneth schreef op zondag 14 mei 2006 @ 21:41:
Welke backend gebruik je? Verschillende DBMSen hebben fixed point datatypes zonder onnauwkeurigheid, bijv decimal in MSSQL.

De DBMS is PostgreSql 8.1. De application server is Jboss met eventueel glassfish als een optie (hoewel ik niet denk dat de AS belangrijk is voor dit probleem). Iniedergeval vinden er ook berekeningen in Java plaats, dus welk type het ook wordt het moet wel mappen naar een Java type via EJB3 (of eventueel plain old JDBC).

is fundamenteel uberhaupt geen oplossing voor (hoe representeer je oneindige precisie met een eindig aantal bits? antwoord: niet)

Dit gaat eigenlijk mijn kennis te boven, maar ik kan me voorstellen dat je een oneindige precisie in gevallen best eindig kunt opslaan door de formule op te slaan. Bijvoorbeeld 1/3 sla je niet op als 0.333333333... maar gewoon als 1/3. Ik meen dat wiskundige paketten het ook zo aanpakken, maar zou er ook financiele software zijn die het zo aanpakt?

[GlowMouse]

Kun je niet beter bijhouden hoeveel elke pagina door elke partij is bekeken, en achteraf met erg hoge precisie alles doorrekeken? In je database komen dan misschien vrij veel records, maar elk record neemt weinig in en je kunt achteraf de precisie nog veranderen.

[ZroBioNe]

eamelink schreef op zondag 14 mei 2006 @ 20:55:
Bij de belastingdienst ronden ze alles af naar hele euro's. Das nog makkelijk, al is het voor kleine bedragen niet altijd even praktisch

Ze ronden af naar boven hoor

[flowerp]

GlowMouse schreef op zondag 14 mei 2006 @ 22:08:
Kun je niet beter bijhouden hoeveel elke pagina door elke partij is bekeken, en achteraf met erg hoge precisie alles doorrekeken? In je database komen dan misschien vrij veel records, maar elk record neemt weinig in en je kunt achteraf de precisie nog veranderen.

Ongeveer zo gebeurd het al in de code, en ik verwacht inderdaad veel records. Het is dus niet zo dat voor elke gelezen pagina het bedrag meteen doorgerekend wordt. Maar de bedragen moeten dus wel een keertje worden opgeslagen. Voor verschillende boeken gelden verschillende vergoedingen en ook verschillende percentages. Iedereen wil zowel totaal bedragen zien als bedragen uitgesplitst per boek, per auteur, per genre, etc.

In het simpelste geval heb je in het begin waarin iemand een bedrag gaat instellen. Op dat moment word er nog niets gerekend, is gewoon een pure store. Bv, boek A van auteur B is 0.06 cent / pagina. Die 0.06 cent moet dus al ergens staan.

Zoals al duidelijk was, direct als float opslaan is niet zo handig. Vandaar dus de vraagstelling hoe dit dan het beste op te slaan. Voorlopig heb ik wel redelijk bevestigd gekregen hier (met dank aan alle! ) dat double precision floats gebruiken waarbij 1 cent als 1000 in de DB staat toch wel een redelijke oplossing is.

In een wat complexere situatie wil 1 van de partijen een vaste vergoeding vergoeding hebben, maar het systeem werkt met percentages. Dus als iemand 0.03 cent wil, dan is dat precies 50% en dus makkelijk op te slaan, maar als iemand het 'onschuldige' bedrag van 0.034 wil dan kan ik het percentage al niet meer exact op slaan, want dat is 0,56666666... Daarbij is het dus zaak om ook percentages zo nauwkeurig mogelijk op te slaan.

[GlowMouse]

ZroBioNe schreef op zondag 14 mei 2006 @ 22:35:
[...]
Ze ronden af naar boven hoor

_{De belastingdienst rondt altijd in jouw voordeel af. Kosten worden naar beneden, voordelen naar boven afgerond.}

Ongeveer zo gebeurd het al in de code, en ik verwacht inderdaad veel records. Het is dus niet zo dat voor elke gelezen pagina het bedrag meteen doorgerekend wordt. Maar de bedragen moeten dus wel een keertje worden opgeslagen.

Het doorrekenen kun je dus met zeer hoge precisie doen, en het opslaan met wat minder. Van belang is het hoeveel keer je die opgeslagen dingen vervolgens nog gaat optellen of vermenigvuldigen. Zul je nog 1000 van die dingen optellen, zijn duizendsten centen geen slechte keuze om in op te slaan.

[kunnen]

Vreemd ideetje dat natuurlijk volkomen onpraktisch is en tegen het idee achter databases ingaat:
varchar datafield gebruiken en er de breuk in opslaan? (Die je dan @ runtime parst)

Zo heb je geen sorting en SUM() e.d., maar je hebt wel oneindige nauwkeurigheid. Desnoods gebruik je ook de andere voorstellen, en dit om uiteindelijk de bedragen over te maken.

[ Voor 36% gewijzigd door kunnen op 14-05-2006 23:08 ]

[whoami]

Pulsher schreef op zondag 14 mei 2006 @ 23:06:
Vreemd ideetje dat natuurlijk volkomen onpraktisch is en tegen het idee achter databases ingaat

Waarom zou je het dan zo doen ?
Zeker omdat een serieuse DBMS toch een 'decimal' type heeft; en anders kan je nog altijd de boel in centen of preciezer oid opslaan.

maar je hebt wel oneindige nauwkeurigheid.

En een DB met prut in.

dus welk type het ook wordt het moet wel mappen naar een Java type

Java heeft toch ook een decimal type mag ik hopen ?
Postgres heeft, na een vlugge zoektocht ook een decimal/numeric datatype.

[ Voor 54% gewijzigd door whoami op 14-05-2006 23:11 ]

[purge]

Wellicht dat ik een stukje heb gemist maar wat was de reden dat je bedragen op wilt slaan in de database? Je zal hier vast een reden voor hebben maar zoals ik al zei is mij dit even ontgaan. Zoals ik het zie is het de bedoeling om af te rekenen obv "aantal gelezen pagina's". Mij lijkt het zinvol om dit aantal op te slaan in de database en de berekening naar valuta op applicatie niveau te berekenen en weer te geven. Verder zou je reeds betaalde valuta op kunnen slaan op een van de manieren die reeds eerder werd geopperd (hele centen of anders).
Ik hoop dat je hier iets aan hebt.

[flowerp]

purge schreef op maandag 15 mei 2006 @ 00:12:
Wellicht dat ik een stukje heb gemist maar wat was de reden dat je bedragen op wilt slaan in de database?

Omdat er niet met vaste bedragen gerekend wordt die je in de code kunt zetten oid, maar de verschillende gebruikers van het systeem kunnen per boek zelf een vergoeding instellen, en waar wil je die ingevoerde vergoeding anders opslaan? In het geheugen? Dat is natuurlijk absoluut niet handig, want bij een restart ben je alles kwijt. En ook zal zou je het in het geheugen opslaan, dan moet je ook daar er nog een representatie voor vinden.

[RobIII]

flowerp schreef op maandag 15 mei 2006 @ 00:18:
[...]


Omdat er niet met vaste bedragen gerekend wordt die je in de code kunt zetten oid, maar de verschillende gebruikers van het systeem kunnen per boek zelf een vergoeding instellen, en waar wil je die ingevoerde vergoeding anders opslaan? In het geheugen? Dat is natuurlijk absoluut niet handig, want bij een restart ben je alles kwijt. En ook zal zou je het in het geheugen opslaan, dan moet je ook daar er nog een representatie voor vinden.

Huh
Je hangt een bedrag per gelezen pagina aan een boek. Je houdt bij welke klant welke pagina's leest. Dan kun je toch na afloop met een simpele join en een sum van die pagina's het bedrag berekenen? Daarvoor hoef je ze echt niet op te slaan hoor? Bedenk wel dat je op het moment van afrekenen het uiteindelijke bedrag dient op te slaan, mocht de prijs per pagina naderhand wijzigen. Ander kun je het oude bedrag nooit meer achterhalen. En, erger: als de klant nu wat pagina's leest voor bedrag X, en jij wijzigt naar Y morgen en de klant leest overmorgen verder dan heeft hij recht op bedrag X en niet Y voor de eerst gelezen pagina's. Daarvoor zou je een soort bedrag-per-pagina-historie kunnen bijhouden waarop je die join dan los laat.
Hoe dan ook hoef je geen mini-centen op te slaan in je DB, enkel de uiteindelijke bedragen op het moment van afrekenen. En afrekenen doen we nog altijd in max. 2 decimalen en da's prima te doen in een decimal (of desnoods een int ofzo in centen).

[ Voor 9% gewijzigd door RobIII op 15-05-2006 00:32 ]

[purge]

flowerp schreef op maandag 15 mei 2006 @ 00:18:
[...]

Omdat er niet met vaste bedragen gerekend wordt die je in de code kunt zetten oid, maar de verschillende gebruikers van het systeem kunnen per boek zelf een vergoeding instellen, en waar wil je die ingevoerde vergoeding anders opslaan?

Wellicht een onhandige optie maar in plaats van het opslaan van de valuta welke is ingevoerd deze omrekenen naar het aantal pagina's per valuta eenheid. Op deze manier sla je (indirect) de valuta toch op zonder verlies van nauwkeurigheid. (tja mss ranzig). Verder zag ik het type decimal hierboven voorbij komen waarbij je zelf de nauwkeurigheid kan bepalen.

whoami schreef op zondag 14 mei 2006 @ 23:07:
[...]

Postgres heeft, na een vlugge zoektocht ook een decimal/numeric datatype.

Zelf denk ik dat het veldtype decimal/numeric (oid) het meest voldoet aan je vraag.

[Paitor]

Ik dacht uit mijn hoofd, dat als je kleinste eenheid bijvoorbeeld een cent is, je een nauwkeurigheid van tienden van centen moet kiezen. Omdat je dan tienden nauwkeurig kan weergeven en centen exact. Op die manier kan je nooit in de knoop raken.

[Verwijderd]

eamelink schreef op zondag 14 mei 2006 @ 20:55:
In de echte wereld is er zoiets sowieso niet; er wordt gewoon afgerond. Dus de onnauwkeurigheid in computers is helemaal geen probleem. 1 euro gedeeld door 3 is 33 cent. En dat was vroeger op papier ook zo

Probeer die wijsheid eens toe te passen op een vat olie...

[flowerp]

RobIII schreef op maandag 15 mei 2006 @ 00:31:
[...]

Huh
Je hangt een bedrag per gelezen pagina aan een boek. Je houdt bij welke klant welke pagina's leest. Dan kun je toch na afloop met een simpele join en een sum van die pagina's het bedrag berekenen? Daarvoor hoef je ze echt niet op te slaan hoor?

Huh?

Stel: systeem vraag iemand een vergoeding in te voeren
Gebruiker voegt in: 0.003

Waar gaat deze 0.003 dan volgens jou heen? Deze invoer kan toch niet magisch in de lucht blijven hangen?

[RobIII]

flowerp schreef op maandag 15 mei 2006 @ 20:33:
[...]


Huh?

Stel: systeem vraag iemand een vergoeding in te voeren
Gebruiker voegt in: 0.003

Waar gaat deze 0.003 dan volgens jou heen? Deze invoer kan toch niet magisch in de lucht blijven hangen?

Boek = 215 pagina's
Bedrag voor dat boek = 0.65 euro

Hoeveel is dat dan per pagina?

Maar dat bedoelde ik niet. 0.003 cent kun je prima in een money/currency field opslaan. Die zijn meestal 4 decimalen precies. Wat wil je dan nog meer? Dan sla je dus gewoon Prijs_per_gelezen_pagina = 0.003 op. Niks aan het handje en zelfs nog een decimaal over

[ Voor 12% gewijzigd door RobIII op 15-05-2006 22:48 ]

[alienfruit]

Sinds wanneer gaat er geld meteen na de auteur ? Voor mijn boek gaat het toch echt eerst na de uitgever die het dan aan mij doorgeeft. Maar dat kan zijn omdat hun ook de e-book versie van het boek regelen. Maar goed 50% van de opbrengsten (revenue) houd ook niet over

[flowerp]

alienfruit schreef op maandag 15 mei 2006 @ 23:20:
Sinds wanneer gaat er geld meteen na de auteur ?

Geen idee. Ik programmeer het ook alleen maar naar de specs van de klant hoor. Maar in hun business model gaat er dus inderdaad geld 'direct' naar de auteur, hoewel direct is relatief natuurlijk. De klant betaald aan de partij die het systeem host, en die hostende partij betaald percentages uit naar verschillende mensen waaronder de auteur. In principe zou een auteur volgens mij ook direct een boek via dit systeem kunnen aanbieden (dan wordt de publisher percentage gewoon op 0 gezet), maar ik geloof niet dat de klant dit wil gaan doen.