Proposal for modifying gnucash to use exact quantities
Fri, 28 Jul 2000 01:12:16 -0500
On Thu, 27 Jul 2000 21:48:30 MST, the world broke into rejoicing as
Gordon Oliver <firstname.lastname@example.org> said:
> Hi all.
> One commentary that I would have with exact values is that
> in this (and any I imagine) accounting scheme we are representing
> one side of the story, i.e. we don't care what the other guy discounts
> from the inventory, we care about 2 things
> 1) How much (of commodity X) we gave away.
> 2) How much (of commodity Y) we recieved.
> The price, though interesting, is not relevant to the accounting per se.
> It should always be calculated based on the commodity out vs. the
> commodity in. In the event that the current value is wanted, it will
> always be an approximation (the value of a given commodity is never
> known till it is actually sold).
You're missing the "third case," which is that when we're estimating
the current value of a commodity in terms of another, we _do_ need
to have a rational number-based calculation in order to have sufficient
precision to represent the value.
For instance, if I have 25.255 shares of a mutual fund that is
trading at $USD 17 22/64ths per share, then the value is properly
value = 25255 * 1110 / (1000 * 64)
= 28033050 / 64000
[ "a miracle occurs," changing granularity to the
nearest 1/100th ]
= $438.02 USD
And that is, to the nearest penny, an "exact" estimate of the
value of the commodity.
Note that in decimal, that turns out to be $438.01640625 [perhaps with
more decimals hidden...], but we should want $438.02, no more, no less,
for this estimate.
> Can anyone come up with a reasonable condition under which an
> account would have arbitrary precision associated with it? Gasoline
> is probably not a good one, as the units pumped in and out have
> fixed precision (with a built in error), and any differences would be
> attributed to loss/gain by evaporation (yeah, gain is actually the
> oops we stole from the customers).
I'd think gasoline to be not a good example of "arbitrary precision"
for a slightly different reason: the amount that you _pay_, if we're
talking $USD or $CDN, is _always_ rounded to an integer quantity of cents
once it is to be paid for.
> If there are no reasonable conditions for this, then each account would
> have a fixed denominator, and the math within the account becomes simpler.
> There is however a hiccup, which is in the case of transfering commodities
> from one account to another, there may be an arbitrary precision loss. What
> gets done with that? (Note that this can only occur in the case of arbitrary
> and different denominators for accounts denominating the same commodity,
> which seems painful at best)
The transformation loses some precision _for the price_. The quantity
is always rounded a little to a fixed value, and once the result is
transacted, that's that.
> The other approach is to provide a single precision for a given commodity/
> currency. I.E. you can only transfer dollars from one account to another in
> units of 1/100 of a dollar, and you can sell wheat down to 1/64 of a bushel
> (as arbitrary examples).
Ah. The _strange_ thing is that the _price_ can use a different number of
"decimal places." Gas prices may be denominated in "tenths-of-cents per
liter." The "swing" of the decimal place takes place in the price,
and not in the commodity. Does that make sense?
> Before we all lose track. The basic argument I am making is that we do
> _not_ need to represent price exactly. It is an intermediate value that has
> no real relevence to the accounting...
Shall I put it differently to illustrate?
If we have a commodity that is purchased for some value in terms of another
commodity, the _ratio_ is an implicit price, and we don't need to
explicitly represent it.
For instance, given that mutual fund purchase up above, we have
a) There are 25.255 units of mutual fund.
b) The cost is $438.02 USD; that's what I paid the broker for
Arguably, there's a third value, but the "price" of $17 22/64ths per
unit is _NOT_ the true price.
The TRUE price is $438.02 / 25.255, which is very slightly lower than
$17 22/64ths, specifically, by (yes, this is exact!) 23/161632
What do we do about that 23/161632?
ABSOLUTELY NOTHING. It is of no particular relevance, and is
certainly not something we account for anywhere.
What's the price? The market may report 17 22/64ths; that's the
only number particularly worth tracking. I don't think we want
to report the price as 87604/5051, which _is_ the _exact_ price
paid for the security.
I'm not sure if that clarifies or not; the point that the price
is a little bit ambiguous (23/161632 worth of ambiguous :-)) is
a pretty good point.
email@example.com - <http://www.ntlug.org/~cbbrowne/linux.html>
The question of whether a computer can think is no more interesting
than the question of whether a submarine can swim.
-- Edsger W. Dijkstra