Hello, On Fri, Aug 20, 2010 at 6:32 AM, Dominique Chabord < [email protected]> wrote:
> hi > > @Raphäel > Are you still convinced of this ? > You wrote yesterday : "NB: again, once this BCD "convention error" is made, > there is no further accounting error where sums wouldn't match or anything > like that (at least if we don't try to re-round the same computation but > done a bit differently, which requires care when coding, further errors > don't happen)." > I insisted to show you that I gave the proof that it is not true, and you > still deny it. Seems you are still make the initial error. Sums not > necessarily match and you conditions are not true. > regards Yeah, well, Dominique, in your example you have shown that you can have round(x) != round(x) pretty easily with Float for very simple computations with decimal values that exceed the precision of the binary Floats (like 0.1, 0.3, 0.7, 0.9...). However, I believe that with extreme coding care, it might be possible to round ONLY ONCE, and once you rounded, you always reuse the value you rounded an put in the accounting and do not try to round it again on the other side of your comparison (or else always use an 'epsilon'). For instance I think we had such a rounding bug in v5 for taxes because OpenERP was computing the net + tax included value for each invoice line using rounding. And there were also computing the total of taxes of one kind in the invoice (you know the 'tax table') doing a different computation order and rounding it. As a consequence: when you summed line tax values it didn't match the value printed for the total of the VAT for some values. Guys I can't remember exactly the bug, if that was only with price_accuracy > 2 or with tax_included modules. I think Sebastien told us this was cleaner in v6 though, may be I'll see with him again to see if that was this Float bug exactly + rounding on too sides (but actually we are so busy on v6 that we can hardly experiment to much with v5 that is the past for us). Now, it exists a way to code that computation properly with Floats: as OpenERP rounds taxes per line (to make sure accounting lines then match which is good), to compute the tax total, they should have added the rounded tax value they found for each line instead of re-compute it again to print it in the tax table. I believe/hope this is what is done in v6. So I do not find any practical counter-example where you really have to round two sides and this problem is forced to arrive with Floats. In all examples I can think about, there is a way to actually make it even with Floats. Now, I agree to say this requires extreme care, not exactly what OpenERP has shown in the past, not even exactly what we have currently as Borja just shown. For me, the only intrinsic issue you can't avoid with Floats and the one I asked about is that one: decimal computation product 0.70 tax 5% tax value = 0.70 * 0.05 = 0.035 but rounded to 0.03 (down) by OpenERP product 0.30 tax 5% tax value = 0.30 * 0.05 = 0.015 and rounded to 0.02 (up) by OpenERP If you have laws that impose you some exact rounding rules like from http://en.wikipedia.org/wiki/IEEE_754-2008 then you might be caught as OpenERP Float won't respect any of them (it's closed to even "round to nearest, ties to even" but not equivalent as values have offset yet statistically distributed equal ('normally'). I could find laws for Franc to Euro conversion saying that if 3rd dec is 5 then it should be rounded up. This however has probably been written by math ignorants and I doubt no 10^-17 could be made previously. I also doubt your whole accounting can be rejected because your BCD system use one of the 5 normalized rounding from http://en.wikipedia.org/wiki/IEEE_754-2008 , but just a different one (if all of them or some are accepted, then the "Float rounding" is undetectable practically and no one can accuse you either of rounding to what fits better for you as it's distributed 'normally' . For that, I'm not an accountant, but I can't believe that the issue I mention is critic (I would love to hear an accountant saying it though), but yes certainly boring as if you make the accounting both in OpenERP and your cheap BCD based system you'll certainly have different values at the end of the year, none being False. And with coding care in OpenERP debits and credits will match too. Now you guys proved me an other thing: it's easier than I though to do wrong code with Floats if exact values or rounded values compared to decimal matters. This certainly should make more vigilant on OpenERP's code as Borja has shown. For now it's just an intuition, but I would say we should think to introduce Decimal in the accounting computations where there are multiplications (anyone could prove that intuition?). Moving fully to Decimal is not reasonable for v6 and would make it too slow. But doing that in tax/currency computation might may be bring us back to standard conventions and smaller probability of pig code (see Borja's post/bug tracker) breaking in accounting errors. Thoughts? My 1 cents yeah well I computed them using a Float based system so technically speaking you know it's balanced but... ;-) 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
