Proposal for modifying gnucash to use exact quantities

[Richard Wackerbarth]

On Sun, 30 Jul 2000, Jason Rennie wrote:
> sjmurdoch@linuxfan.com said:
> > In between two bank balances there are a finite number number of other
> > balances, therefore they _can_ be represented by the set of integers.
> > This reasoning is the root of my suggestion to allow restricting
> > allowable values of some variables to integers.
>
> The number of rationals with a denominator of N between the two rationals
> A/N and B/N is finite.  i.e. the number of bank balances between two other
> balances is finite because the denominator is fixed.  Hence, they can be
> represented by a single integer, but ONLY if the denominator is known (or
> if a multiple of the denominator is known).

It is only fixed if there is some mechanism which assures that all values 
which are in the same domain use a common value for that denominator.
Generalized rational math routines do not make that constraint. Using only 
the numerators to represent the balance in a particular account assures that 
the denominator is the same (implied) one.

> If I'm not mistaken, one of the reasons for Bill's proposal being as
> so abstract is that it may be unreasonable to think that we can come up
> with a denominator that will be a multiple of all other quantity
> denominators.

I am not aware that anyone has suggested that there be a "universal" 
denominator. However, all entries within a given domain (an account) will be 
in the same units and share a common denominator. Therefore it is unnecessary 
to carry that denominator with the individual values. It can be retrieved 
from the description of the units in those very few places where it actually 
gets used.

At the moment, the only place that comes to mind is during the conversion 
from integer to text. Please note that just knowing the denominator is not 
sufficient to do this conversion because there are other formatting variables 
(for example currency symbol or decimal/fractional options) that are needed 
in addition to the numeric value.

When you are adding (or subtracting) amounts from a balance, the conversion 
to the appropriate units is done before the addition and not afterward. As a 
result, there is no need for a mathmatical routine which does the post 
addition conversion. Simple integer addition (on whatever data type) is 
sufficient. You never need to know the denominator or provide for rounding in 
this operation.

Similar analysis of the "exchange" function will show that you only need the 
numerators to do a currency conversion.

To convert "Some" units of "Currency_1" to "Equivalent" units of "Currency_2",
we need to know the exchange rate expressed in terms of the two currencies.
In gereral, this is a rational number. For any exchange rate, there exist 
some integers C1 and C2 such that I will receive EXACTLY C2 units of 
"Currency_2" in exchange for EXACTLY C1 units of "Currency_1". For example, 
if the exchange rate were 10.523 pesos per dollar, I could exchange 1000 
cents ($10) for 10523 centavos (105.23 pesos).

If I convert any amount that is not an exact multiple of $10, there will be 
some small roundoff error but I will receive an integral number of cents.
However, to do this math, I still do not need to know the "denominators" for 
the currency.

integer N2 (of currency C2) = convert_to_integer (N1 * C2 / C1)

For bookkeeping, the round_to_integer conversion should be adequate because 
this calculation is only used to express an estimate of the value. Any 
transaction postings will be modified to reflect the actual amounts involved.

For pricing extensions, integer_floor and integer_ceiling will get used in 
certain calculations.

I'm not certain how far gnucash will go in attempting to mimic various 
pricing policies in an effort to automate the building of transactions from a 
minimal amount of input data. It would certainly be nice for me to be able to 
be able to mimic the policy of the payroll department and have each paycheck 
properly broken out into the individual elements just a they do. However, the 
policies involved are rather complex and anyone who is not familiar with 
payroll calculations and programming would probably find it easier to simply 
start with a template that they had manually entered from the first pay stub 
and adjust the amounts to make them match the current stub.