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