openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

Hello,

On Fri, Aug 20, 2010 at 6:32 AM, Dominique Chabord <
dominique.chabord@xxxxxxxxxx> 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/>