Rethinking Numeric

[John Ralls]

On Jun 22, 2014, at 12:35 PM, Christian Stimming <christian at cstimming.de> wrote:

> Am Samstag, 21. Juni 2014, 16:24:21 schrieb John Ralls:
>> I’ve got the start of the trial implementation pushed to
>> https://github.com/jralls/gnucash/tree/libmpdecimal. It builds, but it
>> doesn’t pass all of the tests yet. I think it’s quite promising and I’ll
>> keep working on it, but I wanted to give everyone a chance to see what it
>> looks like. So far I’m leaving the existing API in place to simplify
>> getting it working, but you’ll notice that the guts of the implementation
>> is in a C++ wrapper to make it easy to use directly as the C++ rewrite
>> progresses.
> 
> Hi John,
> 
> well, the new code and gnc_numeric implementation looks very interesting. 
> However, I still do not quite understand what you are trying to fix here. You 
> said "overflows", but I argued earlier in this discussion that the existence 
> of overflows in itself is most probably not a problem because our business 
> logic requirements will most probably require rounding anyway much earlier 
> before we run into overflows. If the problem is in this direction, shouldn't 
> we rather try to clarify the rounding requirements and implement those 
> correctly, rather than adding more significant digits to our number data type?

Christian,

You’re the one who suggested switching to decimal floats. I said I'd do a test implementation, and it’s far enough along to show, so I have.

The overflows that show up periodically as failures in test-numeric occur in the GCD determination that’s part of most rational arithmetic operations, before rounding takes place. Mike Alexander explained why that happens; it’s part of the nature of rational math, and we’ve clamped the maximum size of the random numbers in test-numeric at 44 bits to get the tests to pass most of the time. They still fail occasionally when the random number generator produces an unfortunate set of inputs.

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?

Regards,
John Ralls