Buddha Buck <[EMAIL PROTECTED]> writes:
> 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.
But when is this acutally a problem in gnucash?
So far, from everything everyone's said. I can't see one place where
switching to some home-grown fixed point solution for the actual
representation has *any* advantage over sticking with 64-bit floating
point. The *only* practical difference I can see would be wrt
performance, and that's just not relevant these days. People are
spending plenty of time making sure that floating point processors are
more than fast enough for our purposes.
The issue of when we need to round our values, and to what extent is
AFAICT a *completely* separable issue from whether or not we represent
them as floating point internally. I'm sure that IEEE 64-bit floats
have far more than enough accuracy to handle any currencies we're
going to run across -- as far as currency-range values are concerned,
the IEEE-64 representation of 1.3 *is* exactly 1/3 because the lossage
is so far out to the right that you'll never see it, and even if
someone can prove me wrong there, then I maintain that the right
solution would just be to see about switching to an arbitrary
precision library, and then we'd still need to ask the same questions
about when and what to round.
So yes there may be times we need to round, but that's not related to
whether or not we use doubles as the underlying representation, and I
suspect that most often the "rounding" will be done by hand because
you'll be entering the values yourself. If the groccery sells apples
3/dollar and you buy two, you'll get charged $0.67, and that's what
you'll enter into gnucash.
IMO
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
