Hi, I completely agree on the theoretical knowledge on which the decision to make floats as defacto for currency/money data type.
But I really wonder if that goes with the rest of the idea. The whole idea of a RAD platform (at-least thats what the claim is) is to speed up development. The choice of RAD itself is a compromise on speed and a python based RAD platform an even bigger compromise on performance. I believe the modules where we have seen rounding issues are all important core modules which would have been written by Fabien or at-least a senior developer of Open ERP SA (if not I have no question). If the design by such senior developers/experts is buggy and takes months, if not years to fix some of them, then I wonder who could write a bug free "ERP" module with financial info on openobject. (I will update the customer to the latest "stable" release and check if the issue persists. I hope that solves the problem and does not introduce new ones (which is usually not the case)) Thanks, Sharoon Thomas http://openlabs.co.in On 17 Aug 2010, at 09:19, Borja López Soilán (Pexego) wrote: > Raphaël Valyi wrote: >> >> Well, of course, I made a small mistake in my mail, I meant 14 000 moves is >> ~10^5, meaning we expect a 10^-17* 10^5=10^12 error at first when summing >> moves while we already get a 10^-9 error. The question why is still open. >> And off course, how that 10^⁻9 propagates to 10^-2 in the chart of accounts >> is still open and should be fixed... > I would say 10^⁻9 is the error to be expected with 14000 moves, not 10^12. > An easy example: summing 14000 times the same float vs using multiplying it > by 14000 (mathematically they should be the same). > > $ cat tmp.py > diffs=[] > for j in range(0, 10000): > s=0.0 > k=j/14000.0 > for i in range(0, 14000): > s+=k > diffs.append(abs(k*14000.0-s)) > > print "max: ", max(diffs) > print "min: ", min(diffs) > print "avg: ", sum(diffs)/len(diffs) > > $ python tmp.py > max: 3.71619535144e-09 > min: 0.0 > avg: 8.2300255102e-10 > > As you can see the average rounding error for 10000 floats is almost 10^-9 ! > > Anyway, I don't understand how Sharoon is getting a 10^-2 rounding error on > __calculate :( > > > By the way, Decimal is a lot slower of what I thought. The same test as > above, but done with Decimal gives a maximum 0.0 rounding error but takes > about 100 times more time than using floats (53.28 vs 0.43 seconds for 100 > 'j' loops), wow, that's bad. > -- > Borja López Soilán > [email protected] > > Pexego Sistemas Informáticos S.L. > Avenida de Magoi 66 - 27002 Lugo (España) > Tel./Fax 982801517 > http://www.pexego.es > > > AVISO LEGAL - CLÁUSULA DE PRIVACIDAD > Este mensaje se dirige exclusivamente a su destinatario y puede contener > información privilegiada o confidencial. Si no es usted el destinatario > indicado, queda informado de que la utilización, divulgación y/o copia sin > autorización está prohibida en virtud de la legislación vigente. Si ha > recibido este mensaje por error, le rogamos que nos lo comunique > inmediatamente por esta misma vía y proceda a su destrucción. > _______________________________________________ > 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
