openerp-expert-framework team mailing list archive

[Nicolas Bessi <nicolas.bessi@xxxxxxxxxxxxxx>]

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



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