From: Rafael C. <raf...@gm...> - 2015-01-06 16:20:24
|
Hi Exson, Yes, I think an "accounting adjustment for differences in calculus" is a bad image for webERP's precision. A couple of suggestions: 1. In calculations, to have "precedence" in calculus. I mean: first additions over subtractions; first multiplication over divisions. Subtractions and divisions destroy precision (reduce the quantity of "significant digits"). 2. If extra decimals in fixed decimal do not solve the problem, try with the floating (9e99) with +1 the quantity of digits of the bigger number to be shown. ref: http://dev.mysql.com/doc/refman/5.0/en/fixed-point-types.html Best regards, Rafael. 2015-01-06 9:11 GMT-06:00 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. > > > ------------------------------------------------------------------------------ > 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...@li... > https://lists.sourceforge.net/lists/listinfo/web-erp-developers > |