tussentijds afronden zonder afwijking in het totaal

[seweso]

Ik moet een reeks getallen tussentijds afronden maar ik wil geen afwijking in het totaal. Als ik hier (en elders op het internet) zoek dan is de conclusie altijd dat je niet tussentijds moet afronden. Dat laatste is voor mij geen optie omdat de afgeronde getallen geexporteerd moeten worden naar een veroudert systeem waar alleen gehele getallen kunnen worden opgeslagen.

Voorbeeld 1:
196,47155590984800
1,48083194434379
17,46510616711350
284,49394883687200
367,46409160084000
58,49286180157980
122,42995869265900
153,70164504674200

Totaal = 1199 (afwijking van -3)

Voorbeeld 2:
196,51510979056400
1,52438582505979
17,50866004782950
284,53750271758800
367,50764548155600
58,53641568229580
120,55714182187100
155,31313863323400

Totaal = 1205 (afwijking van +3)

Onwetenschappelijke oplossing
Met behulp van de functie doelzoeken in excel kan ik achter hoe de getallen moeten worden gecorrigeerd om het goede totaal te komen: Bij voorbeeld 1 moeten alle waarden gedeeld worden door 1,00014 en bij voorbeeld 2 moet gedeeld worden door 0,99986.

Maar is dit een goede oplossing? Kan deze methode voor alle reeksen getallen worden toegepast? Is er misschien een statistische afwijking waardoor bepaalde getallen onevenredig (oneerlijk) worden gecorrigeerd? Is er een manier om de correctie te berekenen i.p.v. de brute-force attack?

Achtergrond informatie
Het gaat praktisch om een uren-registratie-systeem waarbij het totaal aantal geregistreerde uren altijd uit moet komen op 8 uur. Bovenstaande voorbeeld-getallen zijn de bijtellingen die nodig zijn om op 8 uur uit te komen. Registratie vind plaats op gebruiker, datum, opdrachtgever combinatie met gehele uren. Bovenstaande voorbeelden zijn dus voor gebruiker X op datum Y voor 8 verschillende opdrachtgevers waarbij er 27598 seconden geregistreerd zijn en er dus 1202 seconden aan toegevoegd moet worden (evenredig).

[MSalters]

Heb je de complete reeks op het moment van afronden? In dat geval is er een nettere procedure. Bereken voor elk getal de afstand tot het dichtbijzijndste hele getal.
Voorbeeld 1:
0,47155590984800
0,48083194434379
0,46510616711350
0,49394883687200
0,46409160084000
0,49286180157980
0,42995869265900
0,70164504674200 - 1 = -0.28354...
_________________
Rond het getal af met het kleinste verschil. Deel het verschil door het overgebleven aantal getallen, en tel het op bij elk resterend getal. Let op, het verschil kan negatief zijn.
Herhaal de procedure met de overgebleven N-1 getallen. De fout in je som is dan altijd kleiner dan 0,5 omdat je alleen bij het laatste getal een afronding doet zonder compensatie.

Voorbeeld: (som=13.3)
3.4
4.2
5.7
----
3.3 +.1 = 3.5
4
5.7 + .1 = 5.8
-----
3.5 + -.2
4
6
-----
3
4
6
-----
De som is nu 13, wat correct afgerond is.

[Verwijderd]

Als je in jouw voorbeelden alle getallen vermenigvuldigt mer 10^14 dan zijn het allemaal hele getallen. Als je die vervolgens exporteert naar je verouderd systeem, ze daar optelt, door 10^14 deelt en afrondt dan werkt het toch correct?Ik hoop dat ik goed begrepen heb dat dit je probleem is.

[Opi]

Wellicht erg voor de handliggend, maar hoe groot kunnen de gehele getallen zijn? Je zou namelijk alle getallen in het nieuwe systeem met 1000 kunnen vermenigvuldigen, ze naar het oude systeem transporteren, ze daar optellen en de som delen door 1000.

edit:
Damn you, Proost.

[ Voor 7% gewijzigd door Opi op 05-05-2004 13:06 ]

[seweso]

MSalters schreef op 05 mei 2004 @ 12:41:
...

