Hello Dominique, I should say you scared me first when I tried your example and cumulated the error and soon got significant errors. However, I think your counter example is just wrong, you say: "1.0-(1.0-0.001/2)+0.1 =0.100 while the correct answer 0.101" well, firt Python answers: 0.10049999999999995 not 0.100
AND SECOND, THE CORRECT RESULT IS: 0.1005 not 0.101 as you said, do we all agree on this or what? That means again we get a 10^-17 error that is not going to have practical effect at 10^-2 at least if some minimal care is taken in coding (I never found a bug due to the use of Float in Launchpad yet). BTW, Ruby get the result right always using Ruby Floats, not sure how they differ. I personally think Fabien is right to stick with Float even if he has some arrogance when evacuating the issue while IMHO their customers like Publicus have very good reasons to complain about rounding issues that used to cripple OpenERP (even if situation is getting much better now) though none were due to the use of Float so far (only coding errors that would have exist exactly the same if using Decimals). Decimal is also a lot slower. Tryton might be coded with more care general so they can afford that overhead. In OpenERP going Decimal without further refactoring would mean getting very slow (OpenERP speed is okay, but slower would really be an issue, larger companies would never use it then). Refactoring it all would mean harder than just go Tryton. At the end I agree with Fabien here to keep Float, but still urge for sanity/perf refactoring after v6. So to me your counter example was just invalid, do we agree on that? Raphaël Valyi Founder and ERP Consultant +55 21 3010 9965 http://www.akretion.com <http://www.akretion.com.br/> On Wed, Aug 18, 2010 at 6:26 AM, bounaberdi <[email protected]>wrote: > > Hello, > > I'm thinking differently about this issue. > For me, the problem is not "how much is the error on floating calculation" > because we know that a rounding error is a difference of 1 on the last > digit, I mean 1.01 $ instead of 1.00 > > I think the question is how often this small error results in a rounding > error. > > > let's take this example which a three digit precision : > python : > 1.0-(1.0-0.001/2)+0.1 =0.100 while the correct answer 0.101 > > funny thing is that this > 1.0+0.1-(1.0-0.001/2) = 0.101 results in the correct correct answer. > > > You can make this calculation 1000 times, you'll get 1000 rounding errors, > ie 10$ ;-) > If a customer never uses 10% value, which is known as toxic for binary > computing, then he may hope get everything correct ? > > Thank you for your comments. > regards > > -- > View this message in context: > http://openerp-expert-framework.71550.n3.nabble.com/float-errors-propagating-to-10-2-in-OpenERP-v5-tp1175425p1202230.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 >
_______________________________________________ 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
