Proposal for modifying gnucash to use exact quantities

Christopher Browne cbbrowne@hex.net
Wed, 02 Aug 2000 07:58:21 -0500


On Wed, 02 Aug 2000 06:53:18 EST, the world broke into rejoicing as
Richard Wackerbarth <rkw@dataplex.net>  said:
> On Tue, 01 Aug 2000, Christopher Browne wrote:
> 
> > > Placing this unification code inside the addition code is a computational
> > > burden on EVERY addition, even the vast majority (if not all) of the
> > > additions which are performed on ammounts from the same account that are
> > > already in the same representation and need no coersion.
> >
> > I disagree fairly strongly; the problem with this unification has
> > _nothing_ to do with computational burden, but lies in the fact that the
> > only way it is _sensible_ to add two amounts is if they are denominated
> > in the _same commodity_.
> >
> > For instance, you _can't_ add an amount in $USD to an amount in $CDN;
> > this has _nothing_ to do with whether or not this addition will be
> > computationally expensive, but rather to do with the fact that the
> > result _doesn't make sense_.  $25 USD + $35 CDN does not represent a
> > valid single value.
> 
> Here, I think the question degenerates into "What is a commodity?"
> 
> You and I view "$/8 USD" and "$/100 USD" as two different commodities. OTOH, 
> I believes that Bill views them as the same commodity and feels that it is 
> permissible to add them. I don't think that anyone proposes to add $USD to 
> $CND.

Actually, I wouldn't regard "$/8 USD" as being a commodity at all either.

The time you'd get $/8 USD is as a part of a _price_, such as where RHAT
trades at "64 1/8 dollars per share".  Note that the only thing that we
can sensibly do with a price is to multiply it by the "denominating"
commodity, in the described case, by some quantity of RHAT stock.

> In reality, I guess the difference in thought is that Bill proposes to allow 
> addition of rational amounts with the result converted to some particular 
> quantification and you and I would require that the amounts be converted to 
> the quantification units before the addition.

Bill's API doesn't directly address the issue of conversion of quantities,
or of what commodity is "in use;" all it provides is a tool for working
with rational numbers.  It assumes that code elsewhere will address
making sure that amounts that are to be operated on are "compatible."

> I argue that the latter is the way that commerce is conducted.
> Each sub transaction is converted into the monetary units in which the 
> transaction is to be conducted and the resulting moneys are added.
> 
> Thus, if I purchase 1/5 carload of widgets and 1/4 carload of widgets at 
> $1999.95 per carload, the transaction will be computed as:
> 
> 1/5 carload             $399.99
> 1/4 carload             $499.99
>                         _______
> Total                   $899.98
> 
> rather than
> 
> 1/5 carload + 1/4 carload = 9/20 carload
> 9/20 carload            $899.98

Actually, I would think that both of the above expressions could be
perfectly valid ways of charging someone for those "widgets."

The first represents adding together dollars; the second represents
adding together widgets.  Which approach should be taken is neither a
mathematical issue nor an one of "accounting theory," but is, instead,
a policy decision that different organizations should be free to decide
on differently.

For instance, if 15 people each seek to buy 100 shares of RHAT stock,
and, by requesting this of one brokerage, the resulting purchase that
the _brokerage_ makes might aggregate the quantities into one purchase of
1500 shares on NASDAQ.  Accounting for the _purchase_, that's 1 purchase
of 1500 shares.  When the broker transfers the shares to the individual
accounts, that then takes place with individualized quantities of RHAT
stock, but the effect on the _bank_ comes from a total of the 15 prices,
in $USD.

Hopefully that example makes sense; the point is that in different
kinds of transactions, it may make sense to denominate things somewhat
differently...
--
cbbrowne@acm.org - <http://www.hex.net/~cbbrowne/lsf.html>
The nice thing about Windows is  - It does not just crash, it displays
a dialog box and lets you press 'OK' first.  (Arno Schaefer's .sig)