Proposal for modifying gnucash to use exact quantities]

[Richard Wackerbarth]

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.