Proposal for modifying gnucash to use exact quantities

Buddha Buck
Fri, 28 Jul 2000 09:56:06 -0400

At 08:14 AM 7/28/00 -0500, Christopher Browne wrote:

>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 */

How do DENOMINATOR and MULTIPLIER interact?  Is only one active at a time?

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

Since in your picture FROM is associated with D, TO associated with N (I'm 
assuming), would not something like:

struct price {
   finamt FROM;
   finamt TO;

be a little bit better?

>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 );

translate_value looks like it -might- deal with the "invoice extension" 
problem.  But I don't know if it is thorough enough.  Since GnuCash doesn't 
deal with invoices yet, it isn't a major issue, but there are people out 
there who like to see the estimated market value of their securities 

The most complicated "invoice extension" problem I've heard of on this list 
is some futures contracts, which would have a unit of contracts (of 1000 
bushels), prices in the 1/8 cent/bushel, and values in the 1/100 dollar.  I 
believe I even heard that those prices are quoted relative to the current 
market value of the underlying currency, so that the prices might even be 
negative at time.

Does your API provide a way to compute estimated value (in $/100) of N 
contracts (of 1000 bushels each) at price P (in $/800 per bushel)?

>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.

I'm not sure what use this would really be.  When would we want to add 
dollars to soybeans?

>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
>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.
> - <>
>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
>gnucash-devel mailing list