Re: [WebERP-developers] Float accuracy problem

[ExsonQu <hex...@gm...>]

*Hi, Rafael and Richard,*

           Thank you for your feedback. 

          And I've also attached Tim's feedback about the cause of this
problem. As Tim point out, we may use webERP's current
locale_number_format() function to solve this problem. 
          I believe the effort is deserved since webERP is accounting
application. 
          If no objection, I'd like to initiate a schedule to solve this
problem. 

          Thanks again for the feedback from all of you!
        
          Best regards!

          Exson
         


Tim wrote
>           The problem is a general one with the way computers deal with
> floating
> points. Mysql stores floating point values in a 32 bit value, using an
> algorithm to convert the floating point number to a 32 bit integer,
> and then reversing it to get back to a floating point number. This
> means that it is only actually capable of storing 4,294,967,295
> different floating point numbers. However in reality there is an
> infinite number of them, even just between 0 and 1 there is an
> infinite number. This inevitably means that there are an infinite
> number of floating point numbers that when converted to a 32 bit int,
> and then back again do not end up with the initial value. To see an
> example of this enter the following sql into a mysql terminal:
> 
> SELECT 3.1415E0 + 0.9585E0 - 4.1E0;
> 
> the E0 just forces mysql to think of these numbers as floats. The above
> gives
> 
> +-----------------------------+
> | 3.1415E0 + 0.9585E0 - 4.1E0 |
> +-----------------------------+
> |       8.881784197001252e-16 |
> +-----------------------------+
> 
> on my Debian system but may give alternatives on your operating systems.
> 
> Commercial accounting systems store all numbers as integers with a
> number of decimal places and just convert back to floats when
> displaying them.
> 
> Hope this helps,
> Tim
> 
> Well imagine a stock item XYZ that has the decimalplaces field set to
> 4. The quantity field in the locstock table should be of type integer.
> If we have a quantity of 57.561 of XYZ in a particular location then
> the quantity field in the locstock table would be 575610. To display
> the quantity on the screen you convert it into the correct format so
> here it is 575610/pow(10, 4). This could probably be done via the
> number_format functions. We already hold the decimal places number for
> stock items and monetary amounts.
> 
> This "bug" has long been a problem in openerp as well. I know its been
> discussed on that project over and over for many years, but I am not
> sure whether they have taken any action yet. It would be a big plus to
> change it, but a _lot_ of work.
> 
> Tim


Pak Ricard wrote
> Hi Exson:
> 
> YES! We find some tiny differences but after time they become noticeable
> (still small, but there's a bug somewhere with float).
> We detected it also in multicurrency calcualtions, so I guess it is due to
> diffrerent ways to do the same calculations in different parts of webERP,
> and the float precission tricks us here.
>  I will take more attention and try to track it down.
> 
> Regards,
> Ricard
> 
> 2015-01-05 13:01 GMT+08:00 ExsonQu <

> hexinfans@

> >:
> 
>> *Dear all,*
>>
>>      I've received one more case about this. The number in the inventory
>> account does not match with the inventory actual value. There is always
>> some
>> variance even we set up more decimal places.
>>
>>      Does anybody meet this same problem?
>>
>>      Best regards!
>>
>>      Exson
>>
>>
>>
>>
>> --
>> View this message in context:
>> http://weberp-accounting.1478800.n4.nabble.com/Float-accuracy-problem-tp4657899p4657939.html
>> Sent from the web-ERP-developers mailing list archive at Nabble.com.
>>
>>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming! The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is
>> your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take
>> a
>> look and join the conversation now. http://goparallel.sourceforge.net
>> _______________________________________________
>> Web-erp-developers mailing list
>> 

> Web-erp-developers@.sourceforge

>> https://lists.sourceforge.net/lists/listinfo/web-erp-developers
>>
> 
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming! The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is
> your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net
> _______________________________________________
> Web-erp-developers mailing list

> Web-erp-developers@.sourceforge

> https://lists.sourceforge.net/lists/listinfo/web-erp-developers





--
View this message in context: http://weberp-accounting.1478800.n4.nabble.com/Float-accuracy-problem-tp4657899p4657944.html
Sent from the web-ERP-developers mailing list archive at Nabble.com.