Proposal for modifying gnucash to use exact quantities

[Richard Wackerbarth]

On Thu, 27 Jul 2000, Steven Murdoch wrote:
> I've been thinking about storing gnc_numberic as a rational number and
> had a look at some finance/law/accounting books and I thought that there
> is one potential problem that may occur, please correct me if I'm wrong
> or have misunderstood the proposal.
>
> I don't want to make a theoretical point so I'll do my best to restrict
> this to features either existing in Gnucash or conceivable to be added.
>
> Say I buy 10 shares at 123_1/64 pence each. Gnucash will represent this
> as 7873/64 pence per share so the total transaction value will be
> 78730/64 pence. My dealer will pay the seller of the shares 1231 pence,
> and I will be billed for £12.31 as sellers round up.

So far, so good.

> Gnucash will then remove 78730/64 pence from my share buying account and
> correctly display this as -£12.31.

No. Gnucash should remove 1231 pence from your account. The account does not 
have 1/64ths of a pence.

> The reason for the error is obvious, banks store balances as an integer
> number of SCUs (BCD to be precise).

The actual format is unimportant. The important aspect is that the 
representation can EXACTLY represent the amount in question.

The primary problem in the current implementation is not that they have used 
floating point to represent the account balance but that they have used 
DOLLARS or POUNDS rather than CENTS or PENCE. You cannot make an exact 
representation of one CENT in floating point DOLLARS.

The other problem is that they have failed to perform the rounding mentioned 
above.

> You cannot trade in a anything less
> than a SCU, banks will let you store anything less than a SCU and you
> cannot get coins or notes in anything less than a SCU - it is therefore
> reasonable to say that anything less than a SCU is not valid currency.
> So storing an account balance to a precision of less than a SCU is at
> best meaningless at at worst can lead to 'errors'.

Correct.

> The way I see it (which could perhaps be the wrong way) is that Gnucash
> tracks the balance of various types of accounts in a similar way to what
> banks do, and if banks store their data in BCD then we should really do
> the same. To put it another way Gnucash tracks *money* which is a
> discontinuous quantity.

Again, you are relating the format of the storage to the expressiveness of it.
Any format that can express the same values can be used.

> As for exchange rates, yes they are ratios between one currency and
> another and could be represented as rationals (in practice however they
> are always shown as decimals for ease of use and computation), but this
> is not important. 

> What is important is when the deal goes though, you
> either receive or pay an integer number of SCUs and this is what Gnucash
> should store.

Yes. I think that this has now been recognized by all of the principal 
participants in this discussion.

The discussion is now about how to represent those integral numbers of SCUs.
Bill's proposal is to implement operations on a representation that can 
express not only integral SCUs, but more general expressions. In using this 
representation, it will be necessary to add appropriate constraints and 
conversions to assure that the stored values never represent a value which is 
not an integral number of SCUs.
On the other hand, my proposal is to store these amounts as integral SCUs and 
implement the arithmatic operations within the few financial operations that 
we will actually use.