Rounding in the price db.

[Mike Alexander]

--On August 11, 2015 at 9:20:43 AM +0100 John Ralls 
<jralls at ceridwen.us> wrote:

> Hmm. That’s doable in master with careful rounding control. I’m
> pretty sure it would produce overflows in maint because the old
> int128 math is really int128-int64 and it barfs if any intermediate
> result won’t fit in int64_t. On the other hand, the current
> implementation with no rounding is likely to produce overflows if one
> tries to do a large transaction in Dinars->Dobe (or Bitcoin to a lot
> of minor currencies, for that matter). ISTM arbitrarily setting a
> 10^-10 rounding isn’t quite right, though. If we’re going to do
> something like that, and see the next para, it would be more correct
> to round to the number of digits which make a 1-scu change in the
> smaller currency or perhaps one more digit than that. 10 digits might
> not be enough for converting STD to BTC with its 10^-6 scu.
>
> The whole issue of restricting denominators to powers of 10, implied
> by “significant digits” and “decimal places" is also worthy of
> discussion. Both terms are meaningless with rational numbers unless
> one imposes that constraint. Once one does, though, significant
> digits is no more difficult to implement than decimal places: One
> just rounds the numerator to x digits after doing the denominator
> conversion, adjusting the denominator to account for any reduction of
> the digits in the numerator.
>
> None of which does anything to help deal with the small moves in
> prices due to rounding in the amount and value to their respective
> SCUs getting recorded in the pricedb. Mike’s recommendation to
> capture the user input works in the case where the user inputs (or
> retrieves from F::Q) a price, but not if she uses the
> other-account-amount entry.

This is what I meant.  If she enters two amounts then there's no choice 
but to compute a price.

> IIRC I implemented the price db storage
> as after-rounding-to-scu so that there’d be only one place in the
> code where it was written out. That can be changed easily enough and
> might reduce some of the complaints about the presented price jumping
> around when entering a bunch of foreign currency transactions. *That*
> change could go in maint. I clearly hadn’t sufficiently thought
> through rounding when I started this thread. It seems sufficiently
> complicated that any implementation should go into master instead.

Yes, thinking of it as a rational number problem instead of a decimal 
number problem probably helps.

> We seem to agree that there need be only one price per day in the
> price db, but no one’s said anything about what price that should
> be. I’m inclined towards any new price replaces the existing one
> unless they’re the same. What about source? Should a F::Q price
> take precedence over a transfer dialog price or vice-versa?

My first guess is to take the last price entered and prefer F::Q price 
to a calculated price.  I keep daily F::Q prices back for quite a while 
and when I enter historical transactions it's sometimes annoying when 
it adds a new price for that day.  I usually go back and delete the 
transaction price which is often different from the F::Q price due to 
banks adjusting the rate to their advantage.  I really wouldn't want it 
to delete the F::Q price for that day.  Furthermore if I use F::Q to 
get quotes new F::Q prices should replace transaction prices for that 
day, if any.

It's complicated.  I've always said that I hate dealing with numbers 
and I certainly don't pretend to be an expert on this.

         Mike