openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

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 <rvalyi@xxxxxxxxx>

> 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/>
>
>