← Back to team overview

openerp-expert-framework team mailing list archive

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