Ben Stanley wrote:
>
> Hendrik Boom wrote:
>
> > I've always been doubtful about the use of floating point by gnucash.
>
> The problem with floating point types is that they only provide an approximation to
> what you want.
>
[ snipped ]
>
> 1/2 = 0.5 > 0.1, so we have 0 * 2^-1.
> 1/4 = 0.25 > 0.1, so we have 0 * 2^-2.
> 1/8 = 0.125 > 0.1, so we have 0 * 2^-3.
>
[ snipped ]
> results.) However, in a financial application, we need to reliably track every last
> cent (or penny, or yen, or whatever). Thus, I feel that the double type is
> eminently unsuitable.
>
> What's the solution to this problem?
>
> I will first mention a historical solution - this probably bears little relevance
> to what we should do, but anyway...
>
> I seem to remember that the 6502 microprocessor, which was used in the C64, > had a
>BCD flag. When it was enabled, it entered a special mode, where all
> math operations assumed that each byte held 2 decimal digits, ...
[ snipped ]
>
> Alternately, integers have no rounding error. However, they are susceptible
> to overflow. Their range is ...
>
PL/I tried to do EVERYTHING that had been done before.
Even the subset used on CP/M boxes (ie, S-100) had integers, floating
point, and BCD (Binary-Coded-Decimal). The subset left out Complex :-((
"money" problems could be worked in BCD, even if they were part of an
engineering calculation that was mostly floating point. Financial
presentations meant to rank wished-for projects can be done in floating
point, even the net-present-worth stuff, because the overall
approximation is good enough. Monthly credit card interest charges may
have internal rounding, but the month end is rounded to $0.01. Corporate
Accounting departments are leary of engineers who make shortcut (but
useful :-) math routines for keeping track of money!!
Stanley Long, PE
Consulting Electrical Engineer
Anchorage, Alaska
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
