gnucash maint: Bug 779217 - Transactions rounded to 5 decimal places when opening file.

[John Ralls]

> On Mar 11, 2017, at 8:05 AM, John Ralls <jralls at ceridwen.us> wrote:
> 
>> 
>> On Mar 11, 2017, at 3:26 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
>> 
>> On vrijdag 10 maart 2017 22:28:03 CET John Ralls wrote:
>>> Updated	 via  https://github.com/Gnucash/gnucash/commit/3889606d (commit)
>>> 	from  https://github.com/Gnucash/gnucash/commit/bc50f3da (commit)
>>> 
>>> 
>>> 
>>> commit 3889606dd6779564341247ec796a905b54d36426
>>> Author: John Ralls <jralls at ceridwen.us>
>>> Date:   Fri Mar 10 13:21:02 2017 -0800
>>> 
>>>   Bug 779217 - Transactions rounded to 5 decimal places when opening file.
>>> 
>>>   xaccSplitSetValue and xaccSplitSetAmount round to the denominator found
>>> by get_currency_denom and get_commodity_denom. The problem was that if the
>>> commodity was unfindable because either the split’s parent or account
>>> hadn’t been set (as is the case during loading, because the parent
>>> isn’t yet complete) the returned denominator would be 100000, smaller
>>> than the max supported. That would cause the value/amount to be prematurely
>>> rounded.
>>> 
>>> diff --git a/src/engine/Split.c b/src/engine/Split.c
>>> index 8d34c23..6ed3a4e 100644
>>> --- a/src/engine/Split.c
>>> +++ b/src/engine/Split.c
>>> @@ -928,7 +928,7 @@ get_currency_denom(const Split * s)
>>>    }
>>>    else if (!s->parent || !s->parent->common_currency)
>>>    {
>>> -        return 100000;
>>> +        return 1000000; /* Max supported denom to avoid premature rounding.
>> 
>> How about defining this number in gnc_numeric and using this definition 
>> everywhere the max supported denom is used ?
>> 
>> Is this restriction the same in master ?
> 
> Geert,
> 
> A large part of my motivation for rewriting the numeric code was to make enough headroom to expand it to 10^ for master in order to support Bitcoin and that looney mutual fund in Slovenia, and I think that it should be defined in GncNumeric. I'd like to make that a stand-alone commit in master rather than buried in a bug fix, which is why I didn't do it here.
> 

Huh. The 9 in 10^9 got lost.
It should say "enough headroom to expand it to 10^9 for  master".

Regards,
John Ralls