--On August 11, 2015 at 9:20:43 AM +0100 John Ralls
<jra...@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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
