Rob Browning said...
> 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?
This isn't... After all, as you say below, I'd enter 0.33 for each
peach, based on my receipt, and all is well.
But I did give another example, which you don't make reference to,
which deals -specifically- to 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 main reason I have for integer/fixed point over floating point is
because the domain of the problem is fixed point arithmetic, not
floating point.
You are a scheme programmer, right? I maintain that IEEE floating
point is optimised for inexact real computations. As such, it is an
ideal represenation of Scheme inexact real classes. On the otherhand,
I also think that accounting, by it's nature, is -exact-. As such,
using an inexact type when a suitable exact type exists (or can be made
to exist) is not useful.
Consider this: The -vast- majority of operations on currency done in
accounting are addition, with subtraction being a close second. We
never multiply currencies by currencies. When we do multiply
currencies by scalers, we -always- immediately round, so that we
maintain the same number of decimal places. And we also compare
currency values -- if for no other reason than to assure that the books
balance. We do that commonly by adding everything up and comparing
to 0.
As a counterpoint, addition and subtraction is one of the weaknesses of
floatingpoint numbers, whereas they are an optimised representation for
multiplication/division. And another traditional weakness is in
floating point equality comparisons. And comparisons with 0 are
particularly prone.
> 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.
IEEE does have sufficient precision such that if rounding is done
-consistantly-, everytime and -when- a currency value gets multiplied
by an arbitrary double, we will likely never run into an error after
rounding, even given the inherent problems with floating point addition
and subtraction. Except possibly with comparisons -- Sure, both
$175.53/7 and $526.59/21 will both round to something that will display
as $25.07, but are those two values internally equal?
> 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.
What about the recurring transaction I mentioned in my last message?
The transaction was a $250 payment on a loan, automatically split
between interest (computed as a percentage of the outstanding
principle) and the principle (computed as $250-interest)?
>
> IMO
IMO, as well...
>
> --
> Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
>
> --
> 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]
