Well, of course, I made a small mistake in my mail, I meant 14 000 moves is ~10^5, meaning we expect a 10^-17*10^5=10^12 error at first when summing moves while we already get a 10^-9 error. The question why is still open. And off course, how that 10^⁻9 propagates to 10^-2 in the chart of accounts is still open and should be fixed...
Raphaël Valyi Founder and ERP Consultant +55 21 3010 9965 http://www.akretion.com <http://www.akretion.com.br/> 2010/8/16 Raphaël Valyi <[email protected]> > Hello, > > we while ago we debated here the usage of Floats vs Decimals in Python. > with OpenERP Floats, 0.3 means 0.29999999999999999 in Python for instance > so there is very often a 10^-17 error when loading exact data from > PostgreSQL for instance. > The whole debate was that if we pay attention in the dev, that 10^⁻17 error > wouldn't contaminate the 10^⁻2 required accuracy of the legal accounting (or > even possibly 10^-3). > Well I tend to agree with that in general. Tryton went for Decimals > instead, claiming it makes it easier to code, at the cost of some extra > overhead of course. > > However, Sharoon Thomas (Openlabs) just reports us that he his watching the > credit and debit of some specific root account and > get a 0.04 delta between credit and debit: http://yfrog.com/f/afxxbp/ : > 1033970.79 > vs 1033970.83 > > Database numbers are exact on contrary: > debit | credit > ------------+------------ > 1033970.83 | 1033970.83 > > Sharoon says there are around 14 000 (~10^4) moves inside that account. > So we can at least expect a contamination to up to 10^-17*10^4=10^-13 for > credit and also for debit. > > The delta he finds is even a bitter higher however: > >>> debit, credit = sum([x['debit'] for x in moves]), sum([x['credit'] for > x in moves]) > >>> debit > 1033970.8299999937 > >>> credit > 1033970.8299999965 > > that's a 10^-9 error, I'm not sure exactly why it's more than our 10^-13 > we expected by the way, any explanation? > It looks like the error propagated the squared we expected. > > Now the question is how the recursivity of the __compute method in > account/account.py can amplify this into a 10^-2 error. > The bug is real and annoying, you can still gain your medal if you find out > how it propagates from 10^-17 to 10^-2 in the chart of accounts with only 14 > 000 moves. > I think Sharoon is investigating on his side meanwhile... > > More soon hopefully... > > > > Regards, > > > Raphaël Valyi > Founder and ERP Consultant > +55 21 3010 9965 > http://www.akretion.com > > <http://www.akretion.com.br/> > >
_______________________________________________ Mailing list: https://launchpad.net/~openerp-expert-framework Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-expert-framework More help : https://help.launchpad.net/ListHelp
