On Wed, Aug 18, 2010 at 4:02 PM, bounaberdi <[email protected]>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/>
_______________________________________________ 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
