openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

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

>
> Unfortunatly, the story is worst than what you seem to hope so much. Again
> you missed the point.
> The two expressions give you different results, when they are absolutly
> equivalent, just the order of operations is different.
>

Got that yes.


> One gives you 0.101, the second, with the same python interpreter gives
> 0.100
> One of them is wrong, choose the one you like.


Well, I can very well view that as:
both results are rounded values of two different approximated computations
(by luck those fractional numbers are exact in base 10, we could also very
well have worked with numbers like 1/3 that have no exact representation in
base 10 either, that's why in general I call that approximated computation).
Depending the order we compute things, 10^-17 epsilon has gone one side or
an other of the 5th rounding digit.
For me it's no more than 10^-17 epsilons again.



> It just confirms what we
> learnt at school.
> I just managed to have float error jumping over the rounding limit, so
> rounded result is different in the two cases.
> Accounting can be computerized if it provides the same result as manual
> calculation, in base ten.


Laws are laws so no matter how stupid they are, the software should enforce
them indeed.
Now, do you have any pointer to laws that say such things?

For me, with the eye of a physician, again there is no big deal if you
perform two different approximated computations (in base 2 they are
approximated, even if by luck in base 10 those are exact values here; they
wouldn't be anymore if we had things like 1/3 in base 10) and depending of
the order, you get a 10^-17 epsilon difference that might, by luck make you
pass the 5th digit rounding barrier.
For instance, in France the fact that both VAT computation methods: rounding
per line or globally is tolerated already lead to much larger approximation
that those 10^-17 epsilons...
Accounting rounding also force to have much larger approximation in
consolidated reports, so I just see no logic for that.

Now, I agree, the question is whether this can be accepted or not in
accounting, I should say I'm very curious about that. Any accountant here to
tell us?
is there such a law that favor base 10 over base 2 for exact numbers vs
approximations, regardless we achieve the correct precision, such as
"Accounting can be computerized if it provides the same result as
manual calculation, in base ten." ?



> BCD is made for this. Hand held computers use BCD,
> spreadsheets use BCD for financial format, Ciel (cheap accounting software)
> does it as well as COBOL.
>

I don't doubt some at least do it with Decimal, as we all agreed on, Decimal
makes a few things simpler (at the cost of some serious overhead and
dangerous/expensive refactoring for the OpenERP case), this alone doesn't
mean it's the only solution. Ciel is not meant for scalability either.


> Now we can invent a new way. In fact I don't care more in 2010, than in
> 2006, only the noise around awoke me. ;-)


If there is a law that says:  "Accounting can be computerized if it provides
the same result as manual calculation, in base ten." or something very
similar, then I would agree we would have serious trouble as base ten would
mean that some values are considered as being exact and not approximated as
they are in base two in the Python Float world.

Even in that case could however introduce Decimal at the few spots where
accounting would make them matter (invoice line/tax computation), but is
that the law, where?

any clue?


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

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