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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel