Richard Wackerbarth <[EMAIL PROTECTED]> writes:
> For example, if the sales tax rate is 8 3/4 % (0.0875) we can
> represent that as 37/400 or as 875/10000. When we apply that to a
> purchase of $1 (100/100) we get an answer of 37/400 and not 9/100
> which is what is actually collected.
That's only if you want your multiplication to have an exact AND
correct result with an unspecified denominator. In my API you can
specify not only the denominator that the result must have but the
conversion strategy that should be used (floor, ceiling, round) for
the result, and can optionally get another result that represents as
an exact quantity the difference between the result returned (in
pennies, for example) and the correct result of the arithmetic
operation.
And, in fact, it's likely to be 10/100 that would actually be
collected in your example. As far as I can determine, financial
entities collect or pay the least amount of money that completely
satisfies the obligation. In order to buy an orange that costs 9/16
of a dollar, you have to pay $0.57, though the cost would round down
to $0.56. This is a policy decision, and should be exposed to the
API.
> However, you have yet to show how it is of any significant
> assistance. I, and others, have pointed out some ways that it
> hinders.
You'll have to recap those for me, then, because I haven't seen any
such "hindrances" survive the light of inspection. In particular, the
problems you cite with SQL backends just don't exist as far as I can
tell.
I am interested in finding the right solution to this problem, but
this discussion has exhausted its usefulness in that regard as far as
I can tell. Please prove me wrong on that.
Bill Gribble
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
