Proposal for modifying gnucash to use exact quantities

[Richard Wackerbarth]

On Thu, 27 Jul 2000, Terry wrote:
> On Thu, 27 Jul 2000, you wrote:
> > Bill's proposal is to implement operations on a representation that can
> > express not only integral SCUs, but more general expressions. In using
> > this representation, it will be necessary to add appropriate constraints
> > and conversions to assure that the stored values never represent a value
> > which is not an integral number of SCUs.
> > On the other hand, my proposal is to store these amounts as integral SCUs
> > and implement the arithmatic operations within the few financial
> > operations that we will actually use.

> Richard, I'm curious (sometimes fatal :-) ) Bill has put together a fairly
> detailed proposal and implementation using rationals.

> I haven't seen a
> similar single discription and corresponding implementation on your
> proposal.

I haven't made it in that form because it is too trivial.
Bill has defined a complex infrastructure to attack a simple problem.

At the level of Bill's proposal, I have:

typedef gnc_amount; ANY representation of integers what satisfies the dynamic 
range required for a particular use.  Note that I, personally, will never 
have an account with a balance the size of the national debt. As a result, it 
is only wasteful to force me to use extremely large integers to store small 
amounts. The storage scheme should carry with formatting information which 
would allow conversion of the representation between different versions of 
gnucash.
This representation might be gint64, BCD, etc. The ONLY routines that should 
care are the few routines that I mention below which actually implement the 
math. At higher levels, it is sufficient to know that it is an amount.

gnc_amount gnc_add(gnc_amount a, gnc_amount b);
gnc_amount gnc_subtract(gnc_amount a, gnc_amount b);
We may wish to extend this to
gnc_amount gnc_sum( gnc_amount a, gnc_amount b, gnc_amount c, ...);

gnc_amount gnc_exchange(gnc_amount apples_exchanged, gnc_amount oranges, 
gnc_amount for_apples);

This routine does the conversion with rounding.
When we get beyond accounting and into pricing, ceiling and floor versions of 
this routine will be required to implement pricing policy. However, they are 
not necessary for the bookkeeping because all addition is exact and exchanges 
are just estimates which are subject to revision to match the actual 
transaction. I would make these separate functions rather than burden and 
obfuscate the ordinary case with the extra parameters necessary to fold all 
of these cases into one common function call.

The interesting functions are those which actually handle the functionality 
of transactions such as displaying values.

I would handle this by a pointer to a structure which carries the information 
about the preferences for handling particular kinds of amounts.
These are similar to the gnc_currency items that Bill has proposed.

As I have said before, we don't need MATH routines. We need to define 
FINANCIAL routines. Until those routines are defined, it is premature to 
attempt to define the precise math routines that are appropriate.

I am still waiting for Bill, or someone else, to show how his implementation 
will simplify the actual higher level routines that we need to implement.

I view Bill's implementation like Southwest Parkway, a multi-million dollar 
roadway leading nowhere. It was a fine roadway, but did not serve a real 
purpose because it addressed a non-existant need. It cost additional millions 
to convert it into something useful.

PLEASE, plan before you implement.