But when a calculation such as a multiplication or a division is involved, then, yes, some amounts (billing rates in the catalog, for example) are indeed stored in integer "millicents" (multiplied by 1E5) in order to get the right value in the end. I actually participated in 2009 to a project where we changed the catalog tariffs from 3 to 5 decimal point precision because it was the only way to get the right amount in the final invoice without any rounding error. Typically, if the marketing was selling a subscription for, say, EUR 19.90 (VAT inclusive) per month, it was impossible to find a before-tax rate to be stored in the catalog that would lead to exactly 19.90 after applying the tax rate (we would get, for example, either 19.91 or 19.89 after rounding). With a five decimal place catalog, any 2 decimal-place amount could be reached after applying the VAT rate. But this is really a rounding issue, not exactly the same thing as the floating point versus integer arithmetic problem (even though they are somewhat related).
In my experience rounding issues and date management issues are some of the worst problems plaguing regularly information technology for business management. In the case of rounding issues, my client had to go through three large successive projects over a period of more than two years before getting rid completely of these rounding problems. The overall cost of these 3 projects is far in excess of one million euros, perhaps closer to or even above two million euros. I don't know exactly because I know (more or less accurately) only about the direct IT costs (studies, development and tests), but a lot of work from non IT persons (people from business departments, marketing, support, customer relationship, management, accounting, finance, tax, auditing, revenue assurance, SOX compliance, etc.) is also involved.
In reply to Re^4: Strange int() result
by Laurent_R
in thread Strange int() result
by menth0l
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |