Rounding in the price db.

[Hajo Hindriks]

On 10.08.2015 01:29, 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 solved this problem in the Advanced Portfolio report by recording 
> prices derived from transactions with 8 decimal places. This seemed 
> large enough to avoid losing precision for very small prices, but 
> small enough to avoid overflows in computations. Perhaps we should do 
> that for the price DB too.
>
>> Related but somewhat separate, does it make sense to record more than
>> one price per day in the price db? If so, should we suppress saving
>> the price if it’s unchanged, perhaps within some tolerance, of the
>> previous entry on the same day? If not, do we keep the first entry or
>> overwrite every entry so that we end up with the last (entered) entry
>> for a particular day?
>>
>> The point would be to not store a bunch of data that we don’t use
>> and to present users with more useful defaults in the transfer dialog
>> when they’re entering a bunch of transactions for the same day and
>> the same currencies/commodities. What are the possible bad impacts,
>> particularly in reports, especially the Advanced Portfolio Report?
>
> Recording only one price per day probably is a good idea.  I think 
> there may already be code that won't record a price if the same price 
> is there on the same day, but I'm not sure what the definition of 
> "same" is.
>
>         Mike
>
>
I don't know much about the inner workings of gc but I think it doesn't 
make sense to keep several quotes per day, I don't think there is a use 
case to keep intraday quotes.

I recently started with Gnucash and am writing a small perl script to 
fetch quotes, and I am keeping only one quote per day, updating the 
previous one from the same day. Later on I plan to add those quotes to 
the gnucash data file. Currently I just read the commodities of a 
gnucash file and keep the quotes in a separate file.

Hajo