Proposal for modifying gnucash to use exact quantities

[Steven Murdoch]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Bill Gribble wrote:
> 
> On Sat, Jul 29, 2000 at 01:30:05PM +0100, Steven Murdoch wrote:
> > It seems clear to me that there are many occasions where a value
> > is stored, and it's only permissable values are integers (things
> > like number of shares, bank balance, number of accounts etc...).
> > Bill's API is clearly sufficient for this purpose and already has
> > the required functions to accomodate this, simply by setting the
> > denominator to be one.
> 
> Not exactly.  Bank balances are stored as a denominated integer
> (rational).  The currency of, for example, a US bank account is US
> dollars, so the balance of the account is a balance in US dollars,
> not any other unit (such as, for example, pennies).  The
> *denomination* of the account balance is pennies (1/100 of a US
> dollar) and the value that's stored has a denominator of 100.
One characteristic difference between rational and integer numbers is
that between any two rationals, there are an infinite number of other
rational numbers (excluding bounds on their size), but in between two
integers there only a finite number of integers.
This is theoretical (from my Number Theory course actually) but it
has a practical conclusion:
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.

But I should also stress that this does not impact the correctness of
Bill's proposal. Integers are a subset of rationals so bank balances
can be represented as a pair of 64bit Integers so the API is
sufficient and correct (range is also a consideration but both 128bit
rationals and 64 bit integers have more than enough values for this
application).

However my gut instinct is that the implementation of things that
*can* be represented as integers would be easier if they *were*
represented of integers for several reasons, including:
It would not be necessary to keep track of giving functions the
correct denominator.
You deal with only one value when creating an object.
Makes it more difficult to mix up types and give errors (say
accidentally adding cents to dollars without the conversion would be
hard as everything would be represented in cents.)
Does not allow fractions to creep in where they are not allowed
(multiplying two integrs will always give an integer, but ensuring
that multiplying two gnc_numerics give an integer requires a little
extra work that could be forgotten).
Simplifies positive and negative values (does the numerator or
denominator or bothedefine sign, and if both this complicates the
comparison of values)
etc...

In addition this would also give performance (time and memory)
benefits, but how significant this would be would depend on the
structure of the program (whether API calls are present in deeply
nested loops, or whether large arrays of numerics and processed or
saved to disk) and the time complexity of Bill's API, so should at
least be considered as an option especially since the prevalence of
qnatities the can be represented as integers.

I think everyone agrees that some quantities in gnucash exist in the
set of integers and so can be represented as integers. Whether they
should is a matter of opinion, and since Bill has volenteerd to do
most if not all of they work, he should have a big say in the matter.
My opinion is that adding a pure integer type would be a good idea,
but this is only an opinion of a Ada programmer who has not seen much
of the Gnucash source (I'm learning C for October so this will
hopefully change in the near future), and should be taken as such.


- -- Steven Murdoch.
email: sjmurdoch@linuxfan.com
web: http://www.bigfoot.com/~murdomania/
PGP Keys: http://www.bigfoot.com/~murdomania/contact.htm
Geek Code: http://www.bigfoot.com/~murdomania/geek.htm

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.3 for non-commercial use <http://www.pgp.com>

iQA/AwUBOYNHIl92Njw5pdVdEQK54ACg+CETczSx+c8C4M+JL7FZfxUsHzsAmgNf
lrObkcEeaNk+CZHy6umPYhfH
=V0ne
-----END PGP SIGNATURE-----