Buddha Buck <[EMAIL PROTECTED]> writes:
> 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.
Except that there's the practical argument to be made. *If* doubles
are for for all intents and purposes accurate enough that we wouldn't
ever notice the difference between them and a scaled integer
representation, then the current solution using doubles has the *vast*
advantage of existence and simplicity, and if doubles really are
functionally equivalent, presuming we round at the right times, they
also allow more flexibility. If we decide we *need* to represent 1/3,
we can (more or less), whereas with the integer representation, we'd
be stuck.
> 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?
In the abstract, I understand the point you're making here, and I tend
to agree with you, but I'm having a hard time thinking of a time where
an equality test like this would be meaningful. That doesn't mean
there aren't plenty of times like that, though.
> 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)?
I would maintain that the code doing the "automatic splitting" would
be responsible for the rounding, or does that not solve the problem?
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
