# Proposal for modifying gnucash to use exact quantities]

**Richard Wackerbarth**
rkw@dataplex.net

*Fri, 28 Jul 2000 05:02:57 -0500*

On Fri, 28 Jul 2000, Christopher Browne wrote:
>* <Warning: I'm playing a mathematician playing with a bit of number theory
*>* here, and am decidedly _NOT_ taking an accounting approach...>
*>*
*>* We could probably do _pretty well_ with some fixed base if we used a base
*>* with quite a lot of useful divisors. For instance, 360 has, as factors:
*>* 2, 3, 4, 5, 6, 8, 9, 10, 12, 15, 18, 20, 24, 30, 36, 40, 45,
*>* 60, 72, 90, 120, and 180
*>*
*>* 240 has a similarly large set of factors, which allows ...
*
>* Admittedly, 1/7 and 1/11 are still continuing fractions,
*>* but any values that are representable as
*>* v = 2^k * 3^l * 5^m
*>* can _all be represented _exactly_, and that's pretty valuable.
*
The problem with any proposal that attempts to use a base other than the
exact base needed for the particular commodity in question is that this
permits the value to take on unpermitted values. By mapping the consecutive
permitted values onto consecutive integers and limiting the representation to
integral values, we are assured that we are representing all the permissible
values and no others.
As for representing {price, exchange rates, average cost, etc.} by anything
less expressive than a pair of integers, we lose the ability to properly
compute certain needed values such as cost basis allocation.
When it come to representing INTEGERS, the base used does not matter. Any
base can be used. The representation chosen should be determined by other
considerations such as dynamic range, hardware efficiency, or I/O
requirements.