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. _______________________________________________ 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