Volgens mij word dan de correctie dan verdeeld over het aantal getallen maar niet in verhouding tot de grote van het getal. Ik bedoel dat een klein getal net zoveel kans heeft om met één te worden opgehoogd als een groot getal waardoor onder aan de streep (na b.v. duizenden reeksen) de totalen afgevlakt zullen worden (praktisch in mijn voorbeeld dus de totalen per opdrachtgever). Hoewel het verschil natuurlijk minimaal is en de berekening die jij geeft sowieso voor elke reeks werkt (en simpeler is).

[Duur!]

't is niet de beste methode, maar als ik een berekening moet doen met een bepaald aantal nauwkeurig bekende cijfers, dan rond ik de deel uitkomsten op 2 of 3 cijfevers meer afdan ik in het uiteindelijke antwoordt nodig heb.

Dus als ik bijv. pi moet gebruiken en 3 cijfers significant zijn gebruik ik geen 3,14 maar 3.1415
dit scheel niet heel veel ten opzichte van 3,14159265enz. maar door een groter aantal tellende cijfers te nemen krijg je geen tot een heel kleine invloed.

't getal met de minste tellende (significante) cijfers bepaalt toch uiteindelijk de nauwkeurigheid van de uitkomst.
Om het grof te zeggen op een lengte van ongeveer tien meter maakt het qua nauwkeurig heid niet uit of er een milimeter bij opgetelt wordt of niet.
echter als je iets hebt van 99,875mm dan is 0,010mm erbij wel belangrijk...

[seweso]

Verwijderd schreef op 05 mei 2004 @ 13:02:
Als je in jouw voorbeelden alle getallen vermenigvuldigt mer 10^14 dan zijn het allemaal hele getallen. Als je die vervolgens exporteert naar je verouderd systeem, ze daar optelt, door 10^14 deelt en afrondt dan werkt het toch correct?Ik hoop dat ik goed begrepen heb dat dit je probleem is.

Dat 'oude' systeem kan niet aangepast worden, en dus als je dan alles x1000 doet dan komen er opeens heel hoge facturen uit.

[Rey Nemaattori]

Je maar je deelt het weer door duizend voor je de facturen maakt. Het lijkt me stark als het systeem nieteens centen kan opslaan bij het maken van een factuur oid.....

[seweso]

Duur schreef op 05 mei 2004 @ 13:16:
't is niet de beste methode, maar als ik een berekening moet doen met een bepaald aantal nauwkeurig bekende cijfers, dan rond ik de deel uitkomsten op 2 of 3 cijfevers meer afdan ik in het uiteindelijke antwoordt nodig heb.

Dus als ik bijv. pi moet gebruiken en 3 cijfers significant zijn gebruik ik geen 3,14 maar 3.1415
dit scheel niet heel veel ten opzichte van 3,14159265enz. maar door een groter aantal tellende cijfers te nemen krijg je geen tot een heel kleine invloed.
...

Je zegt dus eigenlijk dat ik moet kiezen voor een acceptabele afwijking.

En dus moet ik me praktisch afvragen: ben ik mieren aan het neuken of niet...

Ff kijken, theoretisch als ik elke dag een registratie heb van 35 seconden die na bijtelling in de helft van de gevallen met 1 seconde extra word opgehoogd dan heb je een afwijking van (pakt rekenmachine) 1,43%. Dat betekent dat een kleine klant 1,43% meer moet betalen.

Rey Nemaattori schreef op 05 mei 2004 @ 13:39:
Je maar je deelt het weer door duizend voor je de facturen maakt. Het lijkt me stark als het systeem nieteens centen kan opslaan bij het maken van een factuur oid.....

De facturen komen rechtstreeks uit dat programma rollen, dus achteraf aanpassen zou dan een hels karwei worden.

[Sgrovert]

Als je zegt dat je elke dag iets moet registreren, zou je ook het getal van de dag van te voren in kunnen voeren en het stukje dat je afgerond hebt de volgende dag bij de tijd kunnen tellen.

Dit lijkt sterk op het idee van MSalters

Voorbeeld:
Dag
1 : 6,4 --> +0,0 --> 6,4 --> 6
2 : 5,2 --> +0,4 --> 5,6 --> 6
3 : 7,7 --> -0,4 --> 7,3 --> 7
4 : 6,0 --> +0,3 --> 6,3 --> 6

Dag 5: +0,3


Enz. Zo neem je elke dag dus de fout van de vorige mee.

[ Voor 9% gewijzigd door Sgrovert op 10-05-2004 17:25 ]