> Richard Wackerbarth writes:
> >
> > When transactions occur, they are rounded. In general, the roundoff error
> > accumulates to an amount which exceeds the displayed precision.
> > We need to model the actual behavior rather than approximating it.
> >
> > This can only be done by knowing the rounding precision of each transaction.
> > Therefore, we must track the 'primitive units'.
>
> Could you give a concrete example of this for the purposes of discussion?
I buy peaches at 3/$1. If I buy them one at a time, each transaction
is rounded, and I get 1 peach for $0.33. After three such
transactions, I've spent $0.99 for 3 peaches. The rounding error
accumulated in my favor.
I buy apples at 3/$2. If I buy them one at a time, each transaction is
rounded, and I get 1 peach for $0.67. After three transactions, I've
spent $2.01 for 3 apples. The rounding error accumulated in my
grocer's favor.
Or, for a more GnuCash-ish example...
I have a couple of outstanding student loans, which I am dilligently
paying back. Every month, I make a student loan payment of a fixed
amount, on a fixed date, etc. This is the perfect scenario for the (as
I understand it) not-yet-completed scheduled recurring transaction
functions of GnuCash.
But the transactions are not perfectly identical. This months payment
of $p is going to pay interest at an annual rate of r, and the rest is
going to principle. So what I'd really like to happen is for each
recurring transaction to have a Journal Entry like so:
x/14/00 Student Loan Payment
Checking account $p
Interest on Loans $B*r/12
Stafford Loan Balance $p-$B*r/12
where $B is the previous balance on the student loan.
The problem comes with the computation of $B*r/12, since this is
unlikely to come out to an integral number of cents. If $B is $20,000,
r is 8%, then this works out to $B*r/12 = $133.3333333333, which gets
rounded (in real life) to simply $133.33. Which means that if my loan
payment was (say) $250, then I'd pay $116.67 towards the principle.
I'd want GnuCash to record that as interest of $133.33, principle of
$116.67, since that is what my creditor will record it as.
If GnuCash recorded the balances internally as FP numbers, then the
amounts wouldn't get rounded off. The difference would be small, true,
but over time could result in the GnuCash computed values differing
from the "real" values significantly, where a cent may be considered
"significant".
(BTW, is the recurring transaction system going to be able to handle
transactions like that? That seems like a fairly common type of
recurring transaction.)
>
> thanks,
> dave
>
> --
> Gnucash Developer's List
> To unsubscribe send empty email to: [EMAIL PROTECTED]
>
>
--
Buddha Buck [EMAIL PROTECTED]
"Just as the strength of the Internet is chaos, so the strength of our
liberty depends upon the chaos and cacophony of the unfettered speech
the First Amendment protects." -- A.L.A. v. U.S. Dept. of Justice
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
