Hello, Instead of using decimal why not using long to store and compute then do the conversion at the end of computation. We should not have rounding error and it should be faster than Decimal. (But we will be limited in the numeric range of long)
Regards Nicolas Le 17 août 2010 à 10:57, Sharoon Thomas a écrit : > 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 -------------------------------------------------------------------- Nicolas Bessi Senior ERP consultant Business Solution technical leader Camptocamp SA PSE A CH-1015 Lausanne http://www.openerp.camptocamp.com Phone: +41 21 619 10 26 Office: +41 21 619 10 10 Fax : +41 21 619 10 00 --------------------------------------------------------------------
_______________________________________________ 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
