openerp-expert-framework team mailing list archive
-
openerp-expert-framework team
-
Mailing list archive
-
Message #00420
Re: float errors propagating to 10^-2 in OpenERP v5...
Hello All,
Finally after two days of digging i have found the good, bad and the ugly answers that solves my rounding problem.
Good: Its not a rounding issue.
(Not that i am ready to believe float is a solution. We need Decimals !!)
Bad: The source of the problem is scarier. The production system had an account move with one draft line and a valid line. (The move as a whole was not validated if that is any useful info. I have no idea how this could happen. If i can recreate the situation i shall update the list/file a bug again.)
Ugly: There are innumerous design issues in accounts which could cause more dangerous issues. This inference is from my attempts to recreate the same problem i faced in different ways and of course i did succeed.
The most notable is the use of active field:
The implicit discard of inactive rows could lead to a situation where the account may not get displayed in the chart of accounts despite having a balance.
Same could happen to parent rows as well. It will hide all child rows in COA, if its active=False
This is one issue that can be easily fixed.
Thanks for the concern and time.
Sharoon
On 17 Aug 2010, at 15:23, P. Christeas wrote:
> On Monday 16 August 2010, Raphaël Valyi wrote:
>> Hello,
>>
>> we while ago we debated here the usage of Floats vs Decimals in Python.
>> ...
>
> When talking money, decimals (+ numeric, in SQL) are supposed to yield better
> precision at calculations, than floats[1].
>
> However, I feel that this is not our problem. IMHO the error is not at the
> choice of arithmetic /storage/, but at the interface of data to and from the
> db.
> Every time we fetch sth from the db, or store something in it, we may lose a
> little bit of information, here, some decimal digits. We spend resources to do
> that, too.
>
> So, my counter-proposal is that we let the database do more, instead of
> writting those loops in Python (or Java, or Python over Java, or Java over
> Ruby over Python over Java etc.). Let SQL do what it is good at: Sums.
>
> I do appreciate that some developers are allergic at SQL and would write
> anything else instead. But here, Python with its metaprogramming would allow
> us to write some intelligent framework to abstract over some complex SQL query
> building. Let us try to go to that direction[2].
>
> This means it will definitely be a post-v6.0 thing.
>
>
> [1] which, may even be a myth, because floats /do/ have the necessary precision
> to always round up to the correct value.
> [2] see line 37 at:
> http://git.hellug.gr/?p=xrg/a2blib;a=blob;f=a2blib/Form/Class.SumMultiView.inc.php;h=4a0d9b562958c8739a2735c
>
> --
> Say NO to spam and viruses. Stop using Microsoft Windows!
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openerp-expert-framework
> Post to : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help : https://help.launchpad.net/ListHelp
Follow ups
References