In the message below, Bill Gribble points out some "intrinsic" problems
with how GnuCash deals with currency amounts.
It has been pointed out by some others (as well as myself) that at least
some "commercial" systems (notably in COBOL) use "fixed point"
representations. My very limited experience with "business"-type languages
is that fixed-point representations are quite common in those languages,
though in my much greater experience with engineering/scientific languages
"fixed-point" data types (other than "integer" and variants on it) are rare
to the point of vanishing. (FWIW, I write customized "engineering" compilers
for a living.)
A thought has occurred to me: A possible solution would be to "migrate"
to C++ (not a humongous project, since a quick look through a "tar -tvzf"
of a source-tarball reveals that it's mostly in C) and then use C++'s
ability to "overload" the normal operators to, in essence, construct
"custom fixed-point data types".
This approach has the advantage that it can probably be implemented without
re-writing a lot of existing code (I'm saying this without having actually
looked at the existing code, so there's a fair amount of room for "not"
on that "probably"). There would be a fair amount of modification needed,
but it would be mostly in terms of declaring and initializing variables.
Indeed, it might be worthwhile doing some searching to see if there are
existing "fixed-point" C++ packages that could be used -- and if none
are turned up, put one together as a "by-product".
The down-side is that the code will probably run somewhat slower than
had it been implemented "directly" in C -- however, we're NOT talking
about an accounting package that will will be used to, say, print the
paychecks for the U.S. Post Office. :-) I suspect that a few extra
milliseconds per transaction would not be noticed by most users... I'd
be surprised if it slowed it down much more than a couple hundred milli-
seconds per transaction.
Anyway, it's a thought. :-)
Clark
Bill Gribble wrote:
>
> After discussion with some of the other developers, it is becoming
> clear that most if not all of the problems people are having with
> rounding and fractional cents are because, in fact, gnucash does not
> know that there is a minimimum quantum of transactions for certain
> types of accounts. This is an attempt to lay out the problem and a
> possible solution. Please discuss.
>
> Bill Gribble
>
> ======================
>
> PROBLEM: gnucash does not take into consideration the possibility
> that a financial institution may not conduct transactions in fractional
> currency units.
>
> EXAMPLE: purchase 1 share of "foo" at 9 7/8 (9.875) from "bank".
> "bank" balance is displayed as -9.88 (which is correct). purchase 1
> more share of "foo" at 9 7/8 from "bank", in another transaction.
> "bank" balance is displayed as -19.75. This is incorrect, since it
> implies that the intermediate balance was -9.875 rather than (as
> was displayed) -9.88.
>
> In fact, the displayed value "-9.88" is rounded from the actual
> double-precision representation of the amount, -9.875. The transfer
> from the bank should have been, in each separate transaction, an
> integer number of pennies (localized appropriately) meaning that the
> bank balance should be -19.76.
>
> This demonstrates the way in which gnucash currently represents all
> quantities as double-precision floats and rounds these as appropriate
> *for display only*.
>
> PROPOSED SOLUTION: there must be account-type-specific (localized for
> currency) rules describing the minimum unit of transaction for a
> particular type of account and what to do with fractionally-unbalanced
> amounts. For example, it should be possible to restrict bank-account
> transfers to integer pennies but allow for fractional-cent balances in
> brokerage accounts if the brokerage handles the accounting in this
> way. QUESTION: what types of accounts have what types of
> transaction-quanta in the real world?
>
> SIDE EFFECTS: In the case described in the EXAMPLE, 9.88 should be
> transferred from the bank to purchase 1 share at 9.875. The remaining
> 1/2 cent must be accounted for.
>
> Accounting for the fractional amount:
>
> Alternative 1 is to add a split to the transaction which transfers the
> remaining fractional amount into an account designated for such
> things. For security accounts, this could be a "commissions" account,
> since the 1/2 cent is effectively a tiny commission on the
> transaction. This has the drawback of being confusing to naive users.
>
> Alternative 2 is to fractionally adjust the price per share to reflect
> the "true cost" of the shares purchased. In the EXAMPLE,
> price-per-share would be adjusted to 9.88, since the purchaser did
> have to transfer 9.88 to purchase each share, though the market price
> was 9.875. This has the drawback of having possibly surprising
> effects on the total value of holdings in an account. example:
> purchase 10,000 @ 9 7/8. total holdings == $98750. then purchase 1
> more at 9 7/8, price rounded up to 9.88, total holdings == $98809.88,
> an unexpected jump of $50.
>
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: [EMAIL PROTECTED]
--
Disclaimer: The opinions expressed herein are mine and not necessarily
those of anyone else. (As if anyone else would want them!)
Internet: [EMAIL PROTECTED] RF: KI7TU
ICBM: 33 22' 01" N 111 43' 52" W Home Page: www.inficad.com/~jones
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
