Rounding in the price db.

[John Ralls]

> On Aug 10, 2015, at 10:34 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> On Sunday 09 August 2015 19:29:51 Mike Alexander wrote:
>> --On August 9, 2015 at 8:35:04 PM +0100 John Ralls
>> <jralls at ceridwen.us>
>> wrote:
>>> A recent IRC conversation and a discussion (face to face!) with a
>>> user got me thinking about the prices entered from the transfer
>>> dialog into the price db. The current situation is that when the
>>> user
>>> creates a transaction between accounts with differing currencies and
>>> commodities, the transfer dialog comes up to get either a price or
>>> the value in the “other” currency. The user duly enters a number
>>> and GC does the appropriate calculation, rounding the value to the
>>> max denominator for the “other” account’s currency/commodity,
>>> then recalculating the “true” price without the rounding and
>>> saves the result in the price db. The user could do several entries
>>> with the same nominal exchange rate and get a different exact
>>> fraction for each because of the rounding of the value.
>>> 
>>> Does that really make sense? Should we round the price we store in
>>> the price db to some reasonable fraction? What fraction? The
>>> smallest
>>> commodity unit (scu) of the “value” currency/commodity seems
>>> reasonable to me. For example, if the entry is of  how many US
>>> Dollars buys a Euro or a share of Ford stock, the price should be
>>> rounded to the scu of US Dollars, i.e. cents. OTOH some mutual funds
>>> price in mils ($.0001), so perhaps we should round the price db
>>> entries to
>> 
>> No, that doesn't make sense.  I've been bothered by this for some
>> time.
>> 
>> However, I don't think rounding to the SCU of either commodity is
>> correct.  Suppose the SCU of A and B is 2 and the official exchange
>> rate from A to B is 1.500555 (my bank quotes rates to 6 decimal places
>> when I buy foreign currency).  If I first convert 2.00 A to 3.00 B by
>> entering this exchange rate in the transfer dialog it would record an
>> exchange rate of 1.50.  Later a value of 2000 A would be converted by
>> default to 3000 B, not 3001.11.  I think you need to record more
>> digits than the SCU.  Ideally you should record exactly what is
>> entered in the transfer dialog if the user enters a price rather than
>> a destination value.  If they enter a destination value then you
>> probably should record at least 6 places after the decimal point.
>> 
>> Things get tricky if the ratio is very small.  The current rate for
>> USD per Sao Tomean Dobra per USD is 0.0000444615.  if you rounded
>> this to 0.000044, you lose a lot of precision.  If someone enters a
>> transaction of 1000 Dobra to USD .04 (unlikely, but valid) then the
>> recorded rate to 2 places would be zero which is clearly a bad idea.
>> 
> I seem to remember that banks here use 6 significant digits in exchange 
> rates, which is not quite the same as 6 places after the decimal point. 
> Your USD-Sao Tomean Dobra illustrates this: due to the extreme value 
> difference between the two you need 10 digits after the decimal point, 
> but only 6 of them are significant (ie not a leading zero).
> 
> Is this something our gnc_numeric code supports and can be used by the 
> price db ?

We have “significant digits” rounding code, but IIRC it’s really six decimal places. If we were to have real significant digits we’d need to be careful to keep it away from the debits-and-credits code or it could make a real mess.

Regards,
John Ralls