openerp-expert-framework team mailing list archive

[Sharoon Thomas <sharoonthomas@xxxxxxxxxxxx>]

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