Proposal for modifying gnucash to use exact quantities

[Christopher Browne]

On Thu, 27 Jul 2000 19:42:37 -0400, the world broke into rejoicing as
Terry <tboldt@attglobal.net>  said:
> 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.

Unfortunately, all Bill has provided is a way of representing and
manipulating rational values.  There's nothing particularly _wrong_ or
awful about having that.  I don't think we need to go so far as to burn
the proposal, strew the ashes in a field, and sow the field with salt,
broken glass, and powdered plutonium so that nothing useful can ever
grow there again.  (Other opinions may vary :-).)

But I don't think it represents what people really need to do with
_financial amounts_.

Once we get that library, the conclusion is liable to be:
"Well, now let's build something that works with transactions, and
adds, prices, and values them."

I'd rather put the emphasis on that next higher level library, which
might look more like:

struct finamt {
  numerator Q;   /* Might be a rational value, if need be... */
  commodity C;
};

struct commodity {
  string IDENTIFIER;
  string NAME;
  integer DENOMINATOR /* for $USD, $CDN, 100, as $1.00 is expressed
                         as 100 */
  integer MULTIPLIER  /* for Lira, where the minimum quanta is
                         something like 1000, this is 1000 */
  /* the two amounts here allow scaling up and down */
};

struct price {
  numerator N;
  denominator D;
  commodity *FROM;
  commodity *TO;
}:

We then have:

finamt add_amounts ( finamt a, finamt b );
finamt sub_amounts ( finamt a, finamt b );
finamt sum_amt_seq ( finamt *SEQ );
finamt translate_value ( finamt amt, price p );

Note that there would need to be some preconditions here.  For instance,
you can only add amounts for compatible commodities.  Adding dollars to
soybeans doesn't work.  Unless we introduce:

finamt add_amounts_with_coercion ( finamt result, finamt addition )
  where inside the function, it looks for a conversion rate so that
  "addition" may be coerced into the commodity that "result" references.

This set of operators came off the top of my head, and there is a bit
of an assumption that amounts are integers, and that the denominators
sit in the commodity.  Relax/strengthen that as needed.

People shouldn't and won't be coding using the "rational division"
operator; they should be writing financial code that sums up sequences
of transaction values.  Or converting a value from one commodity to
another.

It may be that we could use the API that Bill has described to help
implement the next one, but I think it's the operators to work with
commodities and quantities thereof that need the attention.
--
cbbrowne@ntlug.org - <http://www.ntlug.org/~cbbrowne/lsf.html>
History of Epistemology in One Lesson
"First Hume said "We can't really know anything", but nobody believed
him, including Hume. Then Popper said "Hume was right, but here's what
you can do instead...". Bartley then debugged Popper's code."
-- Mark Miller