On Sun, 30 Jul 2000, Jason Rennie wrote:
> [EMAIL PROTECTED] 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.
_______________________________________________
gnucash-devel mailing list
[EMAIL PROTECTED]
http://www.gnumatic.com/cgi-bin/mailman/listinfo/gnucash-devel
