On Fri, 16 Jun 2000, Rob Browning wrote:
> 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 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.
> 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,
I agree that the underlying representation is not the problem.
The problem is that people are bypassing the class wrapper and doing
operations directly on these values. It is this misuse which is the problem.
For example, if I add up a series of 10,000 transactions, I must convert the
intermediate results back to "exact" money so that the error does not
accumulate.
> 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.
Well, gnucash is already messing up my brokerage account because of its
mishandling of shares, prices, and amounts
Remember that accounting is a COUNTING
and counting is done in integers
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
