# Proposal for modifying gnucash to use exact quantities

Christopher Browne cbbrowne@hex.net
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 <gordo@pincoya.com>  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.
--
aa454@freenet.carleton.ca - <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

```