openerp-expert-framework team mailing list archive

[bounaberdi <dominique.chabord@xxxxxxxxxx>]

Hi Raphaël,

yes, you got the first aspect : result can be wrong when rounded.
You have shown it is quite easy to reproduce with other examples.

My second example showed a more concerning problem, imho :
When you make equivalent calculations in float you can get different results
after rounding.
Depending on the order you calculate, you got 0.100 and 0.101 and this is
unconsistent.
1.0-(1.0-0.001/2)+0.1 =0.100
1.0+0.1-(1.0-0.001/2) = 0.101

Because there are two different kinds of consequences :

1 - Some numbers are consistently wrong in all the accounting : this will
probably never be detected. Impact is low. Undetected errors are usual.
Accountants can understand.

2 - Two numbers which should be the same (balanced), but elaborated by
different calculation modes, are not the same : this will be detected and
the accounting consistency is broken. This is bad. Impact is high.
Accountants cannot understand.

I'm not in charge of making decisions for V6, nevertheless, I think that if
we characterize in the code both cases and can be sure case number 2 never
happens, it would be an acceptable trade-off. Anyway, I don't know how this
could be done.

rgrds

-- 
View this message in context: http://openerp-expert-framework.71550.n3.nabble.com/float-errors-propagating-to-10-2-in-OpenERP-v5-tp1175425p1220580.html
Sent from the openerp-expert-framework mailing list archive at Nabble.com.