Proposal for modifying gnucash to use exact quantities
Fri, 28 Jul 2000 06:36:04 -0500
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
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
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,
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.