Clark Jones <[EMAIL PROTECTED]> writes:
> Well, floating point is definitely NOT the proper solution for US dollars
That's not what we are talking about. We know that floating point is
a bad solution. The point I was trying to raise was that "fixed
point" implies decimal fractions, but there are plenty of places that
we need non-decimal fractions. They can still be represented exactly
(i.e. non floating point), just not using a decimal-fixed-point
library.
> The one place I can think of where you still see fractions commonly is
> in stockmarket quotations, e.g., nonsense like "73 213/256". However,
> the SEC has told the U.S. stock markets "thou shalt decimalize", and though
> I don't recall off hand exactly when the deadline is, it's within the next
> few months.
Partially true, but stock prices are an important part of gnucash, and
while the US stock exchange is going decimal "pretty soon", there are
historical prices which will always be in 64ths and the bond market is
not likely to decimalize any time soon (according to Jon Trowbridge,
who does this stuff for a living; is that a correct interpretation of
your mail to me?).
handling integer-penny balances in bank accounts is the easy part of
the problem that we have to address. The harder part is correct
handling of stock/mutual transactions with fractional-penny results
and how that interacts with the smallest-transaction-amount of
currencies. Thus it makes sense to have all the parts of the equation
(price, share amount, and total value) represented in the same form,
which I argue should be more akin to a rational number than to decimal
fixed point. I am working on a more concrete proposal about this
which I'll probably send around early next week.
Bill Gribble
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
