Rethinking Numeric: Decimal floats, or Rounding?
Christian Stimming
christian at cstimming.de
Fri Jul 4 16:59:23 EDT 2014
Am Sonntag, 22. Juni 2014, 13:47:49 schrieb John Ralls:
> If we’re going to fix that by rounding, we have to round to a power-of-ten
> denominator, but we have to do it in the right places to avoid accumulating
> errors; for a complex multi-currency transaction that might be to round
> each exchange to the target’s SCU before performing the next exchange;
> interest calculations might be a bit harder. In either case, that won’t
> necessarily prevent a GCD overflow in the presence of a large, weird,
> denominator.
>
> So you proposed digital floats as a way around that problem. I think it’s a
> good alternative, and I pursued it. Why are you now having second thoughts?
Hi John,
I'm not at all against the decimal floating point types. The implementation
looks nice.
However, I probably still didn't get the original problem. It occurred to me
as if some general overflow situation was detected in our 16 byte rational
numbers - which is completely normal for any finite-precision number. But if
such overflow happens during gnucash, it just means that the usual financial
rounding procedures must be applied. As long as we don't round with less
precision that what normal financial procedures are doing, we are fine. With
the exception that sometime we are even fine only if we do exactly the
necessary rounding and don't keep more precision than what the currency or
security in question should hold. We've gone through the discussion at length
so far. This question isn't related to the data type but rather asks whether
our rounding strategy in general needs some changes towards accepted financial
rounding rules. From my understanding, calculations with normal financial
rounding rules can be achieved both with any of the decimal float types in
question, but probably just as well with our existing 16-byte rational number
type.
In other words, from my understanding, switching from 16 byte rationals to 8
byte decimal floats does not make the original problem any worse, but also not
really any better. What did I miss?
Regards,
Christian
More information about the gnucash-devel
mailing list