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 <[email protected]>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 : [email protected] > Unsubscribe : https://launchpad.net/~openerp-expert-framework > More help : https://help.launchpad.net/ListHelp >
_______________________________________________ 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
