On Thu, 06 Jul 2000, you wrote:
> 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.
I don't think so.
First, let me apologize that the correct conversion is 35/400.
Even in the case of 9.25% (37/400), the TEXAS SALES TAX tables tell the
merchant to collect $0.09.
I am sure that "ceiling" may apply in some transactions, but "rounding" is
the procedure used for this instance.
Don't get me wrong. I am certain that having "floor", "ceiling", and "round"
available will be useful for extensions into pricing calculators when we
extend into other aspects of business calculations. But I don't see much
utility in them for just "bookkeeping". Fundamentally, any multiplicative
calculation that we perform in the ledger system is just an estimate to ease
the data entry. It is always subject to revision to match the actual
transaction.
> > 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.
Start with "Space", "Speed" and "Assertions" ...
> In particular, the problems you cite with SQL backends just don't exist as
far as I can tell.
If you wish to limit yourself to small databases, you can get away with just
about ANY representation.
In fact, the calculations that you need to perform should be "format
agnostic". You should define them in terms of the properties of the inputs
and integer operations. As long as you are writing in a language such as
Scheme or C++ where there is no prefix/infix notational difference when you
change the representation of integers, You shouldn't care how we STORE the
values.
> 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.
Please don't think about "numbers".
Financial calculations are not about numbers. They are about countable
amounts of money, rates of exchange, etc.
Think instead of strongly typed entities and OO concepts (like what you do to
the object (a pot of money) rather than the number of items in the pot.)
Try viewing the problem from the top down rather than the bottom up.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
