On Thu, 27 Jul 2000 21:48:30 MST, the world broke into rejoicing as
Gordon Oliver <[EMAIL PROTECTED]> 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
calculated via:
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
_two_ values:
a) There are 25.255 units of mutual fund.
b) The cost is $438.02 USD; that's what I paid the broker for
the units.
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 PROTECTED] - <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
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
