openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Dominique,

I got it yes, may be you should have written a big round() around your
expression, but got the idea yes, sorry.

Now what would be the problematic concrete use case then?

I can think: you compute and round 0.1005 (at 2 digits) an invoice line
value as 0.100 instead of 0.101 using the kind of computation you do (what
you call the Float error).
But I'm pretty sure no one can reproach you to round 0.1005 to 0.100 instead
of 0.101, as this is certainly not a 10^-2 error but just a convention
(otherwise please shout as it would be a trouble indeed).

Then what? We store 0.100 in the invoice line and the account move line.
After that we can sum those 0.100 in reports, multiply them, there would be
no 'accounting error' for that, no wrong sum of those 2 digits approximated
values.
The only thing you have here is an approximation at some point that get an
amplification if you multiply it.


Now, if rounding 0.1005 to 0.100 is not an accounting error, are those
approximations important in practice?
My answer would be no, because even if you rounded according to the
convention or with more precision, you would still make such cumulated
approximations.
Indeed, because accounting force you to round invoice lines at 10^-2, it
forces you anyway to have rounding approximation at invoice line that would
get amplificated anyway in reports.

Suppose I'm selling something that cost 0.1005 and you round it at 0.101
(which is correct after you), because the law force you to do so: in your
invoice report or invoice line in the database you then store
0.101. Nonetheless, your are actually making an approximation of 0.005
Multiply it by 100 000 products you sale and you get an approximation of 500
against the exact calculus, sell more products and it just get worst, just
like the case you are reporting, whether you use Float, Decimal or whatever.

At the end, I think that because the accounting laws force you to do
approximations, it's not relevant to fight that kind of approximation you
mention as accounting rules make them appear anyway as I've shown.


Thoughts?


Raphaël Valyi
Founder and ERP Consultant
+55 21 3010 9965
http://www.akretion.com

<http://www.akretion.com.br/>



On Wed, Aug 18, 2010 at 2:58 PM, bounaberdi <dominique.chabord@xxxxxxxxxx>wrote:

>
> Raphael,
>
> I think you missed the point. You went too fast across it.
> the correct answer is 0.101
> nevertheless, whichever result you prefer, I gave two examples which make
> the same calculation and give opposit results.
> Floats will give you the right answer in the second expression or
> voce-versa
> if you prefer.
> I took an example of a currency rounded at three digits after the point.
> How does it work ?
> 0.001/2 introduces an error which is bigger than 0.1 error
> combining them gives you an unpredictable result.
>
> --
> View this message in context:
> http://openerp-expert-framework.71550.n3.nabble.com/float-errors-propagating-to-10-2-in-OpenERP-v5-tp1175425p1210919.html
> Sent from the openerp-expert-framework mailing list archive at Nabble.com.
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-framework
> Post to     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>