openerp-expert-framework team mailing list archive

[Raphaël Valyi <rvalyi@xxxxxxxxx>]

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 <dominique.chabord@xxxxxxxxxx>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     : openerp-expert-framework@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openerp-expert-framework
> More help   : https://help.launchpad.net/ListHelp
>