Re: Rounding in the price db.

[John Ralls]

> On Sep 22, 2015, at 6:59 AM, David Carlson  
> wrote:
> 
> Testing git rev 766cf48+ on 2015-09-18, I have a report using "Nearest in 
> Time" price reference.  There is an F::Q price for January 30 2015 in the db 
> and a user:split-register price has now appeared for February 1 that is 
> slightly off because the transaction that generated it was for 2.203 shares 
> at $10.16 totalling $22.38.  That translates to 10.158874 per share in 
> GnuCash.  Now my January 31 2015 report is off by $0.67 for that security and 
> also for a couple of other securities with the same issue.  Last January the 
> report was correct.  I know that there has been discussion about having a 
> report option that would not select following-day prices and here is the 
> example of why I think it is needed.  This year is bad that way, February May 
> and October present the same situation.  Going back and adding a lot of bogus 
> weekend prices just to get good reports would be a pain.

I agree. It’s https://bugzilla.gnome.org/show_bug.cgi?id=743753, BTW. I haven’t 
looked into it but I think the code in question is in the report module, which 
is beyond the scope of this particular set of changes. It’s also been the 
behavior for all of 2.6.x.

> 
> By the way, when I went into the price db to add a price for January 31, I 
> noticed that the February 1 price was labelled as unknown type and no source 
> was shown in the edit window, just in the list.  I thought the source used to 
> be shown in the edit window as well.  That is not a real issue, but when I 
> edited the February 1 price to 10.16 the source was not changed to user: 
> price-editor as it should have been.

No, the edit dialog hasn’t ever shown the source. I did notice that using the 
price editor doesn’t change the source, also historical behavior. It hasn’t 
mattered in the past, of course: Source and type were just info for the user. 
Now that it’s more important I suppose that the edit price dialog should 
accurately reflect the source.

Type is another issue. The original idea was to identify *quotes* as Bid, Ask, 
Last, and NAV (meaning respectively the price the market-maker will pay for 
your shares, the price at which he’s selling shares, the price of the last 
trade, and the Net Asset Value calculated by the mutual fund company the 
previous afternoon and used for all trades on the day). The edit price dialog 
allows the user to select among those; Finance::Quote may report Bid, Ask, and 
Last but the GnuCash parser always captures Last if it’s available. F::Q 
unfortunately doesn’t designate NAV, reporting it only as Last — and I think 
you noticed at one point that it’s for the wrong day. I think I should add a 
type “actual” for prices generated by transactions, perhaps replacing 
“unknown”. Since it’s there only for user info I left it alone.

>  
> Also, I happened to be sitting on February 1 when I selected Add new price.  
> I put the focus on the date in the editor window and pressed the minus key 
> the date changed to January 30.  Pressing the plus key then correctly 
> advanced the date to January 31.

Odd, but not related to calculating prices.
> I hope those are the only issues.

So do I.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[David Carlson]

Testing git rev 766cf48+ on 2015-09-18, I have a report using "Nearest in
Time" price reference.  There is an F::Q price for January 30 2015 in the
db and a user:split-register price has now appeared for February 1 that is
slightly off because the transaction that generated it was for 2.203 shares
at $10.16 totalling $22.38.  That translates to 10.158874 per share in
GnuCash.  Now my January 31 2015 report is off by $0.67 for that security
and also for a couple of other securities with the same issue.  Last
January the report was correct.  I know that there has been discussion
about having a report option that would not select following-day prices and
here is the example of why I think it is needed.  This year is bad that
way, February May and October present the same situation.  Going back and
adding a lot of bogus weekend prices just to get good reports would be a
pain.

By the way, when I went into the price db to add a price for January 31, I
noticed that the February 1 price was labelled as unknown type and no
source was shown in the edit window, just in the list.  I thought the
source used to be shown in the edit window as well.  That is not a real
issue, but when I edited the February 1 price to 10.16 the source was not
changed to user: price-editor as it should have been.
Also, I happened to be sitting on February 1 when I selected Add new
price.  I put the focus on the date in the editor window and pressed the
minus key the date changed to January 30.  Pressing the plus key then
correctly advanced the date to January 31.
I hope those are the only issues.

David C

On Sun, Sep 20, 2015 at 3:58 PM, John Ralls  wrote:

>
> > On Sep 20, 2015, at 6:35 AM, David Carlson 
> wrote:
> >
> > By hard to read, I mainly mean that the new section 6.2 now contains
> four note bullets that at least appear to be warnings about exceptions or
> special cases or something.  The first one starts out with "The following
> sections will..." but it isn't clear where that reference ends.  Maybe it
> and the parts that it references should be indented or in a box or
> delimited by some sort of paragraph or topic separator icon.  If it only
> applies to the three numbered sentences, then changing it to read "The
> following numbered sections will..." would likely suffice.
> >
> >  I really did not want to make specific suggestions until I could
> understand why each sentence is there and how they fit together.  I have
> not reached that point, so my suggestions may not even work.
> >
> > Is it possible to have the page clearly divided into a section that
> describes what it is intended to do followed by a section of details how to
> use it?
> >
>
> Sure is, and I’ve done it. It will be in the documentation nightlies (
> http://www.gnucash.org/viewdoc.phtml?rev=trunk=C=help) tomorrow
> morning.
>
> Regards,
> John Ralls
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[David Carlson]

Oh, I completely forgot to mention that the new documentation page is much
better.  Sorry about forgetting to mention that.

David C

On Tue, Sep 22, 2015 at 8:59 AM, David Carlson 
wrote:

> Testing git rev 766cf48+ on 2015-09-18, I have a report using "Nearest in
> Time" price reference.  There is an F::Q price for January 30 2015 in the
> db and a user:split-register price has now appeared for February 1 that is
> slightly off because the transaction that generated it was for 2.203 shares
> at $10.16 totalling $22.38.  That translates to 10.158874 per share in
> GnuCash.  Now my January 31 2015 report is off by $0.67 for that security
> and also for a couple of other securities with the same issue.  Last
> January the report was correct.  I know that there has been discussion
> about having a report option that would not select following-day prices and
> here is the example of why I think it is needed.  This year is bad that
> way, February May and October present the same situation.  Going back and
> adding a lot of bogus weekend prices just to get good reports would be a
> pain.
>
> By the way, when I went into the price db to add a price for January 31, I
> noticed that the February 1 price was labelled as unknown type and no
> source was shown in the edit window, just in the list.  I thought the
> source used to be shown in the edit window as well.  That is not a real
> issue, but when I edited the February 1 price to 10.16 the source was not
> changed to user: price-editor as it should have been.
> Also, I happened to be sitting on February 1 when I selected Add new
> price.  I put the focus on the date in the editor window and pressed the
> minus key the date changed to January 30.  Pressing the plus key then
> correctly advanced the date to January 31.
> I hope those are the only issues.
>
> David C
>
> On Sun, Sep 20, 2015 at 3:58 PM, John Ralls  wrote:
>
>>
>> > On Sep 20, 2015, at 6:35 AM, David Carlson 
>> wrote:
>> >
>> > By hard to read, I mainly mean that the new section 6.2 now contains
>> four note bullets that at least appear to be warnings about exceptions or
>> special cases or something.  The first one starts out with "The following
>> sections will..." but it isn't clear where that reference ends.  Maybe it
>> and the parts that it references should be indented or in a box or
>> delimited by some sort of paragraph or topic separator icon.  If it only
>> applies to the three numbered sentences, then changing it to read "The
>> following numbered sections will..." would likely suffice.
>> >
>> >  I really did not want to make specific suggestions until I could
>> understand why each sentence is there and how they fit together.  I have
>> not reached that point, so my suggestions may not even work.
>> >
>> > Is it possible to have the page clearly divided into a section that
>> describes what it is intended to do followed by a section of details how to
>> use it?
>> >
>>
>> Sure is, and I’ve done it. It will be in the documentation nightlies (
>> http://www.gnucash.org/viewdoc.phtml?rev=trunk=C=help) tomorrow
>> morning.
>>
>> Regards,
>> John Ralls
>>
>>
>>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

> On Sep 20, 2015, at 6:35 AM, David Carlson  
> wrote:
> 
> By hard to read, I mainly mean that the new section 6.2 now contains four 
> note bullets that at least appear to be warnings about exceptions or special 
> cases or something.  The first one starts out with "The following sections 
> will..." but it isn't clear where that reference ends.  Maybe it and the 
> parts that it references should be indented or in a box or delimited by some 
> sort of paragraph or topic separator icon.  If it only applies to the three 
> numbered sentences, then changing it to read "The following numbered sections 
> will..." would likely suffice.
> 
>  I really did not want to make specific suggestions until I could understand 
> why each sentence is there and how they fit together.  I have not reached 
> that point, so my suggestions may not even work.
> 
> Is it possible to have the page clearly divided into a section that describes 
> what it is intended to do followed by a section of details how to use it?
> 

Sure is, and I’ve done it. It will be in the documentation nightlies 
(http://www.gnucash.org/viewdoc.phtml?rev=trunk=C=help) tomorrow 
morning.

Regards,
John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

> On Sep 19, 2015, at 10:51 AM, David Carlson  
> wrote:
> 
> On 9/19/2015 11:17 AM, John Ralls wrote:
>>> On Sep 19, 2015, at 8:59 AM, David Carlson  
>>> wrote:
>>> 
>>> I have installed the weekly build dated the 18th and started testing.  I
>>> really like the new appearance of the transfer dialog screen,  I have not
>>> yet switched to a disposable copy of my data file, so I have not tried test
>>> transactions yet.
>> New appearance? There isn’t any change there, all of the changes are to how 
>> it calculates and stores prices.
>> 
>>> I think that the new help for the transfer dialog, while no doubt accurate,
>>> is very hard to understand.  Perhaps someone can help us make it easier to
>>> read.
>> Could you elaborate on that a bit?
>> 
>> Regards,
>> John Ralls
>> 
>> 
> 
> Perhaps it was a context thing that made the difference with the
> transfer dialog.  Starting from the Transfer button, the box was
> understandable and  happened to have preselected a security account so
> the two ratio boxes were understandable enough that one of them looked
> like a price per share even though the word price was absent.  That
> wasn't the way it looked in the past when I would get slapped by it
> while trying to enter stock transactions and I wasn't even expecting it
> to appear.

Yes, it does look different when you start it with the Transfer button from 
when it’s brought up to get a price or exchange rate. In the latter case all of 
the controls above the Exchange Rate panel are disabled. It would be better if 
they were hidden just like it would be better if the “Exchange Rate” labels 
changed to “Price” when the “From” commodity is non-currency. I intend to make 
those changes, just not in the release branch.

> 
> The new help page is hard to read but I want to try the new logic that
> it is describing before I make any suggestions for changes.

There are three changed help pages, 6.2 Transfer Funds Dialog Box, 6.5 Multiple 
Currency/Commodity Transactions, and 8.6 Price Editor.

“Hard to read” means to me that the sentences are too complex or the words too 
long. Is that what you mean?

Regards,
John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[David Carlson]

On 9/19/2015 11:17 AM, John Ralls wrote:
>> On Sep 19, 2015, at 8:59 AM, David Carlson  
>> wrote:
>>
>> I have installed the weekly build dated the 18th and started testing.  I
>> really like the new appearance of the transfer dialog screen,  I have not
>> yet switched to a disposable copy of my data file, so I have not tried test
>> transactions yet.
> New appearance? There isn’t any change there, all of the changes are to how 
> it calculates and stores prices.
>
>> I think that the new help for the transfer dialog, while no doubt accurate,
>> is very hard to understand.  Perhaps someone can help us make it easier to
>> read.
> Could you elaborate on that a bit?
>
> Regards,
> John Ralls
>
>

Perhaps it was a context thing that made the difference with the
transfer dialog.  Starting from the Transfer button, the box was
understandable and  happened to have preselected a security account so
the two ratio boxes were understandable enough that one of them looked
like a price per share even though the word price was absent.  That
wasn't the way it looked in the past when I would get slapped by it
while trying to enter stock transactions and I wasn't even expecting it
to appear.

The new help page is hard to read but I want to try the new logic that
it is describing before I make any suggestions for changes.

David C

.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

> On Sep 19, 2015, at 8:59 AM, David Carlson  
> wrote:
> 
> I have installed the weekly build dated the 18th and started testing.  I
> really like the new appearance of the transfer dialog screen,  I have not
> yet switched to a disposable copy of my data file, so I have not tried test
> transactions yet.

New appearance? There isn’t any change there, all of the changes are to how it 
calculates and stores prices.

> 
> I think that the new help for the transfer dialog, while no doubt accurate,
> is very hard to understand.  Perhaps someone can help us make it easier to
> read.

Could you elaborate on that a bit?

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[David Carlson]

I have installed the weekly build dated the 18th and started testing.  I
really like the new appearance of the transfer dialog screen,  I have not
yet switched to a disposable copy of my data file, so I have not tried test
transactions yet.

I think that the new help for the transfer dialog, while no doubt accurate,
is very hard to understand.  Perhaps someone can help us make it easier to
read.

Those are a couple of initial impressions.

David C

On Fri, Sep 18, 2015 at 12:55 PM, Geert Janssens  wrote:

> On Friday 18 September 2015 06:56:47 John Ralls wrote:
> > > On Sep 12, 2015, at 12:20 PM, John Ralls  wrote:
> > >> On Sep 9, 2015, at 6:20 PM, John Ralls  wrote:
> > >>> On Sep 5, 2015, at 8:44 AM, John Ralls  wrote:
> >  On Sep 4, 2015, at 2:17 AM, Geert Janssens
> >   wrote:
> >  On Tuesday 01 September 2015 15:13:48 John Ralls wrote:
> > >> Geert,
> > >>
> > >> Thanks for testing. I agree that the check_foo() semantics are
> > >> clumsy. I did it that way to avoid negating the return value in
> > >> the
> > >> if conditional, but in retrospect that would be clearer, so
> > >> I’ll
> > >> flip it.
> > >>
> > >> Roger that the checks aren’t reliably bidirectional. I’ll dig
> > >> into
> > >> that. I hadn’t yet changed anything with regards to which
> > >> direction
> > >> prices are recorded, at least not on purpose, so I’ll have to
> > >> track
> > >> that down too.
> > >>
> > >> I coded up the price-rounding algorithm on the flight back
> > >> today and
> > >> played with it a little. I think it may need some adjustment.
> > >
> > > I’ve pushed more changes to single-price which I think address
> > > Geert’s comments and some tweaks to maximize significant digit
> > > preservation while keeping denominators <= 10E6 in most cases.
> > > Please test some more!
> > >
> > > Regards,
> > > John Ralls
> > 
> >  John,
> > 
> >  I pulled your branch again yesterday and ran some tests on it
> >  this morning.
> > 
> >  Here is what I did today:
> > 
> >  - removed all prices from the price db.
> >  - created an invoice in EUR
> >  - added one entry to this invoice to an account denominated in
> >  USD
> >  - post the invoice => as expected this brings up the transfer
> >  dialog to get an exchange rate. - as I removed all prices
> >  beforehand, there was no suggested price (obviously), so I hit
> >  fetch quotes => When fetch quotes finished, I still didn't have
> >  an exchange rate entered in the dialog. - so to continue I
> >  entered one myself
> >  - close transfer dialog and chech the price db via the price
> >  editor
> >  => There are two quotes in there now:
> >  Security EUR, Currency USD, type user:xfer-dialog
> >  Security USD, Currency EUR, type Finance::Quote (last)
> > 
> >  The latter seems to have been fetched successfully by the
> >  transfer dialog but was never proposed. The former is the price
> >  I had to manually enter to continue.
> > 
> >  The exact same thing happens if I now use process payment and for
> >  test pay this (Euro denominated) invoice in HKD. Transfer dialog
> >  won't propose an exchange rate even after hitting the fetch
> >  quotes button. Setting one manually will allow me to continue
> >  and afterwards there will be two new quotes in the price editor
> >  Security EUR, Currency HKD, type user:xfer-dialog
> >  Security HKD, Currency EUR, type Finance::Quote (last)
> > 
> >  Looks like the transfer dialog is not yet fully aware of
> >  bidirectional quotes.>>>
> > >>> Not just the Transfer Dialog. Price-quotes.scm doesn’t read the
> > >>> output from gnc-fq-helper quite the way I thought it did. This
> > >>> weekend’s pretty busy but I should be able to fix it Monday along
> > >>> with finishing the source prioritization.>>
> > >> So I’ve got that fixed along with some other issues and the
> > >> preference of some sources and it’s pushed to my github branch.
> > >> It’s doing too much rounding somewhere so that our Sao Tomé Dobra
> > >> test gets rounded to uselessness in one direction, but I think the
> > >> rest is working. Please test while I wrestle some more with the
> > >> rounding.>
> > > Rounding is now fixed and pushed.
> > >
> > > There’s one change I’m holding back on: If I make it so that
> > > Finance::Quote can’t overwrite a price added in the Price Editor
> > > (i.e. one of source user:price-editor) as David Carlson suggested
> > > last week, then the “fetch quote” button is broken because
> > > price-quotes.scm only knows how to write the prices into the
> > > pricedb. This is a per-day effect: A user-created quote from a
> > > different day won’t block 

Re: Rounding in the price db.

[Geert Janssens]

On Friday 18 September 2015 06:56:47 John Ralls wrote:
> > On Sep 12, 2015, at 12:20 PM, John Ralls  wrote:
> >> On Sep 9, 2015, at 6:20 PM, John Ralls  wrote:
> >>> On Sep 5, 2015, at 8:44 AM, John Ralls  wrote:
>  On Sep 4, 2015, at 2:17 AM, Geert Janssens
>   wrote: 
>  On Tuesday 01 September 2015 15:13:48 John Ralls wrote:
> >> Geert,
> >> 
> >> Thanks for testing. I agree that the check_foo() semantics are
> >> clumsy. I did it that way to avoid negating the return value in
> >> the
> >> if conditional, but in retrospect that would be clearer, so
> >> I’ll
> >> flip it.
> >> 
> >> Roger that the checks aren’t reliably bidirectional. I’ll dig
> >> into
> >> that. I hadn’t yet changed anything with regards to which
> >> direction
> >> prices are recorded, at least not on purpose, so I’ll have to
> >> track
> >> that down too.
> >> 
> >> I coded up the price-rounding algorithm on the flight back
> >> today and
> >> played with it a little. I think it may need some adjustment.
> > 
> > I’ve pushed more changes to single-price which I think address
> > Geert’s comments and some tweaks to maximize significant digit
> > preservation while keeping denominators <= 10E6 in most cases.
> > Please test some more!
> > 
> > Regards,
> > John Ralls
>  
>  John,
>  
>  I pulled your branch again yesterday and ran some tests on it
>  this morning.
>  
>  Here is what I did today:
>  
>  - removed all prices from the price db.
>  - created an invoice in EUR
>  - added one entry to this invoice to an account denominated in
>  USD
>  - post the invoice => as expected this brings up the transfer
>  dialog to get an exchange rate. - as I removed all prices
>  beforehand, there was no suggested price (obviously), so I hit
>  fetch quotes => When fetch quotes finished, I still didn't have
>  an exchange rate entered in the dialog. - so to continue I
>  entered one myself
>  - close transfer dialog and chech the price db via the price
>  editor
>  => There are two quotes in there now:
>  Security EUR, Currency USD, type user:xfer-dialog
>  Security USD, Currency EUR, type Finance::Quote (last)
>  
>  The latter seems to have been fetched successfully by the
>  transfer dialog but was never proposed. The former is the price
>  I had to manually enter to continue.
>  
>  The exact same thing happens if I now use process payment and for
>  test pay this (Euro denominated) invoice in HKD. Transfer dialog
>  won't propose an exchange rate even after hitting the fetch
>  quotes button. Setting one manually will allow me to continue
>  and afterwards there will be two new quotes in the price editor
>  Security EUR, Currency HKD, type user:xfer-dialog
>  Security HKD, Currency EUR, type Finance::Quote (last)
>  
>  Looks like the transfer dialog is not yet fully aware of
>  bidirectional quotes.>>> 
> >>> Not just the Transfer Dialog. Price-quotes.scm doesn’t read the
> >>> output from gnc-fq-helper quite the way I thought it did. This
> >>> weekend’s pretty busy but I should be able to fix it Monday along
> >>> with finishing the source prioritization.>> 
> >> So I’ve got that fixed along with some other issues and the
> >> preference of some sources and it’s pushed to my github branch.
> >> It’s doing too much rounding somewhere so that our Sao Tomé Dobra
> >> test gets rounded to uselessness in one direction, but I think the
> >> rest is working. Please test while I wrestle some more with the
> >> rounding.> 
> > Rounding is now fixed and pushed.
> > 
> > There’s one change I’m holding back on: If I make it so that
> > Finance::Quote can’t overwrite a price added in the Price Editor
> > (i.e. one of source user:price-editor) as David Carlson suggested
> > last week, then the “fetch quote” button is broken because
> > price-quotes.scm only knows how to write the prices into the
> > pricedb. This is a per-day effect: A user-created quote from a
> > different day won’t block the F::Q quote, so maybe it’s an
> > acceptable corner case that just needs to be mentioned in the docs
> > and the button’s tooltip. Ideally the button should disable in this
> > situation, but I’m not sure yet whether that’s feasible.
> > 
> > Comments?
> > 
> > I should add that I want to merge this ASAP so that it will be
> > available in the nightlies for testing before the next release,
> > which is only two weeks away.
> I’ve merged it to maint and after a couple of build hiccups on Win32
> it’s in today’s maint nightly:
> http://code.gnucash.org/builds/win32/maint/gnucash-2.6.7-2015-09-18-g
> it-766cf48+-setup.exe
> 
> Documentation changes are included in the nightly and also in the
> 

Re: Rounding in the price db.

[John Ralls]

> On Sep 12, 2015, at 12:20 PM, John Ralls  wrote:
> 
> 
>> On Sep 9, 2015, at 6:20 PM, John Ralls  wrote:
>> 
>>> 
>>> On Sep 5, 2015, at 8:44 AM, John Ralls  wrote:
>>> 
 
 On Sep 4, 2015, at 2:17 AM, Geert Janssens  
 wrote:
 
 On Tuesday 01 September 2015 15:13:48 John Ralls wrote:
>> Geert,
>> 
>> Thanks for testing. I agree that the check_foo() semantics are
>> clumsy. I did it that way to avoid negating the return value in the
>> if conditional, but in retrospect that would be clearer, so I’ll
>> flip it.
>> 
>> Roger that the checks aren’t reliably bidirectional. I’ll dig into
>> that. I hadn’t yet changed anything with regards to which direction
>> prices are recorded, at least not on purpose, so I’ll have to track
>> that down too.
>> 
>> I coded up the price-rounding algorithm on the flight back today and
>> played with it a little. I think it may need some adjustment.
> I’ve pushed more changes to single-price which I think address Geert’s
> comments and some tweaks to maximize significant digit preservation
> while keeping denominators <= 10E6 in most cases. Please test some
> more!
> 
> Regards,
> John Ralls
 
 John,
 
 I pulled your branch again yesterday and ran some tests on it this morning.
 
 Here is what I did today:
 
 - removed all prices from the price db.
 - created an invoice in EUR
 - added one entry to this invoice to an account denominated in USD
 - post the invoice => as expected this brings up the transfer dialog to 
 get an exchange rate.
 - as I removed all prices beforehand, there was no suggested price 
 (obviously), so I hit fetch quotes
 => When fetch quotes finished, I still didn't have an exchange rate 
 entered in the dialog.
 - so to continue I entered one myself
 - close transfer dialog and chech the price db via the price editor
 => There are two quotes in there now:
 Security EUR, Currency USD, type user:xfer-dialog
 Security USD, Currency EUR, type Finance::Quote (last)
 
 The latter seems to have been fetched successfully by the transfer dialog 
 but was never proposed. The former is the price I had to manually enter to 
 continue.
 
 The exact same thing happens if I now use process payment and for test pay 
 this (Euro denominated) invoice in HKD.
 Transfer dialog won't propose an exchange rate even after hitting the 
 fetch quotes button. Setting one manually will allow me to continue and 
 afterwards there will be two new quotes in the price editor
 Security EUR, Currency HKD, type user:xfer-dialog
 Security HKD, Currency EUR, type Finance::Quote (last)
 
 Looks like the transfer dialog is not yet fully aware of bidirectional 
 quotes.
>>> 
>>> Not just the Transfer Dialog. Price-quotes.scm doesn’t read the output from 
>>> gnc-fq-helper quite the way I thought it did. This weekend’s pretty busy 
>>> but I should be able to fix it Monday along with finishing the source 
>>> prioritization.
>> 
>> So I’ve got that fixed along with some other issues and the preference of 
>> some sources and it’s pushed to my github branch. It’s doing too much 
>> rounding somewhere so that our Sao Tomé Dobra test gets rounded to 
>> uselessness in one direction, but I think the rest is working. Please test 
>> while I wrestle some more with the rounding.
> 
> Rounding is now fixed and pushed.
> 
> There’s one change I’m holding back on: If I make it so that Finance::Quote 
> can’t overwrite a price added in the Price Editor (i.e. one of source 
> user:price-editor) as David Carlson suggested last week, then the “fetch 
> quote” button is broken because price-quotes.scm only knows how to write the 
> prices into the pricedb. This is a per-day effect: A user-created quote from 
> a different day won’t block the F::Q quote, so maybe it’s an acceptable 
> corner case that just needs to be mentioned in the docs and the button’s 
> tooltip. Ideally the button should disable in this situation, but I’m not 
> sure yet whether that’s feasible.
> 
> Comments?
> 
> I should add that I want to merge this ASAP so that it will be available in 
> the nightlies for testing before the next release, which is only two weeks 
> away.

I’ve merged it to maint and after a couple of build hiccups on Win32 it’s in 
today’s maint nightly:
http://code.gnucash.org/builds/win32/maint/gnucash-2.6.7-2015-09-18-git-766cf48+-setup.exe

Documentation changes are included in the nightly and also in the Documentation 
nightly at http://gnucash.org/viewdoc.phtml?rev=trunk=C=help. English 
only until German and Italian translators have a go at it. The new 
documentation is in the Help, sections 6.2 Transfer Funds Dialog Box and 6.5 
Multiple Currency Translations. Feedback 

Re: Rounding in the price db.

[Chris Good]

> Message: 1
> Date: Sat, 12 Sep 2015 12:20:46 -0700
> From: John Ralls <jra...@ceridwen.us>
> To: Geert Janssens <geert.gnuc...@kobaltwit.be>
> Cc: gnucash-devel@gnucash.org
> Subject: Re: Rounding in the price db.
> Message-ID: <4a7c3475-9787-4346-bfd7-f086dcd78...@ceridwen.us>
> Content-Type: text/plain; charset=utf-8
> 
...
> 
> Rounding is now fixed and pushed.
> 
> There?s one change I?m holding back on: If I make it so that
Finance::Quote
> can?t overwrite a price added in the Price Editor (i.e. one of source
> user:price-editor) as David Carlson suggested last week, then the ?fetch
> quote? button is broken because price-quotes.scm only knows how to write
> the prices into the pricedb. This is a per-day effect: A user-created
quote
> from a different day won?t block the F::Q quote, so maybe it?s an
acceptable
> corner case that just needs to be mentioned in the docs and the button?s
> tooltip. Ideally the button should disable in this situation, but I?m not
sure
> yet whether that?s feasible.
> 
> Comments?
> 
> I should add that I want to merge this ASAP so that it will be available
in the
> nightlies for testing before the next release, which is only two weeks
away.
> Regards,
> John Ralls
> 
> 
> --
> 
> Message: 2
> Date: Sat, 12 Sep 2015 18:50:36 -0700 (PDT)
> From: david.carlson@gmail.com  <david.carlson@gmail.com>
> To: jra...@ceridwen.us, geert.gnuc...@kobaltwit.be
> Cc: gnucash-devel@gnucash.org
> Subject: Re: Rounding in the price db.
> Message-ID: <000f4259.651417a17ddc3...@gmail.com>
> Content-Type: text/plain; charset="utf-8"
> 
> I could accept your proposal if it is documented. I think a user could
still go
> in later if he didn't like the online price for a certain date.
> Sent from my LG G Pad 7.0 LTE, an AT 4G LTE tablet
> --

Hi John,

Sorry for the late reply, needs must...

I haven't understood all your previous comments about this but thought I'd
weigh in anyway.
Can there only be 1 price record per stock/date?

I would have thought the primary key should be stock/date/source and that
the advanced portfolio rpt should get actual cost details from the stock
transactions and market price details from price records. If there are
multiple price records of the same stock/date, then the advamced portfolio
rpt should use say using source user:price-editor first, then a price from
FQ, (then others...)

AFAIK, it is not critical that the market price be accurate as the
costs/values on the stock transactions should be accurate.
That's why I suggested prices from FQ should use the date returned by FQ and
assume that if there is already a price record for the same stock/date from
FQ, then the new price should override the older.

Regards,
Chris Good


smime.p7s
Description: S/MIME cryptographic signature
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

> On Sep 16, 2015, at 12:01 AM, Chris Good <chris.g...@ozemail.com.au> wrote:
> 
>> Message: 1
>> Date: Sat, 12 Sep 2015 12:20:46 -0700
>> From: John Ralls <jra...@ceridwen.us>
>> To: Geert Janssens <geert.gnuc...@kobaltwit.be>
>> Cc: gnucash-devel@gnucash.org
>> Subject: Re: Rounding in the price db.
>> Message-ID: <4a7c3475-9787-4346-bfd7-f086dcd78...@ceridwen.us>
>> Content-Type: text/plain; charset=utf-8
>> 
> ...
>> 
>> Rounding is now fixed and pushed.
>> 
>> There?s one change I?m holding back on: If I make it so that
> Finance::Quote
>> can?t overwrite a price added in the Price Editor (i.e. one of source
>> user:price-editor) as David Carlson suggested last week, then the ?fetch
>> quote? button is broken because price-quotes.scm only knows how to write
>> the prices into the pricedb. This is a per-day effect: A user-created
> quote
>> from a different day won?t block the F::Q quote, so maybe it?s an
> acceptable
>> corner case that just needs to be mentioned in the docs and the button?s
>> tooltip. Ideally the button should disable in this situation, but I?m not
> sure
>> yet whether that?s feasible.
>> 
>> Comments?
>> 
>> I should add that I want to merge this ASAP so that it will be available
> in the
>> nightlies for testing before the next release, which is only two weeks
> away.
>> Regards,
>> John Ralls
>> 
>> 
>> ------
>> 
>> Message: 2
>> Date: Sat, 12 Sep 2015 18:50:36 -0700 (PDT)
>> From: david.carlson@gmail.com  <david.carlson@gmail.com>
>> To: jra...@ceridwen.us, geert.gnuc...@kobaltwit.be
>> Cc: gnucash-devel@gnucash.org
>> Subject: Re: Rounding in the price db.
>> Message-ID: <000f4259.651417a17ddc3...@gmail.com>
>> Content-Type: text/plain;charset="utf-8"
>> 
>>I could accept your proposal if it is documented. I think a user could
> still go
>> in later if he didn't like the online price for a certain date.
>> Sent from my LG G Pad 7.0 LTE, an AT 4G LTE tablet
>> --
> 
> Hi John,
> 
> Sorry for the late reply, needs must...
> 
> I haven't understood all your previous comments about this but thought I'd
> weigh in anyway.
> Can there only be 1 price record per stock/date?
> 
> I would have thought the primary key should be stock/date/source and that
> the advanced portfolio rpt should get actual cost details from the stock
> transactions and market price details from price records. If there are
> multiple price records of the same stock/date, then the advamced portfolio
> rpt should use say using source user:price-editor first, then a price from
> FQ, (then others...)
> 
> AFAIK, it is not critical that the market price be accurate as the
> costs/values on the stock transactions should be accurate.
> That's why I suggested prices from FQ should use the date returned by FQ and
> assume that if there is already a price record for the same stock/date from
> FQ, then the new price should override the older.

Chris,

Please read over the thread again carefully. We’ve already discussed all of 
that in some detail. In particular, actual cost for reports comes from the 
transactions, not the price db.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Geert Janssens]

On Wednesday 16 September 2015 06:52:14 John Ralls wrote:
> > On Sep 16, 2015, at 12:01 AM, Chris Good <chris.g...@ozemail.com.au> wrote:
> >> Message: 1
> >> Date: Sat, 12 Sep 2015 12:20:46 -0700
> >> From: John Ralls <jra...@ceridwen.us>
> >> To: Geert Janssens <geert.gnuc...@kobaltwit.be>
> >> Cc: gnucash-devel@gnucash.org
> >> Subject: Re: Rounding in the price db.
> >> Message-ID: <4a7c3475-9787-4346-bfd7-f086dcd78...@ceridwen.us>
> >> Content-Type: text/plain; charset=utf-8
> > 
> > ...
> > 
> >> Rounding is now fixed and pushed.
> >> 
> >> There?s one change I?m holding back on: If I make it so that
> > 
> > Finance::Quote
> > 
> >> can?t overwrite a price added in the Price Editor (i.e. one of
> >> source
> >> user:price-editor) as David Carlson suggested last week, then the
> >> ?fetch quote? button is broken because price-quotes.scm only knows
> >> how to write the prices into the pricedb. This is a per-day
> >> effect: A user-created> 
> > quote
> > 
> >> from a different day won?t block the F::Q quote, so maybe it?s an
> > 
> > acceptable
> > 
> >> corner case that just needs to be mentioned in the docs and the
> >> button?s tooltip. Ideally the button should disable in this
> >> situation, but I?m not> 
> > sure
> > 
> >> yet whether that?s feasible.
> >> 
> >> Comments?
> >> 
> >> I should add that I want to merge this ASAP so that it will be
> >> available> 
> > in the
> > 
> >> nightlies for testing before the next release, which is only two
> >> weeks> 
> > away.
> > 
> >> Regards,
> >> John Ralls
> >> 
> >> 
> >> --
> >> 
> >> Message: 2
> >> Date: Sat, 12 Sep 2015 18:50:36 -0700 (PDT)
> >> From: david.carlson@gmail.com  <david.carlson@gmail.com>
> >> To: jra...@ceridwen.us, geert.gnuc...@kobaltwit.be
> >> Cc: gnucash-devel@gnucash.org
> >> Subject: Re: Rounding in the price db.
> >> Message-ID: <000f4259.651417a17ddc3...@gmail.com>
> >> Content-Type: text/plain;  charset="utf-8"
> >> 
> >>I could accept your proposal if it is documented. I think a user
> >>could> 
> > still go
> > 
> >> in later if he didn't like the online price for a certain date.
> >> Sent from my LG G Pad 7.0 LTE, an AT 4G LTE tablet
> >> --
> > 
> > Hi John,
> > 
> > Sorry for the late reply, needs must...
> > 
> > I haven't understood all your previous comments about this but
> > thought I'd weigh in anyway.
> > Can there only be 1 price record per stock/date?
> > 
> > I would have thought the primary key should be stock/date/source and
> > that the advanced portfolio rpt should get actual cost details from
> > the stock transactions and market price details from price records.
> > If there are multiple price records of the same stock/date, then
> > the advamced portfolio rpt should use say using source
> > user:price-editor first, then a price from FQ, (then others...)
> > 
> > AFAIK, it is not critical that the market price be accurate as the
> > costs/values on the stock transactions should be accurate.
> > That's why I suggested prices from FQ should use the date returned
> > by FQ and assume that if there is already a price record for the
> > same stock/date from FQ, then the new price should override the
> > older.
> 
> Chris,
> 
> Please read over the thread again carefully. We’ve already discussed
> all of that in some detail. In particular, actual cost for reports
> comes from the transactions, not the price db.
> 
> Regards,
> John Ralls
> 
> 
Chris' mention of the primary key should be stock/date/source triggered another 
question in 
my mind. So far I always considered "source" in this context to be F::Q vs user 
input vs 
whatever other means.

But now I started wondering is gnucash/F::Q supports tracking multiple stock 
exchanges for a 
single stock ? (Eg track gold price on both London stock exchange and on 
Amsterdam stock 
exchange) ?

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

> On Sep 16, 2015, at 8:42 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> 
> wrote:
> 
> On Wednesday 16 September 2015 06:52:14 John Ralls wrote:
> > > On Sep 16, 2015, at 12:01 AM, Chris Good <chris.g...@ozemail.com.au 
> > > <mailto:chris.g...@ozemail.com.au>> wrote:
> > >> Message: 1
> > >> Date: Sat, 12 Sep 2015 12:20:46 -0700
> > >> From: John Ralls <jra...@ceridwen.us <mailto:jra...@ceridwen.us>>
> > >> To: Geert Janssens <geert.gnuc...@kobaltwit.be 
> > >> <mailto:geert.gnuc...@kobaltwit.be>>
> > >> Cc: gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>
> > >> Subject: Re: Rounding in the price db.
> > >> Message-ID: <4a7c3475-9787-4346-bfd7-f086dcd78...@ceridwen.us 
> > >> <mailto:4a7c3475-9787-4346-bfd7-f086dcd78...@ceridwen.us>>
> > >> Content-Type: text/plain; charset=utf-8
> > > 
> > > ...
> > > 
> > >> Rounding is now fixed and pushed.
> > >> 
> > >> There?s one change I?m holding back on: If I make it so that
> > > 
> > > Finance::Quote
> > > 
> > >> can?t overwrite a price added in the Price Editor (i.e. one of
> > >> source
> > >> user:price-editor) as David Carlson suggested last week, then the
> > >> ?fetch quote? button is broken because price-quotes.scm only knows
> > >> how to write the prices into the pricedb. This is a per-day
> > >> effect: A user-created> 
> > > quote
> > > 
> > >> from a different day won?t block the F::Q quote, so maybe it?s an
> > > 
> > > acceptable
> > > 
> > >> corner case that just needs to be mentioned in the docs and the
> > >> button?s tooltip. Ideally the button should disable in this
> > >> situation, but I?m not> 
> > > sure
> > > 
> > >> yet whether that?s feasible.
> > >> 
> > >> Comments?
> > >> 
> > >> I should add that I want to merge this ASAP so that it will be
> > >> available> 
> > > in the
> > > 
> > >> nightlies for testing before the next release, which is only two
> > >> weeks> 
> > > away.
> > > 
> > >> Regards,
> > >> John Ralls
> > >> 
> > >> 
> > >> --
> > >> 
> > >> Message: 2
> > >> Date: Sat, 12 Sep 2015 18:50:36 -0700 (PDT)
> > >> From: david.carlson@gmail.com <mailto:david.carlson@gmail.com>  
> > >> <david.carlson@gmail.com <mailto:david.carlson@gmail.com>>
> > >> To: jra...@ceridwen.us <mailto:jra...@ceridwen.us>, 
> > >> geert.gnuc...@kobaltwit.be <mailto:geert.gnuc...@kobaltwit.be>
> > >> Cc: gnucash-devel@gnucash.org <mailto:gnucash-devel@gnucash.org>
> > >> Subject: Re: Rounding in the price db.
> > >> Message-ID: <000f4259.651417a17ddc3...@gmail.com 
> > >> <mailto:000f4259.651417a17ddc3...@gmail.com>>
> > >> Content-Type: text/plain;charset="utf-8"
> > >> 
> > >>I could accept your proposal if it is documented. I think a user
> > >>could> 
> > > still go
> > > 
> > >> in later if he didn't like the online price for a certain date.
> > >> Sent from my LG G Pad 7.0 LTE, an AT 4G LTE tablet
> > >> --
> > > 
> > > Hi John,
> > > 
> > > Sorry for the late reply, needs must...
> > > 
> > > I haven't understood all your previous comments about this but
> > > thought I'd weigh in anyway.
> > > Can there only be 1 price record per stock/date?
> > > 
> > > I would have thought the primary key should be stock/date/source and
> > > that the advanced portfolio rpt should get actual cost details from
> > > the stock transactions and market price details from price records.
> > > If there are multiple price records of the same stock/date, then
> > > the advamced portfolio rpt should use say using source
> > > user:price-editor first, then a price from FQ, (then others...)
> > > 
> > > AFAIK, it is not critical that the market price be accurate as the
> > > costs/values on the stock transactions should be accurate.
> > > That's why I suggested prices from FQ should use the date returned
> > >

Re: Rounding in the price db.

[John Ralls]

> On Sep 9, 2015, at 6:20 PM, John Ralls  wrote:
> 
>> 
>> On Sep 5, 2015, at 8:44 AM, John Ralls  wrote:
>> 
>>> 
>>> On Sep 4, 2015, at 2:17 AM, Geert Janssens  
>>> wrote:
>>> 
>>> On Tuesday 01 September 2015 15:13:48 John Ralls wrote:
> Geert,
> 
> Thanks for testing. I agree that the check_foo() semantics are
> clumsy. I did it that way to avoid negating the return value in the
> if conditional, but in retrospect that would be clearer, so I’ll
> flip it.
> 
> Roger that the checks aren’t reliably bidirectional. I’ll dig into
> that. I hadn’t yet changed anything with regards to which direction
> prices are recorded, at least not on purpose, so I’ll have to track
> that down too.
> 
> I coded up the price-rounding algorithm on the flight back today and
> played with it a little. I think it may need some adjustment.
 I’ve pushed more changes to single-price which I think address Geert’s
 comments and some tweaks to maximize significant digit preservation
 while keeping denominators <= 10E6 in most cases. Please test some
 more!
 
 Regards,
 John Ralls
>>> 
>>> John,
>>> 
>>> I pulled your branch again yesterday and ran some tests on it this morning.
>>> 
>>> Here is what I did today:
>>> 
>>> - removed all prices from the price db.
>>> - created an invoice in EUR
>>> - added one entry to this invoice to an account denominated in USD
>>> - post the invoice => as expected this brings up the transfer dialog to get 
>>> an exchange rate.
>>> - as I removed all prices beforehand, there was no suggested price 
>>> (obviously), so I hit fetch quotes
>>> => When fetch quotes finished, I still didn't have an exchange rate entered 
>>> in the dialog.
>>> - so to continue I entered one myself
>>> - close transfer dialog and chech the price db via the price editor
>>> => There are two quotes in there now:
>>> Security EUR, Currency USD, type user:xfer-dialog
>>> Security USD, Currency EUR, type Finance::Quote (last)
>>> 
>>> The latter seems to have been fetched successfully by the transfer dialog 
>>> but was never proposed. The former is the price I had to manually enter to 
>>> continue.
>>> 
>>> The exact same thing happens if I now use process payment and for test pay 
>>> this (Euro denominated) invoice in HKD.
>>> Transfer dialog won't propose an exchange rate even after hitting the fetch 
>>> quotes button. Setting one manually will allow me to continue and 
>>> afterwards there will be two new quotes in the price editor
>>> Security EUR, Currency HKD, type user:xfer-dialog
>>> Security HKD, Currency EUR, type Finance::Quote (last)
>>> 
>>> Looks like the transfer dialog is not yet fully aware of bidirectional 
>>> quotes.
>> 
>> Not just the Transfer Dialog. Price-quotes.scm doesn’t read the output from 
>> gnc-fq-helper quite the way I thought it did. This weekend’s pretty busy but 
>> I should be able to fix it Monday along with finishing the source 
>> prioritization.
> 
> So I’ve got that fixed along with some other issues and the preference of 
> some sources and it’s pushed to my github branch. It’s doing too much 
> rounding somewhere so that our Sao Tomé Dobra test gets rounded to 
> uselessness in one direction, but I think the rest is working. Please test 
> while I wrestle some more with the rounding.

Rounding is now fixed and pushed.

There’s one change I’m holding back on: If I make it so that Finance::Quote 
can’t overwrite a price added in the Price Editor (i.e. one of source 
user:price-editor) as David Carlson suggested last week, then the “fetch quote” 
button is broken because price-quotes.scm only knows how to write the prices 
into the pricedb. This is a per-day effect: A user-created quote from a 
different day won’t block the F::Q quote, so maybe it’s an acceptable corner 
case that just needs to be mentioned in the docs and the button’s tooltip. 
Ideally the button should disable in this situation, but I’m not sure yet 
whether that’s feasible.

Comments?

I should add that I want to merge this ASAP so that it will be available in the 
nightlies for testing before the next release, which is only two weeks away.
Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[david . carlson . 417]

I could accept your proposal if it is documented. I think a user could 
still go in later if he didn't like the online price for a certain date.
Sent from my LG G Pad 7.0 LTE, an AT 4G LTE tablet




___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

> On Sep 5, 2015, at 8:44 AM, John Ralls  wrote:
> 
>> 
>> On Sep 4, 2015, at 2:17 AM, Geert Janssens  
>> wrote:
>> 
>> On Tuesday 01 September 2015 15:13:48 John Ralls wrote:
 Geert,
 
 Thanks for testing. I agree that the check_foo() semantics are
 clumsy. I did it that way to avoid negating the return value in the
 if conditional, but in retrospect that would be clearer, so I’ll
 flip it.
 
 Roger that the checks aren’t reliably bidirectional. I’ll dig into
 that. I hadn’t yet changed anything with regards to which direction
 prices are recorded, at least not on purpose, so I’ll have to track
 that down too.
 
 I coded up the price-rounding algorithm on the flight back today and
 played with it a little. I think it may need some adjustment.
>>> I’ve pushed more changes to single-price which I think address Geert’s
>>> comments and some tweaks to maximize significant digit preservation
>>> while keeping denominators <= 10E6 in most cases. Please test some
>>> more!
>>> 
>>> Regards,
>>> John Ralls
>> 
>> John,
>> 
>> I pulled your branch again yesterday and ran some tests on it this morning.
>> 
>> Here is what I did today:
>> 
>> - removed all prices from the price db.
>> - created an invoice in EUR
>> - added one entry to this invoice to an account denominated in USD
>> - post the invoice => as expected this brings up the transfer dialog to get 
>> an exchange rate.
>> - as I removed all prices beforehand, there was no suggested price 
>> (obviously), so I hit fetch quotes
>> => When fetch quotes finished, I still didn't have an exchange rate entered 
>> in the dialog.
>> - so to continue I entered one myself
>> - close transfer dialog and chech the price db via the price editor
>> => There are two quotes in there now:
>> Security EUR, Currency USD, type user:xfer-dialog
>> Security USD, Currency EUR, type Finance::Quote (last)
>> 
>> The latter seems to have been fetched successfully by the transfer dialog 
>> but was never proposed. The former is the price I had to manually enter to 
>> continue.
>> 
>> The exact same thing happens if I now use process payment and for test pay 
>> this (Euro denominated) invoice in HKD.
>> Transfer dialog won't propose an exchange rate even after hitting the fetch 
>> quotes button. Setting one manually will allow me to continue and afterwards 
>> there will be two new quotes in the price editor
>> Security EUR, Currency HKD, type user:xfer-dialog
>> Security HKD, Currency EUR, type Finance::Quote (last)
>> 
>> Looks like the transfer dialog is not yet fully aware of bidirectional 
>> quotes.
> 
> Not just the Transfer Dialog. Price-quotes.scm doesn’t read the output from 
> gnc-fq-helper quite the way I thought it did. This weekend’s pretty busy but 
> I should be able to fix it Monday along with finishing the source 
> prioritization.

So I’ve got that fixed along with some other issues and the preference of some 
sources and it’s pushed to my github branch. It’s doing too much rounding 
somewhere so that our Sao Tomé Dobra test gets rounded to uselessness in one 
direction, but I think the rest is working. Please test while I wrestle some 
more with the rounding.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

> On Sep 4, 2015, at 2:17 AM, Geert Janssens  wrote:
> 
> On Tuesday 01 September 2015 15:13:48 John Ralls wrote:
> > > Geert,
> > >
> > > Thanks for testing. I agree that the check_foo() semantics are
> > > clumsy. I did it that way to avoid negating the return value in the
> > > if conditional, but in retrospect that would be clearer, so I’ll
> > > flip it.
> > >
> > > Roger that the checks aren’t reliably bidirectional. I’ll dig into
> > > that. I hadn’t yet changed anything with regards to which direction
> > > prices are recorded, at least not on purpose, so I’ll have to track
> > > that down too.
> > >
> > > I coded up the price-rounding algorithm on the flight back today and
> > > played with it a little. I think it may need some adjustment.
> > I’ve pushed more changes to single-price which I think address Geert’s
> > comments and some tweaks to maximize significant digit preservation
> > while keeping denominators <= 10E6 in most cases. Please test some
> > more!
> >
> > Regards,
> > John Ralls
>  
> John,
>  
> I pulled your branch again yesterday and ran some tests on it this morning.
>  
> Here is what I did today:
>  
> - removed all prices from the price db.
> - created an invoice in EUR
> - added one entry to this invoice to an account denominated in USD
> - post the invoice => as expected this brings up the transfer dialog to get 
> an exchange rate.
> - as I removed all prices beforehand, there was no suggested price 
> (obviously), so I hit fetch quotes
> => When fetch quotes finished, I still didn't have an exchange rate entered 
> in the dialog.
> - so to continue I entered one myself
> - close transfer dialog and chech the price db via the price editor
> => There are two quotes in there now:
> Security EUR, Currency USD, type user:xfer-dialog
> Security USD, Currency EUR, type Finance::Quote (last)
>  
> The latter seems to have been fetched successfully by the transfer dialog but 
> was never proposed. The former is the price I had to manually enter to 
> continue.
>  
> The exact same thing happens if I now use process payment and for test pay 
> this (Euro denominated) invoice in HKD.
> Transfer dialog won't propose an exchange rate even after hitting the fetch 
> quotes button. Setting one manually will allow me to continue and afterwards 
> there will be two new quotes in the price editor
> Security EUR, Currency HKD, type user:xfer-dialog
> Security HKD, Currency EUR, type Finance::Quote (last)
>  
> Looks like the transfer dialog is not yet fully aware of bidirectional quotes.

Not just the Transfer Dialog. Price-quotes.scm doesn’t read the output from 
gnc-fq-helper quite the way I thought it did. This weekend’s pretty busy but I 
should be able to fix it Monday along with finishing the source prioritization.

Regards,
John Ralls

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Geert Janssens]

On Tuesday 01 September 2015 15:13:48 John Ralls wrote:
> > Geert,
> > 
> > Thanks for testing. I agree that the check_foo() semantics are
> > clumsy. I did it that way to avoid negating the return value in the
> > if conditional, but in retrospect that would be clearer, so I’ll
> > flip it.
> > 
> > Roger that the checks aren’t reliably bidirectional. I’ll dig into
> > that. I hadn’t yet changed anything with regards to which direction
> > prices are recorded, at least not on purpose, so I’ll have to track
> > that down too.
> > 
> > I coded up the price-rounding algorithm on the flight back today and
> > played with it a little. I think it may need some adjustment.
> I’ve pushed more changes to single-price which I think address Geert’s
> comments and some tweaks to maximize significant digit preservation
> while keeping denominators <= 10E6 in most cases. Please test some
> more!
> 
> Regards,
> John Ralls

John,

I pulled your branch again yesterday and ran some tests on it this morning.

Here is what I did today:

- removed all prices from the price db.
- created an invoice in EUR
- added one entry to this invoice to an account denominated in USD
- post the invoice => as expected this brings up the transfer dialog to get an 
exchange rate.
- as I removed all prices beforehand, there was no suggested price (obviously), 
so I hit fetch 
quotes
=> When fetch quotes finished, I still didn't have an exchange rate entered in 
the dialog.
- so to continue I entered one myself
- close transfer dialog and chech the price db via the price editor
=> There are two quotes in there now:
Security EUR, Currency USD, type user:xfer-dialog
Security USD, Currency EUR, type Finance::Quote (last)

The latter seems to have been fetched successfully by the transfer dialog but 
was never 
proposed. The former is the price I had to manually enter to continue.

The exact same thing happens if I now use process payment and for test pay this 
(Euro 
denominated) invoice in HKD.
Transfer dialog won't propose an exchange rate even after hitting the fetch 
quotes button. 
Setting one manually will allow me to continue and afterwards there will be two 
new quotes 
in the price editor
Security EUR, Currency HKD, type user:xfer-dialog
Security HKD, Currency EUR, type Finance::Quote (last)

Looks like the transfer dialog is not yet fully aware of bidirectional quotes.

Regards,

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

> On Sep 3, 2015, at 6:25 AM, david.carlson@gmail.com wrote:
> 
> I usually reply at the end of a message but this tablet is not set up that 
> way yet.
> Thank you John for that concise description.  This thread 
> Is too lengthy to browse and I am still trying to figure out why one Android 
> device puts the last message at the top of the list and another device puts 
> the last message at the bottom or sorts randomly? ?? I am definitely not 
> rrady to give up my tower next to my desk.  Tablets are impossible to edit 
> on, too.
> 
> I like the idea of deferring the transfer dialog to the end of the edit 
> session but that would not completely solve the problem of changing a 
> transaction from a sale of ABC stock to FOO stock because it is still 
> necessary t o save before going to the target security account register to 
> adjust the number of shares or something to get whole thing right

You can do that in the transfer dialog: Instead of entering the price in 
“Exchange Rate” click the “To Amount” radio button (or just arrow down to it) 
and enter the actual amount you want. The dialog will calculate the 
corresponding price for you.

> Maybe I could learn to start by adding an empty split line to make the 
> ttarget security account available as a place to do the edit., but there is 
> still either an intermediate save or split lines containing different lots 
> and securities (maybe even different brokerage accounts) to contend with.  
> Now that I am thinking about it, maybe I should try doing that in a ledger 
> view.  I have not tried that.  Business transactions probably add more cans 
> of worms to this work flow concept.

If you’re talking about changing your procedure then just make sure you change 
the counter-account before editing the credit/debit column so that the Transfer 
Dialog has the right information at the outset.

Do you really have multiple securities in a single transaction that often? I 
only do that when there’s a merger or a spin-off. That requirement (which is 
anyway reasonable) means that we’d have to keep a list of the commodities and 
run the transfer dialog once for each of them. The invoice creation code 
already does that.

Ledger view might make the operation easier if you’re changing both the cash 
and security accounts.

> 
> If there was a way to paste an entire transaction into an account, then a 
> different method of editing might work.  I think that would be way beyond the 
> scope of this work.

Ledger view might help with this, too.

Regards,
John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[David Carlson]

I should split this off from the price rounding thread, but I don't know
how to do that in GMail when I am replying from inside the thread.

Ledger view doesn't show number of shares or prices, so I would still need
to go the security account to check on/fix them.  I do not see how to fill
out the transfer Funds Dialog from a confirmation statement listing number
of shares, price, commission and amount.  There are no boxes for number of
shares or amount.  I am also not sure which split line the dialog is
working on after it has popped up.  All closing transactions should have a
pair of adjustment (Realized Gain/Loss) lines as well as the basic
purchase/sale.and currency transfer lines.

It seems like it is still easiest to let the GnuCash Transfer Funds dialog
do whatever it wants then go to the security account where the number of
shares is shown and correct it, because it probably is wrong.

The multiple securities or accounts in the same transaction would usually
be transitory during the editing process, but the cases you mention would
be permanent.  I can also attest that when I had a 401-K with many
securities in 5 different sub-accounts it was very common to have as many
as 30 ledger entries in a single bi-weekly transaction and I was too lazy
to duplicate each one separately.

David C

On Thu, Sep 3, 2015 at 10:06 AM, John Ralls  wrote:

>
> > On Sep 3, 2015, at 6:25 AM, david.carlson@gmail.com wrote:
> >
> > I usually reply at the end of a message but this tablet is not set up
> that way yet.
> > Thank you John for that concise description.  This thread
> > Is too lengthy to browse and I am still trying to figure out why one
> Android device puts the last message at the top of the list and another
> device puts the last message at the bottom or sorts randomly? ?? I am
> definitely not rrady to give up my tower next to my desk.  Tablets are
> impossible to edit on, too.
> >
> > I like the idea of deferring the transfer dialog to the end of the edit
> session but that would not completely solve the problem of changing a
> transaction from a sale of ABC stock to FOO stock because it is still
> necessary t o save before going to the target security account register to
> adjust the number of shares or something to get whole thing right
>
> You can do that in the transfer dialog: Instead of entering the price in
> “Exchange Rate” click the “To Amount” radio button (or just arrow down to
> it) and enter the actual amount you want. The dialog will calculate the
> corresponding price for you.
>
> > Maybe I could learn to start by adding an empty split line to make the
> ttarget security account available as a place to do the edit., but there is
> still either an intermediate save or split lines containing different lots
> and securities (maybe even different brokerage accounts) to contend with.
> > Now that I am thinking about it, maybe I should try doing that in a
> ledger view.  I have not tried that.  Business transactions probably add
> more cans of worms to this work flow concept.
>
> If you’re talking about changing your procedure then just make sure you
> change the counter-account before editing the credit/debit column so that
> the Transfer Dialog has the right information at the outset.
>
> Do you really have multiple securities in a single transaction that often?
> I only do that when there’s a merger or a spin-off. That requirement (which
> is anyway reasonable) means that we’d have to keep a list of the
> commodities and run the transfer dialog once for each of them. The invoice
> creation code already does that.
>
> Ledger view might make the operation easier if you’re changing both the
> cash and security accounts.
>
> >
> > If there was a way to paste an entire transaction into an account, then
> a different method of editing might work.  I think that would be way beyond
> the scope of this work.
>
> Ledger view might help with this, too.
>
> Regards,
> John Ralls
>
>
>
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Aaron Laws]

On Thu, Sep 3, 2015 at 2:03 PM, David Carlson 
wrote:

> I should split this off from the price rounding thread, but I don't know
> how to do that in GMail when I am replying from inside the thread.
>
>
It's a rather hard-to-find feature. To the left of the "to" field, there is
a little icon with a triangle arrow down. Click that, then "Edit Subject",
and it pops the message out and lets you edit the subject.

Aaron
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[david . carlson . 417]

I usually reply at the end of a message but this tablet is not set up that 
way yet.Thank you John for that concise description.  This thread Is too 
lengthy to browse and I am still trying to figure out why one Android device 
puts the last message at the top of the list and another device puts the last 
message at the bottom or sorts randomly? ?? I am definitely not rrady to give 
up my tower next to my desk.  Tablets are impossible to edit on, too.
I like the idea of deferring the transfer dialog to the end of the edit session 
but that would not completely solve the problem of changing a transaction from 
a sale of ABC stock to FOO stock because it is still necessary to save before 
going to the target security account register to adjust the number of shares or 
something to get whole thing right.Maybe I could learn to start by adding an 
empty split line to make the ttarget security account available as a place to 
do the edit., but there is still either an intermediate save or split lines 
containing different lots and securities (maybe even different brokerage 
accounts) to contend with.  Now that I am thinking about it, maybe I should try 
doing that in a ledger view.  I have not tried that.  Business transactions 
probably add more cans of worms to this work flow concept.
If there was a way to paste an entire transaction into an account, then a 
different method of editing might work.  I think that would be way beyond the 
scope of this work.
I am looking forward to seeing the result of all your hard work.
David C

Sent from my LG G Pad 7.0 LTE, an AT 4G LTE tablet



-- Original message--From: John RallsDate: Wed, Sep 2, 2015 7:56 PMTo: 
David Carlson;Cc: gnucash-devel@gnucash.org;Subject:Re: Rounding in the price 
db.
> On Sep 2, 2015, at 1:18 PM, David Carlson  wrote:> > On 9/1/2015 10:01 PM, 
> John Ralls wrote:>>> SNIP...>> David,>> >> Quotes from F::Q are supposed to 
> overwrite user entries for the day, but although F::Q is quite capable of 
> retrieving historical quotes, GnuCash doesn’t use that facility. So if you 
> create a transaction with a date_posted in the past and there isn’t already 
> an F::Q quote for that day then the price generated from that transaction 
> won’t get overwritten later on. On the other hand, if you do have an F::Q 
> quote already on that day then the user price won’t get written to the price 
> db.>> >> Umm, are you able to build from git? This code is currently on a 
> feature branch so it isn’t going to get into the nightlies for you to test 
> with otherwise. I think I understand the first test-case well enough to run 
> tests myself, but I need more detail on the second (the duplicate-and-modify) 
> one to test it.>> >> Regards,>> John Ralls> > John,> I am not ready to try 
> git, but if it does get to nightly or weekly> windows builds, I could try 
> that.> > That second case comes from a habit I developed years ago that once 
> I> have a transaction with a structure that I like but it is in the 'wrong'> 
> account for my current needs, I will clone it there then change the date> and 
> accounts one by one until it is 'correct.'  Sometimes I will stop> and create 
> a new account if I did not create all the accounts ahead of> time.  Since I 
> don't have a fixed routine to do this, I may change any> transaction field in 
> any order, then I often need to save before> finishing to switch to a 
> different account register to complete the> transaction.  This is most likely 
> to happen when I sell a security that> I have not sold from that brokerage 
> account in the past, but that is not> the only time it happens. > > Prior to 
> the 2.6 .x releases, that did not cause any issues in the price> data, but 
> now there are cases where GnuCash wants to set a price (or> quantity?) for a 
> 'wrong' security before I am ready, and it may also add> entries to the price 
> database.  If GnuCash discards transaction derived> prices when there are 
> 'better' prices already present, that is fine with> me.  Otherwise I would 
> request that GnuCash ask if I want to record the> price in the database 
> before that happens.  I think that there is a> difference between 'User" 
> prices entered directly into the database> compared to prices derived 
> indirectly from transactions.  If the derived> price(s) disappear if (all of 
> the) the source transactions for that date> disappear or change, that would 
> be ok too.> > Actually, when directly editing the price database, the user 
> can select> whether the price is characterized as High, Low, Last, NAV, etc.  
> Only> Last or NAV type 'User' prices would need to be 'stickier' than F:Q> 
> prices or indirectly derived prices, in my opinion.David,Git’s the easy part. 
> *Building* is the hard part, especially on Windows. I’m not quite ready to 
> merge but I will soon so that you can test it before the release.Your use 
> case is an interesting one. It actually points up a weakness in the Transfer 
> 

Re: Rounding in the price db.

[John Ralls]

> On Sep 2, 2015, at 1:18 PM, David Carlson  wrote:
> 
> On 9/1/2015 10:01 PM, John Ralls wrote:
>>> SNIP...
>> David,
>> 
>> Quotes from F::Q are supposed to overwrite user entries for the day, but 
>> although F::Q is quite capable of retrieving historical quotes, GnuCash 
>> doesn’t use that facility. So if you create a transaction with a date_posted 
>> in the past and there isn’t already an F::Q quote for that day then the 
>> price generated from that transaction won’t get overwritten later on. On the 
>> other hand, if you do have an F::Q quote already on that day then the user 
>> price won’t get written to the price db.
>> 
>> Umm, are you able to build from git? This code is currently on a feature 
>> branch so it isn’t going to get into the nightlies for you to test with 
>> otherwise. I think I understand the first test-case well enough to run tests 
>> myself, but I need more detail on the second (the duplicate-and-modify) one 
>> to test it.
>> 
>> Regards,
>> John Ralls
> 
> John,
> I am not ready to try git, but if it does get to nightly or weekly
> windows builds, I could try that.
> 
> That second case comes from a habit I developed years ago that once I
> have a transaction with a structure that I like but it is in the 'wrong'
> account for my current needs, I will clone it there then change the date
> and accounts one by one until it is 'correct.'  Sometimes I will stop
> and create a new account if I did not create all the accounts ahead of
> time.  Since I don't have a fixed routine to do this, I may change any
> transaction field in any order, then I often need to save before
> finishing to switch to a different account register to complete the
> transaction.  This is most likely to happen when I sell a security that
> I have not sold from that brokerage account in the past, but that is not
> the only time it happens. 
> 
> Prior to the 2.6 .x releases, that did not cause any issues in the price
> data, but now there are cases where GnuCash wants to set a price (or
> quantity?) for a 'wrong' security before I am ready, and it may also add
> entries to the price database.  If GnuCash discards transaction derived
> prices when there are 'better' prices already present, that is fine with
> me.  Otherwise I would request that GnuCash ask if I want to record the
> price in the database before that happens.  I think that there is a
> difference between 'User" prices entered directly into the database
> compared to prices derived indirectly from transactions.  If the derived
> price(s) disappear if (all of the) the source transactions for that date
> disappear or change, that would be ok too.
> 
> Actually, when directly editing the price database, the user can select
> whether the price is characterized as High, Low, Last, NAV, etc.  Only
> Last or NAV type 'User' prices would need to be 'stickier' than F:Q
> prices or indirectly derived prices, in my opinion.

David,

Git’s the easy part. *Building* is the hard part, especially on Windows. I’m 
not quite ready to merge but I will soon so that you can test it before the 
release.

Your use case is an interesting one. It actually points up a weakness in the 
Transfer Dialog, which assumes that the “other” account has been set in the 
transaction. We might want to defer running the dialog until the transaction 
edit is completed instead of when exiting the Credit or Debit cell.

Prices have a source and a type field. The source can be “Finance::Quote”, 
“user:invoice-post”, “user:stock-split”, “user:xfer-dialog”, 
“user:split-register”, or “user:price-editor”. The current code treats all of 
the “user:foo” sources the same and prefers F::Q to any of them. Early in this 
thread we discussed making two flavors of user:xfer-dialog so that cases where 
the users entered the price directly could be differentiated from those where 
she entered the amount of the “other” currency and the former preferred over 
the latter. I haven’t implemented that yet, and your point about 
user:price-editor being preferred over all others is a good one.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[David Carlson]

On 9/1/2015 10:01 PM, John Ralls wrote:
>> SNIP...
> David,
>
> Quotes from F::Q are supposed to overwrite user entries for the day, but 
> although F::Q is quite capable of retrieving historical quotes, GnuCash 
> doesn’t use that facility. So if you create a transaction with a date_posted 
> in the past and there isn’t already an F::Q quote for that day then the price 
> generated from that transaction won’t get overwritten later on. On the other 
> hand, if you do have an F::Q quote already on that day then the user price 
> won’t get written to the price db.
>
> Umm, are you able to build from git? This code is currently on a feature 
> branch so it isn’t going to get into the nightlies for you to test with 
> otherwise. I think I understand the first test-case well enough to run tests 
> myself, but I need more detail on the second (the duplicate-and-modify) one 
> to test it.
>
> Regards,
> John Ralls

John,
I am not ready to try git, but if it does get to nightly or weekly
windows builds, I could try that.

That second case comes from a habit I developed years ago that once I
have a transaction with a structure that I like but it is in the 'wrong'
account for my current needs, I will clone it there then change the date
and accounts one by one until it is 'correct.'  Sometimes I will stop
and create a new account if I did not create all the accounts ahead of
time.  Since I don't have a fixed routine to do this, I may change any
transaction field in any order, then I often need to save before
finishing to switch to a different account register to complete the
transaction.  This is most likely to happen when I sell a security that
I have not sold from that brokerage account in the past, but that is not
the only time it happens. 

Prior to the 2.6 .x releases, that did not cause any issues in the price
data, but now there are cases where GnuCash wants to set a price (or
quantity?) for a 'wrong' security before I am ready, and it may also add
entries to the price database.  If GnuCash discards transaction derived
prices when there are 'better' prices already present, that is fine with
me.  Otherwise I would request that GnuCash ask if I want to record the
price in the database before that happens.  I think that there is a
difference between 'User" prices entered directly into the database
compared to prices derived indirectly from transactions.  If the derived
price(s) disappear if (all of the) the source transactions for that date
disappear or change, that would be ok too.

Actually, when directly editing the price database, the user can select
whether the price is characterized as High, Low, Last, NAV, etc.  Only
Last or NAV type 'User' prices would need to be 'stickier' than F:Q
prices or indirectly derived prices, in my opinion.

David C
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[David Carlson]

On 9/1/2015 5:13 PM, John Ralls wrote:
>> On Aug 28, 2015, at 8:17 PM, John Ralls  wrote:
>>
>>
>>> On Aug 28, 2015, at 6:43 AM, Geert Janssens  
>>> wrote:
>>>
>>> On Friday 28 August 2015 08:55:53 John Ralls wrote:
 I’ve pushed a feature branch, single-price, to my Github repo
 (https://github.com/jralls/gnucash ) 
 which covers most of what we’ve
 discussed here. I’m still wrestling with the math of how to sensibly
 handle rounding itself, so what’s there still uses the hard-coded
 10^6 denom. The branch is from maint because I’d like to put these
 changes in 2.6.8.

 The actual changes are explained in the commit notes. In my limited
 testing it appears to work and to provide stability when doing
 multiple transactions with the same exchange rate. Please test some
 more; I’m sure I didn’t think of every possible variation.

>>> Hi John,
>>>
>>> Thanks for your work on this.
>>>
>>> From my first tests and reading the code I have the following observations:
>>>
>>> - Let me start with a nit-pick: while reading through the commits I got 
>>> confused by the return values of check_account and check_edit. They return 
>>> TRUE if the check fails (that is when anything is not ok to continue with a 
>>> transfer). From a distance that seems backwards. I usually expect a check 
>>> function to return TRUE if all checks pass correctly.
>>>
>>> - Next I created a vendor bill, posted it and then paid it in a foreign 
>>> currency. This also pops up the transfer dialog. I entered a price and 
>>> continued. This added the price to the db (as expected). Next I remove the 
>>> payment transaction (from the bank account in the foreign currency) and 
>>> issue a new payment via the payment dialog, again in the same foreign 
>>> currency. This time however, I enter a to amount directly (ensuring it 
>>> would result in a completely different price). Check the price db and note 
>>> the existing price hasn't changed.
>>>
>>> - The currencies I was playing with are € (from currency) and HKD (to 
>>> currency). Before your changes my price db listed a HKD security EUR 
>>> currency. On your branch the code now adds a EUR security in HKD currency. 
>>> That change is fine in itself. I prefer your normalized way to store 
>>> (currency) exchange rates in the db. The issue with this however is that 
>>> F::Q won't return an exchange rate for the new price, while it did (and 
>>> still does) for the old one.
>>>
 As for the math, here’s the conundrum: I proposed earlier to base the
 rounding on what would make a 1 scu change in the “to” commodity. The
 problems with that idea are that it depends entirely on the amount in
 the “from” commodity and that prices are often quoted in fractions of
 a scu. For example, the Wall Street Journal website quotes the Yen at
 120.98 to the USD. The Yen’s scu is 1, and the change in the rate to
 make a 1¥ change in the value is different if the USD amount is $10
 from what it would be if the amount was $1000. Carry that to its
 illogical conclusion and we need infinite precision, and that’s
 ignoring the fact that we need infinite precision to exactly
 represent a lot of rational fractions, but since all the real money
 systems use decimal math nowadays that’s not really germane.

 So I have a new proposal: If the commodities are both currencies,
 store exchange rates in the direction where the rate > 1, set the
 denominator to 1000, and round-half-up. The price retrieval code
 already checks in both directions. If only one of the commodities is
 a currency then it’s a price and we store it in the currency with the
 denominator = the currency’s scu * 1.

>>> See above: the check in both directions is not reliable/borked.
>>>
 That leaves commodity-commodity prices. The most common example in
 modern life is stock-for-stock exchanges resulting from mergers or
 spin-offs. These tend to be one-offs, so no rounding required. Barter
 exchange, where one exchanges one commodity for another (e.g. two
 bushels of corn for a cow), is similarly fractional rather than
 decimal, so again not rounding is appropriate. The third case is the
 problem: Bitcoin and similar pseudo-currencies. For maint I think
 we’re going to have to leave those prices unrounded as well, but
 perhaps for master we should consider creating a separate commodity
 category so that users can create commodities that GnuCash treats as
 currencies.

>>> That looks like a very sensible proposal to me.
>> Geert,
>>
>> Thanks for testing. I agree that the check_foo() semantics are clumsy. I did 
>> it that way to avoid negating the return value in the if conditional, but in 
>> retrospect that would be clearer, so I’ll flip it.
>>
>> Roger that the checks aren’t reliably 

Re: Rounding in the price db.

[John Ralls]

> On Aug 28, 2015, at 8:17 PM, John Ralls  wrote:
> 
> 
>> On Aug 28, 2015, at 6:43 AM, Geert Janssens  
>> wrote:
>> 
>> On Friday 28 August 2015 08:55:53 John Ralls wrote:
>>> I’ve pushed a feature branch, single-price, to my Github repo
>>> (https://github.com/jralls/gnucash ) 
>>> which covers most of what we’ve
>>> discussed here. I’m still wrestling with the math of how to sensibly
>>> handle rounding itself, so what’s there still uses the hard-coded
>>> 10^6 denom. The branch is from maint because I’d like to put these
>>> changes in 2.6.8.
>>> 
>>> The actual changes are explained in the commit notes. In my limited
>>> testing it appears to work and to provide stability when doing
>>> multiple transactions with the same exchange rate. Please test some
>>> more; I’m sure I didn’t think of every possible variation.
>>> 
>> Hi John,
>> 
>> Thanks for your work on this.
>> 
>> From my first tests and reading the code I have the following observations:
>> 
>> - Let me start with a nit-pick: while reading through the commits I got 
>> confused by the return values of check_account and check_edit. They return 
>> TRUE if the check fails (that is when anything is not ok to continue with a 
>> transfer). From a distance that seems backwards. I usually expect a check 
>> function to return TRUE if all checks pass correctly.
>> 
>> - Next I created a vendor bill, posted it and then paid it in a foreign 
>> currency. This also pops up the transfer dialog. I entered a price and 
>> continued. This added the price to the db (as expected). Next I remove the 
>> payment transaction (from the bank account in the foreign currency) and 
>> issue a new payment via the payment dialog, again in the same foreign 
>> currency. This time however, I enter a to amount directly (ensuring it would 
>> result in a completely different price). Check the price db and note the 
>> existing price hasn't changed.
>> 
>> - The currencies I was playing with are € (from currency) and HKD (to 
>> currency). Before your changes my price db listed a HKD security EUR 
>> currency. On your branch the code now adds a EUR security in HKD currency. 
>> That change is fine in itself. I prefer your normalized way to store 
>> (currency) exchange rates in the db. The issue with this however is that 
>> F::Q won't return an exchange rate for the new price, while it did (and 
>> still does) for the old one.
>> 
>>> As for the math, here’s the conundrum: I proposed earlier to base the
>>> rounding on what would make a 1 scu change in the “to” commodity. The
>>> problems with that idea are that it depends entirely on the amount in
>>> the “from” commodity and that prices are often quoted in fractions of
>>> a scu. For example, the Wall Street Journal website quotes the Yen at
>>> 120.98 to the USD. The Yen’s scu is 1, and the change in the rate to
>>> make a 1¥ change in the value is different if the USD amount is $10
>>> from what it would be if the amount was $1000. Carry that to its
>>> illogical conclusion and we need infinite precision, and that’s
>>> ignoring the fact that we need infinite precision to exactly
>>> represent a lot of rational fractions, but since all the real money
>>> systems use decimal math nowadays that’s not really germane.
>>> 
>>> So I have a new proposal: If the commodities are both currencies,
>>> store exchange rates in the direction where the rate > 1, set the
>>> denominator to 1000, and round-half-up. The price retrieval code
>>> already checks in both directions. If only one of the commodities is
>>> a currency then it’s a price and we store it in the currency with the
>>> denominator = the currency’s scu * 1.
>>> 
>> See above: the check in both directions is not reliable/borked.
>> 
>>> That leaves commodity-commodity prices. The most common example in
>>> modern life is stock-for-stock exchanges resulting from mergers or
>>> spin-offs. These tend to be one-offs, so no rounding required. Barter
>>> exchange, where one exchanges one commodity for another (e.g. two
>>> bushels of corn for a cow), is similarly fractional rather than
>>> decimal, so again not rounding is appropriate. The third case is the
>>> problem: Bitcoin and similar pseudo-currencies. For maint I think
>>> we’re going to have to leave those prices unrounded as well, but
>>> perhaps for master we should consider creating a separate commodity
>>> category so that users can create commodities that GnuCash treats as
>>> currencies.
>>> 
>> That looks like a very sensible proposal to me.
> 
> Geert,
> 
> Thanks for testing. I agree that the check_foo() semantics are clumsy. I did 
> it that way to avoid negating the return value in the if conditional, but in 
> retrospect that would be clearer, so I’ll flip it.
> 
> Roger that the checks aren’t reliably bidirectional. I’ll dig into that. I 
> hadn’t yet changed anything with regards to which direction prices are 

Re: Rounding in the price db.

[John Ralls]

I’ve pushed a feature branch, single-price, to my Github repo 
(https://github.com/jralls/gnucash) which covers most of what we’ve discussed 
here. I’m still wrestling with the math of how to sensibly handle rounding 
itself, so what’s there still uses the hard-coded 10^6 denom. The branch is 
from maint because I’d like to put these changes in 2.6.8.

The actual changes are explained in the commit notes. In my limited testing it 
appears to work and to provide stability when doing multiple transactions with 
the same exchange rate. Please test some more; I’m sure I didn’t think of every 
possible variation.

As for the math, here’s the conundrum: I proposed earlier to base the rounding 
on what would make a 1 scu change in the “to” commodity. The problems with that 
idea are that it depends entirely on the amount in the “from” commodity and 
that prices are often quoted in fractions of a scu. For example, the Wall 
Street Journal website quotes the Yen at 120.98 to the USD. The Yen’s scu is 1, 
and the change in the rate to make a 1¥ change in the value is different if the 
USD amount is $10 from what it would be if the amount was $1000. Carry that to 
its illogical conclusion and we need infinite precision, and that’s ignoring 
the fact that we need infinite precision to exactly represent a lot of rational 
fractions, but since all the real money systems use decimal math nowadays 
that’s not really germane.

So I have a new proposal: If the commodities are both currencies, store 
exchange rates in the direction where the rate  1, set the denominator to 
1000, and round-half-up. The price retrieval code already checks in both 
directions. If only one of the commodities is a currency then it’s a price and 
we store it in the currency with the denominator = the currency’s scu * 1.

That leaves commodity-commodity prices. The most common example in modern life 
is stock-for-stock exchanges resulting from mergers or spin-offs. These tend to 
be one-offs, so no rounding required. Barter exchange, where one exchanges one 
commodity for another (e.g. two bushels of corn for a cow), is similarly 
fractional rather than decimal, so again not rounding is appropriate. The third 
case is the problem: Bitcoin and similar pseudo-currencies. For maint I think 
we’re going to have to leave those prices unrounded as well, but perhaps for 
master we should consider creating a separate commodity category so that users 
can create commodities that GnuCash treats as currencies.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Geert Janssens]

On Friday 28 August 2015 08:55:53 John Ralls wrote:
 I’ve pushed a feature branch, single-price, to my Github repo
 (https://github.com/jralls/gnucash) which covers most of what we’ve
 discussed here. I’m still wrestling with the math of how to sensibly
 handle rounding itself, so what’s there still uses the hard-coded
 10^6 denom. The branch is from maint because I’d like to put these
 changes in 2.6.8.
 
 The actual changes are explained in the commit notes. In my limited
 testing it appears to work and to provide stability when doing
 multiple transactions with the same exchange rate. Please test some
 more; I’m sure I didn’t think of every possible variation.
 
Hi John,

Thanks for your work on this.

From my first tests and reading the code I have the following observations:

- Let me start with a nit-pick: while reading through the commits I got 
confused by the return 
values of check_account and check_edit. They return TRUE if the check fails 
(that is when 
anything is not ok to continue with a transfer). From a distance that seems 
backwards. I usually 
expect a check function to return TRUE if all checks pass correctly.

- Next I created a vendor bill, posted it and then paid it in a foreign 
currency. This also pops up 
the transfer dialog. I entered a price and continued. This added the price to 
the db (as 
expected). Next I remove the payment transaction (from the bank account in the 
foreign 
currency) and issue a new payment via the payment dialog, again in the same 
foreign currency. 
This time however, I enter a to amount directly (ensuring it would result in a 
completely 
different price). Check the price db and note the existing price hasn't changed.

- The currencies I was playing with are € (from currency) and HKD (to 
currency). Before your 
changes my price db listed a HKD security EUR currency. On your branch the code 
now adds a 
EUR security in HKD currency. That change is fine in itself. I prefer your 
normalized way to store 
(currency) exchange rates in the db. The issue with this however is that F::Q 
won't return an 
exchange rate for the new price, while it did (and still does) for the old one.

 As for the math, here’s the conundrum: I proposed earlier to base the
 rounding on what would make a 1 scu change in the “to” commodity. The
 problems with that idea are that it depends entirely on the amount in
 the “from” commodity and that prices are often quoted in fractions of
 a scu. For example, the Wall Street Journal website quotes the Yen at
 120.98 to the USD. The Yen’s scu is 1, and the change in the rate to
 make a 1¥ change in the value is different if the USD amount is $10
 from what it would be if the amount was $1000. Carry that to its
 illogical conclusion and we need infinite precision, and that’s
 ignoring the fact that we need infinite precision to exactly
 represent a lot of rational fractions, but since all the real money
 systems use decimal math nowadays that’s not really germane.
 
 So I have a new proposal: If the commodities are both currencies,
 store exchange rates in the direction where the rate  1, set the
 denominator to 1000, and round-half-up. The price retrieval code
 already checks in both directions. If only one of the commodities is
 a currency then it’s a price and we store it in the currency with the
 denominator = the currency’s scu * 1.
 
See above: the check in both directions is not reliable/borked.

 That leaves commodity-commodity prices. The most common example in
 modern life is stock-for-stock exchanges resulting from mergers or
 spin-offs. These tend to be one-offs, so no rounding required. Barter
 exchange, where one exchanges one commodity for another (e.g. two
 bushels of corn for a cow), is similarly fractional rather than
 decimal, so again not rounding is appropriate. The third case is the
 problem: Bitcoin and similar pseudo-currencies. For maint I think
 we’re going to have to leave those prices unrounded as well, but
 perhaps for master we should consider creating a separate commodity
 category so that users can create commodities that GnuCash treats as
 currencies.
 
That looks like a very sensible proposal to me.

Regards,
Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

 On Aug 28, 2015, at 6:43 AM, Geert Janssens geert.gnuc...@kobaltwit.be 
 wrote:
 
 On Friday 28 August 2015 08:55:53 John Ralls wrote:
  I’ve pushed a feature branch, single-price, to my Github repo
  (https://github.com/jralls/gnucash https://github.com/jralls/gnucash) 
  which covers most of what we’ve
  discussed here. I’m still wrestling with the math of how to sensibly
  handle rounding itself, so what’s there still uses the hard-coded
  10^6 denom. The branch is from maint because I’d like to put these
  changes in 2.6.8.
  
  The actual changes are explained in the commit notes. In my limited
  testing it appears to work and to provide stability when doing
  multiple transactions with the same exchange rate. Please test some
  more; I’m sure I didn’t think of every possible variation.
  
 Hi John,
  
 Thanks for your work on this.
  
 From my first tests and reading the code I have the following observations:
  
 - Let me start with a nit-pick: while reading through the commits I got 
 confused by the return values of check_account and check_edit. They return 
 TRUE if the check fails (that is when anything is not ok to continue with a 
 transfer). From a distance that seems backwards. I usually expect a check 
 function to return TRUE if all checks pass correctly.
  
 - Next I created a vendor bill, posted it and then paid it in a foreign 
 currency. This also pops up the transfer dialog. I entered a price and 
 continued. This added the price to the db (as expected). Next I remove the 
 payment transaction (from the bank account in the foreign currency) and issue 
 a new payment via the payment dialog, again in the same foreign currency. 
 This time however, I enter a to amount directly (ensuring it would result in 
 a completely different price). Check the price db and note the existing price 
 hasn't changed.
  
 - The currencies I was playing with are € (from currency) and HKD (to 
 currency). Before your changes my price db listed a HKD security EUR 
 currency. On your branch the code now adds a EUR security in HKD currency. 
 That change is fine in itself. I prefer your normalized way to store 
 (currency) exchange rates in the db. The issue with this however is that F::Q 
 won't return an exchange rate for the new price, while it did (and still 
 does) for the old one.
  
  As for the math, here’s the conundrum: I proposed earlier to base the
  rounding on what would make a 1 scu change in the “to” commodity. The
  problems with that idea are that it depends entirely on the amount in
  the “from” commodity and that prices are often quoted in fractions of
  a scu. For example, the Wall Street Journal website quotes the Yen at
  120.98 to the USD. The Yen’s scu is 1, and the change in the rate to
  make a 1¥ change in the value is different if the USD amount is $10
  from what it would be if the amount was $1000. Carry that to its
  illogical conclusion and we need infinite precision, and that’s
  ignoring the fact that we need infinite precision to exactly
  represent a lot of rational fractions, but since all the real money
  systems use decimal math nowadays that’s not really germane.
  
  So I have a new proposal: If the commodities are both currencies,
  store exchange rates in the direction where the rate  1, set the
  denominator to 1000, and round-half-up. The price retrieval code
  already checks in both directions. If only one of the commodities is
  a currency then it’s a price and we store it in the currency with the
  denominator = the currency’s scu * 1.
  
 See above: the check in both directions is not reliable/borked.
  
  That leaves commodity-commodity prices. The most common example in
  modern life is stock-for-stock exchanges resulting from mergers or
  spin-offs. These tend to be one-offs, so no rounding required. Barter
  exchange, where one exchanges one commodity for another (e.g. two
  bushels of corn for a cow), is similarly fractional rather than
  decimal, so again not rounding is appropriate. The third case is the
  problem: Bitcoin and similar pseudo-currencies. For maint I think
  we’re going to have to leave those prices unrounded as well, but
  perhaps for master we should consider creating a separate commodity
  category so that users can create commodities that GnuCash treats as
  currencies.
  
 That looks like a very sensible proposal to me.

Geert,

Thanks for testing. I agree that the check_foo() semantics are clumsy. I did it 
that way to avoid negating the return value in the if conditional, but in 
retrospect that would be clearer, so I’ll flip it.

Roger that the checks aren’t reliably bidirectional. I’ll dig into that. I 
hadn’t yet changed anything with regards to which direction prices are 
recorded, at least not on purpose, so I’ll have to track that down too.

I coded up the price-rounding algorithm on the flight back today and played 
with it a little. I think it may need some adjustment.

Regards,
John Ralls

Re: Rounding in the price db.

[David Carlson]

 I have been watching this thread and am glad that this discussion is
happening.

The price db  is also used in the reconciliation dialog when reconciling an
account with subaccounts. The reconciliation dialog appears to use the most
recent value, where I would expect it to use nearest in time to the
reconciliation date.

Would there any value to keeping one price from each source as opposed to
only one value?  Also, is it possible to have securities valued in more
than one currency?

On Mon, Aug 17, 2015 at 5:06 PM, John Ralls jra...@ceridwen.us wrote:


  On Aug 17, 2015, at 8:07 PM, Mike Alexander m...@umich.edu wrote:
 
  On Aug 17, 2015, at 5:36 AM, John Ralls jra...@ceridwen.us wrote:
 
 
  On Aug 12, 2015, at 2:13 PM, John Ralls jra...@ceridwen.us wrote:
  It might help to consider what the price db is used for: Aside from
 providing a default rate in the transfer dialog, it’s used for pricing
 assets in the Accounts page and the summary bar — only the latest entry is
 used there. It’s used for calculating values in reports, where the reports
 can use a weighted average, nearest in time, most recent, or average cost.
 I need to look to see if the average cost actually looks at the buy
 transactions or if it does something similar to nearest in time and at
 weighted average to see what it’s averaging and how it’s weighting the
 averaged values. Depending on what those two are doing might drive whether
 multiple F::Q entries per day make sense, assuming that the algorithms make
 sense.
 
  OK, I’ve looked. They don’t use the price db, which is what one would
 expect. Weighted-average is weighted by the transaction size, which will be
 distorted by stock splits but is otherwise OK.
 
  The Advanced Portfolio report uses the Price DB to get the current value
 of a holding.  There is an option to use a transaction price instead, but
 the default is to use the Price DB.  The only Price DB options it supports
 are latest and nearest in time.  If you ask it to use a transaction
 price (or if it can't find a price in the Price DB) it uses the most recent
 transaction which defines a price that can be converted to the report's
 currency.
 
  I can't speak for other reports.  I'm out of town and don't have easy
 access to the source code.

 I was referring only to the “average” and “weighted average” options
 provided by price-quotes.scm and really only concerned about whether or not
 they would affect or be affected by mods to what we store in the price db.
 I don’t think they will, so I’ll proceed with what we’ve discussed already.

 Regards,
 John Ralls


 ___
 gnucash-devel mailing list
 gnucash-devel@gnucash.org
 https://lists.gnucash.org/mailman/listinfo/gnucash-devel

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

 On Aug 19, 2015, at 1:44 PM, David Carlson david.carlson@gmail.com 
 wrote:
 
 I have been watching this thread and am glad that this discussion is 
 happening. 
 
 The price db  is also used in the reconciliation dialog when reconciling an 
 account with subaccounts. The reconciliation dialog appears to use the most 
 recent value, where I  would expect it to use nearest in time to the 
 reconciliation date.
 
 Would there any value to keeping one price from each source as opposed to 
 only one value?  Also, is it possible to have securities valued in more than 
 one currency?

Ooh, I’ll have to look into that. It doesn’t seem to me to be a good way to 
handle reconciliation. In fact I’m inclined to disable including subaccounts if 
the currencies don’t match. Can you articulate a use case where reconciling a 
parent account with multiple-currency children makes sense?

The current code doesn’t use the source info for anything other than displaying 
to the user, so there’s no present use to retaining prices with different 
sources. That doesn’t mean there would never be, but it would complicate the 
code quite a bit so the use case would have to be pretty compelling.

Yes, there’s support for security prices in multiple currencies. I think using 
that facility is likely to produce interesting results. Consider a company that 
trades on both the Shanghai and New York stock exchanges in RMB and USD 
respectively. There are a variety of reasons why one might expect the price on 
the two exchanges to be rather loosely coupled: Arbitrage difficulty, the 
current negative sentiment on Chinese exchanges and the resulting government 
controls, the desire of wealthy Chinese to expatriate their wealth, etc.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[David Carlson]

In the past I have been reconciling stocks separately from the containing
brokerage account(s), but it gets tedious in a couple of accounts that
contain several different securities.  It seems logical to me to only need
to reconcile a brokerage statement once instead of several times each
month.  I think a lot of individuals have one or more brokerage or
retirement accounts containing listed stocks and/or mutual funds.  I am
sure that it would not be trivial to implement a single reconcile for a
brokerage account, but it still should be fairly straightforward.  I would
consider this to be common enough to consider implementation.

While you correctly note that values will never be universally consistent,
I think that any one brokerage statement should be consistent within
itself, and that it is very likely to match whatever Yahoo or Google quotes
in the local currency at the end of the month, if that is the date of the
statement.

I do not have mixed currencies in one brokerage account, and while I have
seen a few emails from users that do mix currencies in their daily lives, I
think that is not very common.  I could be wrong.  GnuCash does not work
well for day traders, for example, and it does not have to work well for
every other uncommon scenario.

David C

On Wed, Aug 19, 2015 at 9:56 AM, John Ralls jra...@ceridwen.us wrote:


  On Aug 19, 2015, at 1:44 PM, David Carlson david.carlson@gmail.com
 wrote:
 
  I have been watching this thread and am glad that this discussion is
 happening.
 
  The price db  is also used in the reconciliation dialog when reconciling
 an account with subaccounts. The reconciliation dialog appears to use the
 most recent value, where I  would expect it to use nearest in time to the
 reconciliation date.
 
  Would there any value to keeping one price from each source as opposed
 to only one value?  Also, is it possible to have securities valued in more
 than one currency?

 Ooh, I’ll have to look into that. It doesn’t seem to me to be a good way
 to handle reconciliation. In fact I’m inclined to disable including
 subaccounts if the currencies don’t match. Can you articulate a use case
 where reconciling a parent account with multiple-currency children makes
 sense?

 The current code doesn’t use the source info for anything other than
 displaying to the user, so there’s no present use to retaining prices with
 different sources. That doesn’t mean there would never be, but it would
 complicate the code quite a bit so the use case would have to be pretty
 compelling.

 Yes, there’s support for security prices in multiple currencies. I think
 using that facility is likely to produce interesting results. Consider a
 company that trades on both the Shanghai and New York stock exchanges in
 RMB and USD respectively. There are a variety of reasons why one might
 expect the price on the two exchanges to be rather loosely coupled:
 Arbitrage difficulty, the current negative sentiment on Chinese exchanges
 and the resulting government controls, the desire of wealthy Chinese to
 expatriate their wealth, etc.

 Regards,
 John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

 On Aug 19, 2015, at 7:17 PM, David Carlson david.carlson@gmail.com 
 wrote:
 
 In the past I have been reconciling stocks separately from the containing 
 brokerage account(s), but it gets tedious in a couple of accounts that 
 contain several different securities.  It seems logical to me to only need to 
 reconcile a brokerage statement once instead of several times each month.  I 
 think a lot of individuals have one or more brokerage or retirement accounts 
 containing listed stocks and/or mutual funds.  I am sure that it would not be 
 trivial to implement a single reconcile for a brokerage account, but it still 
 should be fairly straightforward.  I would consider this to be common enough 
 to consider implementation.  
 
 While you correctly note that values will never be universally consistent, I 
 think that any one brokerage statement should be consistent within itself, 
 and that it is very likely to match whatever Yahoo or Google quotes in the 
 local currency at the end of the month, if that is the date of the statement.
 
 I do not have mixed currencies in one brokerage account, and while I have 
 seen a few emails from users that do mix currencies in their daily lives, I 
 think that is not very common.  I could be wrong.  GnuCash does not work well 
 for day traders, for example, and it does not have to work well for every 
 other uncommon scenario.  

Your request to be able to reconcile a brokerage statement in one go is 
reasonable, but has nothing to do with stock prices whether from previous 
transactions or Finance::Quote. You don’t reconcile a stock account on its 
monetary value, you reconcile it on the number of shares.

So in order to implement your request there would have to be a different 
reconcile window with a separate list-view pair and set of balances for each 
subaccount with unreconciled transactions in it, and the “Finish” button 
wouldn’t light up until all of them were properly reconciled. The Reconcile 
Info dialog would similarly need to collect a statement balance for each 
subaccount. ISTM that would get a bit unwieldy if you trade a lot of stocks or 
have a lot of reinvested dividends each month, but I suppose that’s also true 
of reconciling each stock account separately. Regardless, it’s immaterial to 
the price db.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

 On Aug 12, 2015, at 2:13 PM, John Ralls jra...@ceridwen.us wrote:
 It might help to consider what the price db is used for: Aside from providing 
 a default rate in the transfer dialog, it’s used for pricing assets in the 
 Accounts page and the summary bar — only the latest entry is used there. It’s 
 used for calculating values in reports, where the reports can use a weighted 
 average, nearest in time, most recent, or average cost. I need to look to see 
 if the average cost actually looks at the buy transactions or if it does 
 something similar to nearest in time and at weighted average to see what it’s 
 averaging and how it’s weighting the averaged values. Depending on what those 
 two are doing might drive whether multiple F::Q entries per day make sense, 
 assuming that the algorithms make sense.

OK, I’ve looked. They don’t use the price db, which is what one would expect. 
Weighted-average is weighted by the transaction size, which will be distorted 
by stock splits but is otherwise OK.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

 On Aug 17, 2015, at 8:07 PM, Mike Alexander m...@umich.edu wrote:
 
 On Aug 17, 2015, at 5:36 AM, John Ralls jra...@ceridwen.us wrote:
 
 
 On Aug 12, 2015, at 2:13 PM, John Ralls jra...@ceridwen.us wrote:
 It might help to consider what the price db is used for: Aside from 
 providing a default rate in the transfer dialog, it’s used for pricing 
 assets in the Accounts page and the summary bar — only the latest entry is 
 used there. It’s used for calculating values in reports, where the reports 
 can use a weighted average, nearest in time, most recent, or average cost. 
 I need to look to see if the average cost actually looks at the buy 
 transactions or if it does something similar to nearest in time and at 
 weighted average to see what it’s averaging and how it’s weighting the 
 averaged values. Depending on what those two are doing might drive whether 
 multiple F::Q entries per day make sense, assuming that the algorithms make 
 sense.
 
 OK, I’ve looked. They don’t use the price db, which is what one would 
 expect. Weighted-average is weighted by the transaction size, which will be 
 distorted by stock splits but is otherwise OK.
 
 The Advanced Portfolio report uses the Price DB to get the current value of a 
 holding.  There is an option to use a transaction price instead, but the 
 default is to use the Price DB.  The only Price DB options it supports are 
 latest and nearest in time.  If you ask it to use a transaction price (or 
 if it can't find a price in the Price DB) it uses the most recent transaction 
 which defines a price that can be converted to the report's currency.
 
 I can't speak for other reports.  I'm out of town and don't have easy access 
 to the source code.

I was referring only to the “average” and “weighted average” options provided 
by price-quotes.scm and really only concerned about whether or not they would 
affect or be affected by mods to what we store in the price db. I don’t think 
they will, so I’ll proceed with what we’ve discussed already.

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Mike Alexander]

 On Aug 17, 2015, at 5:36 AM, John Ralls jra...@ceridwen.us wrote:
 
 
 On Aug 12, 2015, at 2:13 PM, John Ralls jra...@ceridwen.us wrote:
 It might help to consider what the price db is used for: Aside from 
 providing a default rate in the transfer dialog, it’s used for pricing 
 assets in the Accounts page and the summary bar — only the latest entry is 
 used there. It’s used for calculating values in reports, where the reports 
 can use a weighted average, nearest in time, most recent, or average cost. I 
 need to look to see if the average cost actually looks at the buy 
 transactions or if it does something similar to nearest in time and at 
 weighted average to see what it’s averaging and how it’s weighting the 
 averaged values. Depending on what those two are doing might drive whether 
 multiple F::Q entries per day make sense, assuming that the algorithms make 
 sense.
 
 OK, I’ve looked. They don’t use the price db, which is what one would expect. 
 Weighted-average is weighted by the transaction size, which will be distorted 
 by stock splits but is otherwise OK.

The Advanced Portfolio report uses the Price DB to get the current value of a 
holding.  There is an option to use a transaction price instead, but the 
default is to use the Price DB.  The only Price DB options it supports are 
latest and nearest in time.  If you ask it to use a transaction price (or 
if it can't find a price in the Price DB) it uses the most recent transaction 
which defines a price that can be converted to the report's currency.

I can't speak for other reports.  I'm out of town and don't have easy access to 
the source code.

   Mike
 
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

 On Aug 13, 2015, at 8:22 AM, Geert Janssens geert.gnuc...@kobaltwit.be 
 wrote:
 
 On Thursday 13 August 2015 00:55:49 Mike Alexander wrote:
 --On August 12, 2015 at 10:23:09 AM +0200 Geert Janssens
 
 geert.gnuc...@kobaltwit.be wrote:
 I'm not really sure about the price entered vs F::Q price. I would
 imagine that if you are tracking stock, you would be interested in
 the  exact real price you bought/sold it, which is not necessarily
 exactly  the price you get from F::Q. Wouldn't that mean that the
 price entered  should be preferred over F::Q prices at least in some
 cases ?
 
 I was thinking about multiple currency transactions when I said I
 would prefer F::Q prices to transaction prices in the price DB.  For
 stock, etc., transactions your point makes sense.  In that case the
 price implied by a buy or sell is more likely to be a real price
 that should be recorded in the price DB.  On the other hand, my
 experience is that the transaction price is more likely to match the
 F::Q price for stock transactions so it matters less which you use. 
 Considering all this, I guess I still prefer to use F::Q prices over
 transaction prices in the price DB if both exist.
 
 To address another point, the Advanced Portfolio report only uses the
 price DB to calculate the current value of the commodity (and other
 things derived from current value such as unrealized gain).  Basis and
 realized gain are always calculated from actual transactions and
 their implied prices.  I'm not sure about other reports.
 
Mike
 
 What the Advanced Porfolio does looks like the right way to do it. If 
 other reports don't, they need an update.
 
 Well, I certainly learned a lot in this thread. From what I understand 
 now:
 - The price db is only intended to calculate the value of a 
 stock/foreign currency at any point in time different from the buying or 
 selling transaction (or values derived from this like unrealized gains).
 
 - In situations where the exact buy or sell price is needed it can 
 simply be calculated from the transaction itself.
 
 - The prices of these two moments are added to the price db 
 automatically to enable reports and the account hierarchy overview to 
 work by default on foreign currencies/stocks.
 
 I apologize I had all of you make such a big detour getting this clear 
 just to be back at the original point: how to deal with multiple prices 
 in one day ?
 
 For my proposal I'm starting from these assumptions we all seem to agree 
 upon:
 
 1. Prices in the price db should only be used for current value 
 calculations and are irrelevant for buy/sell transactions themselves.
 
 2. Since we don't track time on transactions, only one price per day 
 makes sense in the price db.
 
 
 With that in mind I agree with Mike that the F::Q should probably be 
 preferred at all times. Only if no F::Q price is available the user 
 entered prices (be it via price or via amount) come into play.
 
 Then back to the question as to what should happen if the user enters 
 more amount based prices in one given day ?
 - if it's the first price for that day, just add it
 - if an F::Q based price for the day is already in the db don't add a 
 transaction calculated price at all. We clearly prefer F::Q prices for 
 current value calculations.
 - if there are already (non-F::Q) prices for that day, compare them to 
 the calculated new price. If they would result in the same conversion 
 (so difference is less than 1 SCU), don't add it. Otherwise ask the user 
 which price to keep for that day as only one price per day makes sense. 
 In the other case I don't think we can come up with a sensible algorithm 
 to make a computed decision on which price to keep. So we either keep 
 two prices or ask the user which one to keep.
 
 Is that reasonable ?

I think so, mostly.

First, there’s one other use for the price db: It provides the default price to 
the transfer dialog (gnc_xfer_dialog_update_price()). The current behavior 
aggravates some people because every entry tweaks the amount slightly so the 
user has to keep editing the value in the transfer dialog. As you can imagine 
this is irritating. For an extreme case see the thread in the user list 
(http://lists.gnucash.org/pipermail/gnucash-user/2015-August/061581.html) from 
a user in the Cayman Islands, which has its own currency but which has pegged 
it to the USD. 

In examining the transfer dialog price-update code I noticed that there’s an 
exception for the currencies that have been absorbed into the Euro. The case of 
our user from the Cayman Islands and the possibility of Grexit makes me wonder 
if we should have a different way of dealing with that. Those currencies’ 
prices are never updated, but that might change for the Drachma, and while the 
Cayman Islands fellow was arguing for similar treatment for his currency it’s 
entirely possible that the Cayman Islands might change the rate from time to 
time just as the Chinese government changes the 

Re: Rounding in the price db.

[Geert Janssens]

On Thursday 13 August 2015 00:55:49 Mike Alexander wrote:
 --On August 12, 2015 at 10:23:09 AM +0200 Geert Janssens
 
 geert.gnuc...@kobaltwit.be wrote:
  I'm not really sure about the price entered vs F::Q price. I would
  imagine that if you are tracking stock, you would be interested in
  the  exact real price you bought/sold it, which is not necessarily
  exactly  the price you get from F::Q. Wouldn't that mean that the
  price entered  should be preferred over F::Q prices at least in some
  cases ?
 
 I was thinking about multiple currency transactions when I said I
 would prefer F::Q prices to transaction prices in the price DB.  For
 stock, etc., transactions your point makes sense.  In that case the
 price implied by a buy or sell is more likely to be a real price
 that should be recorded in the price DB.  On the other hand, my
 experience is that the transaction price is more likely to match the
 F::Q price for stock transactions so it matters less which you use. 
 Considering all this, I guess I still prefer to use F::Q prices over
 transaction prices in the price DB if both exist.
 
 To address another point, the Advanced Portfolio report only uses the
 price DB to calculate the current value of the commodity (and other
 things derived from current value such as unrealized gain).  Basis and
 realized gain are always calculated from actual transactions and
 their implied prices.  I'm not sure about other reports.
 
 Mike

What the Advanced Porfolio does looks like the right way to do it. If 
other reports don't, they need an update.

Well, I certainly learned a lot in this thread. From what I understand 
now:
- The price db is only intended to calculate the value of a 
stock/foreign currency at any point in time different from the buying or 
selling transaction (or values derived from this like unrealized gains).

- In situations where the exact buy or sell price is needed it can 
simply be calculated from the transaction itself.

- The prices of these two moments are added to the price db 
automatically to enable reports and the account hierarchy overview to 
work by default on foreign currencies/stocks.

I apologize I had all of you make such a big detour getting this clear 
just to be back at the original point: how to deal with multiple prices 
in one day ?

For my proposal I'm starting from these assumptions we all seem to agree 
upon:

1. Prices in the price db should only be used for current value 
calculations and are irrelevant for buy/sell transactions themselves.

2. Since we don't track time on transactions, only one price per day 
makes sense in the price db.


With that in mind I agree with Mike that the F::Q should probably be 
preferred at all times. Only if no F::Q price is available the user 
entered prices (be it via price or via amount) come into play.

Then back to the question as to what should happen if the user enters 
more amount based prices in one given day ?
- if it's the first price for that day, just add it
- if an F::Q based price for the day is already in the db don't add a 
transaction calculated price at all. We clearly prefer F::Q prices for 
current value calculations.
- if there are already (non-F::Q) prices for that day, compare them to 
the calculated new price. If they would result in the same conversion 
(so difference is less than 1 SCU), don't add it. Otherwise ask the user 
which price to keep for that day as only one price per day makes sense. 
In the other case I don't think we can come up with a sensible algorithm 
to make a computed decision on which price to keep. So we either keep 
two prices or ask the user which one to keep.

Is that reasonable ?

Geert
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Herbert Thoma]

Am 13.08.2015 um 12:52 schrieb John Ralls:

Sigh. src/app-utils/gnc-euro.[ch]. Not only hard coded but not in engine where 
it obviously belongs. Yes, obviously it should be redone as a datafile; I can’t 
imagine why those currencies aren’t part of iso-4217-currencies.xml with a tag 
indicating their absorption with a date — and for future umm, disturbances, a 
de-absorption date. Whether that’s loaded or compiled probably makes no 
difference since we have no good way of distributing updates between releases. 
Regardless, it would give us a nice platform on which to expand for pegged 
currencies.


Yes, it's all my fault ... ;-)

I did this back in 1999 or 2000, when the EUR was introduced (as book money, 
not as cash. that was 2002).
There was an euro conversion wizard/druid/whatever by Christian Stimming that 
was in app-utils (or
may be gnome-utils) and so it ended up there. BTW, I am not sure if something 
like the price db even
existed back then ... For sure we did not have iso currencies back then but 
currency was an arbitrary
string. That's why multiple codes exist for some currencies.

I agree that having these fixed exchange rates in the price db would be much 
better. Unfortunately,
I can not commit to work on this now.

 Herbert.
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Geert Janssens]

On Thursday 13 August 2015 10:06:09 John Ralls wrote:
  On Aug 13, 2015, at 8:22 AM, Geert Janssens
  geert.gnuc...@kobaltwit.be wrote: 
  On Thursday 13 August 2015 00:55:49 Mike Alexander wrote:
  --On August 12, 2015 at 10:23:09 AM +0200 Geert Janssens
  
  geert.gnuc...@kobaltwit.be wrote:
  I'm not really sure about the price entered vs F::Q price. I would
  imagine that if you are tracking stock, you would be interested in
  the  exact real price you bought/sold it, which is not necessarily
  exactly  the price you get from F::Q. Wouldn't that mean that the
  price entered  should be preferred over F::Q prices at least in
  some
  cases ?
  
  I was thinking about multiple currency transactions when I said I
  would prefer F::Q prices to transaction prices in the price DB. 
  For
  stock, etc., transactions your point makes sense.  In that case the
  price implied by a buy or sell is more likely to be a real price
  that should be recorded in the price DB.  On the other hand, my
  experience is that the transaction price is more likely to match
  the
  F::Q price for stock transactions so it matters less which you use.
  Considering all this, I guess I still prefer to use F::Q prices
  over
  transaction prices in the price DB if both exist.
  
  To address another point, the Advanced Portfolio report only uses
  the
  price DB to calculate the current value of the commodity (and other
  things derived from current value such as unrealized gain).  Basis
  and realized gain are always calculated from actual transactions
  and their implied prices.  I'm not sure about other reports.
  
 Mike
  
  What the Advanced Porfolio does looks like the right way to do it.
  If
  other reports don't, they need an update.
  
  Well, I certainly learned a lot in this thread. From what I
  understand now:
  - The price db is only intended to calculate the value of a
  stock/foreign currency at any point in time different from the
  buying or selling transaction (or values derived from this like
  unrealized gains).
  
  - In situations where the exact buy or sell price is needed it can
  simply be calculated from the transaction itself.
  
  - The prices of these two moments are added to the price db
  automatically to enable reports and the account hierarchy overview
  to
  work by default on foreign currencies/stocks.
  
  I apologize I had all of you make such a big detour getting this
  clear just to be back at the original point: how to deal with
  multiple prices in one day ?
  
  For my proposal I'm starting from these assumptions we all seem to
  agree upon:
  
  1. Prices in the price db should only be used for current value
  calculations and are irrelevant for buy/sell transactions
  themselves.
  
  2. Since we don't track time on transactions, only one price per day
  makes sense in the price db.
  
  
  With that in mind I agree with Mike that the F::Q should probably be
  preferred at all times. Only if no F::Q price is available the user
  entered prices (be it via price or via amount) come into play.
  
  Then back to the question as to what should happen if the user
  enters
  more amount based prices in one given day ?
  - if it's the first price for that day, just add it
  - if an F::Q based price for the day is already in the db don't add
  a
  transaction calculated price at all. We clearly prefer F::Q prices
  for current value calculations.
  - if there are already (non-F::Q) prices for that day, compare them
  to the calculated new price. If they would result in the same
  conversion (so difference is less than 1 SCU), don't add it.
  Otherwise ask the user which price to keep for that day as only one
  price per day makes sense. In the other case I don't think we can
  come up with a sensible algorithm to make a computed decision on
  which price to keep. So we either keep two prices or ask the user
  which one to keep.
  
  Is that reasonable ?
 
 I think so, mostly.
 
 First, there’s one other use for the price db: It provides the default
 price to the transfer dialog (gnc_xfer_dialog_update_price()). The
 current behavior aggravates some people because every entry tweaks
 the amount slightly so the user has to keep editing the value in the
 transfer dialog. As you can imagine this is irritating. For an
 extreme case see the thread in the user list
 (http://lists.gnucash.org/pipermail/gnucash-user/2015-August/061581.h
 tml) from a user in the Cayman Islands, which has its own currency but
 which has pegged it to the USD.
 
Yes, I have followed that thread also. The rounding test may reduce the 
irritation, but will probably not fix all of it.

 In examining the transfer dialog price-update code I noticed that
 there’s an exception for the currencies that have been absorbed into
 the Euro. The case of our user from the Cayman Islands and the
 possibility of Grexit makes me wonder if we should have a different
 way of dealing with that. Those currencies’ prices are never 

Re: Rounding in the price db.

[David T.]

 On Aug 13, 2015, at 6:52 AM, John Ralls jra...@ceridwen.us wrote:
 
 
 On Aug 13, 2015, at 10:51 AM, Geert Janssens geert.gnuc...@kobaltwit.be 
 wrote:
 
 On Thursday 13 August 2015 10:06:09 John Ralls wrote:
 
 First, there’s one other use for the price db: It provides the default
 price to the transfer dialog (gnc_xfer_dialog_update_price()). The
 current behavior aggravates some people because every entry tweaks
 the amount slightly so the user has to keep editing the value in the
 transfer dialog. As you can imagine this is irritating. For an
 extreme case see the thread in the user list
 (http://lists.gnucash.org/pipermail/gnucash-user/2015-August/061581.h
 tml) from a user in the Cayman Islands, which has its own currency but
 which has pegged it to the USD.
 
 Yes, I have followed that thread also. The rounding test may reduce the 
 irritation, but will probably not fix all of it.
 
 Right, which motivates the price-vs-calculated discussion below.
 
 
 In examining the transfer dialog price-update code I noticed that
 there’s an exception for the currencies that have been absorbed into
 the Euro. The case of our user from the Cayman Islands and the
 possibility of Grexit makes me wonder if we should have a different
 way of dealing with that. Those currencies’ prices are never updated,
 but that might change for the Drachma, and while the Cayman Islands
 fellow was arguing for similar treatment for his currency it’s
 entirely possible that the Cayman Islands might change the rate from
 time to time just as the Chinese government changes the rate on the
 Yuan/RMB.
 
 At one point I looked at this code and even started to implement a way 
 to have these static prices in a configuration file. That was very 
 early in my involvement with gnucash and I now consider that early work 
 way too naive to include in the code base. It did make me think about 
 the issue though and I now think the cleanest solution would be an 
 additional price source in F::Q that queries a db of static prices. 
 Ideally this price list is maintained independently of the F::Q source 
 such that even static prices can be updated if needed without requiring 
 users to upgrade their F::Q installation each time as well.
 
 That would keep the quote code in gnucash fairly straight-forward (no 
 need for the exception code anymore). And F::Q is already aimed at 
 having multiple price sources.
 
 As an intermediate solution we can also choose to keep the exception 
 code but move the prices themselves to a configuration file. This file 
 can then be manually updated if needed without having to rebuild gnucash 
 each time.
 
 I haven't thought out any details of this. These are just general ideas.
 
 Sigh. src/app-utils/gnc-euro.[ch]. Not only hard coded but not in engine 
 where it obviously belongs.
 Yes, obviously it should be redone as a datafile; I can’t imagine why those 
 currencies aren’t part of iso-4217-currencies.xml with a tag indicating their 
 absorption with a date — and for future umm, disturbances, a de-absorption 
 date. Whether that’s loaded or compiled probably makes no difference since we 
 have no good way of distributing updates between releases. Regardless, it 
 would give us a nice platform on which to expand for pegged currencies.
 
 
 
 It’s obviously my hope that the 1 scu rule will prevent any jitter,
 but we should be prepared to adjust it if necessary. Mike proposed
 early on that we treat differently prices that are entered vs. those
 that are calculated so that they’re not subjected to jitter, but that
 makes me a bit nervous. We’d obviously have to tag them differently
 in the pricedb and it would create a new precedence: F::Q,
 user-direct, user-calc or some such. Is that worth considering?
 
 That's a difficult one. I understand the benefit of this. A user entered 
 price can be considered exact and preferred over a user calculated one. 
 So it would sit in between an F::Q fetched price and one that had to be 
 calculated from the different amounts in our selection system.
 
 On the other hand my fear is adding yet another type may add to the user 
 confusion instead of reducing it. Although if it's well documented the 
 difference between the tags should be fairly easy to learn and 
 understand.
 
 Users are already pretty thoroughly confused. A little more won’t do any 
 harm. ;-)
 
 Maybe if we renamed the Price DB some variation of the Price History DB or 
 Market Price DB it would be clearer? ISTM the fundamental problem is getting 
 inexperienced users to understand that market prices and realized prices are 
 different and that only the latter apply directly to accounting. There should 
 be a discussion of that in the Tutorial… but getting people to read docs is 
 always a challenge.
 

John, 

I think renaming and documenting* would be the best way to go. Considering this 
a little more, it seems to me that there are two different issues here: basis 
and valuation. The first is (or should 

Re: Rounding in the price db.

[Geert Janssens]

On Thursday 13 August 2015 09:28:01 David T. wrote:
  On Aug 13, 2015, at 6:52 AM, John Ralls jra...@ceridwen.us wrote:
  On Aug 13, 2015, at 10:51 AM, Geert Janssens
  geert.gnuc...@kobaltwit.be wrote: 
  On Thursday 13 August 2015 10:06:09 John Ralls wrote:
  First, there’s one other use for the price db: It provides the
  default price to the transfer dialog
  (gnc_xfer_dialog_update_price()). The current behavior aggravates
  some people because every entry tweaks the amount slightly so the
  user has to keep editing the value in the transfer dialog. As you
  can imagine this is irritating. For an extreme case see the
  thread in the user list
  (http://lists.gnucash.org/pipermail/gnucash-user/2015-August/06158
  1.h
  tml) from a user in the Cayman Islands, which has its own currency
  but which has pegged it to the USD.
  
  Yes, I have followed that thread also. The rounding test may reduce
  the irritation, but will probably not fix all of it.
  
  Right, which motivates the price-vs-calculated discussion below.
  
  In examining the transfer dialog price-update code I noticed that
  there’s an exception for the currencies that have been absorbed
  into
  the Euro. The case of our user from the Cayman Islands and the
  possibility of Grexit makes me wonder if we should have a
  different
  way of dealing with that. Those currencies’ prices are never
  updated,
  but that might change for the Drachma, and while the Cayman
  Islands
  fellow was arguing for similar treatment for his currency it’s
  entirely possible that the Cayman Islands might change the rate
  from
  time to time just as the Chinese government changes the rate on
  the
  Yuan/RMB.
  
  At one point I looked at this code and even started to implement a
  way to have these static prices in a configuration file. That
  was very early in my involvement with gnucash and I now consider
  that early work way too naive to include in the code base. It did
  make me think about the issue though and I now think the cleanest
  solution would be an additional price source in F::Q that queries
  a db of static prices. Ideally this price list is maintained
  independently of the F::Q source such that even static prices can
  be updated if needed without requiring users to upgrade their F::Q
  installation each time as well.
  
  That would keep the quote code in gnucash fairly straight-forward
  (no
  need for the exception code anymore). And F::Q is already aimed at
  having multiple price sources.
  
  As an intermediate solution we can also choose to keep the
  exception
  code but move the prices themselves to a configuration file. This
  file can then be manually updated if needed without having to
  rebuild gnucash each time.
  
  I haven't thought out any details of this. These are just general
  ideas. 
  Sigh. src/app-utils/gnc-euro.[ch]. Not only hard coded but not in
  engine where it obviously belongs. Yes, obviously it should be
  redone as a datafile; I can’t imagine why those currencies aren’t
  part of iso-4217-currencies.xml with a tag indicating their
  absorption with a date — and for future umm, disturbances, a
  de-absorption date. Whether that’s loaded or compiled probably
  makes no difference since we have no good way of distributing
  updates between releases. Regardless, it would give us a nice
  platform on which to expand for pegged currencies. 
  It’s obviously my hope that the 1 scu rule will prevent any
  jitter,
  but we should be prepared to adjust it if necessary. Mike proposed
  early on that we treat differently prices that are entered vs.
  those
  that are calculated so that they’re not subjected to jitter, but
  that
  makes me a bit nervous. We’d obviously have to tag them
  differently
  in the pricedb and it would create a new precedence: F::Q,
  user-direct, user-calc or some such. Is that worth considering?
  
  That's a difficult one. I understand the benefit of this. A user
  entered price can be considered exact and preferred over a user
  calculated one. So it would sit in between an F::Q fetched price
  and one that had to be calculated from the different amounts in
  our selection system.
  
  On the other hand my fear is adding yet another type may add to the
  user confusion instead of reducing it. Although if it's well
  documented the difference between the tags should be fairly easy
  to learn and understand.
  
  Users are already pretty thoroughly confused. A little more won’t do
  any harm. ;-)
  
  Maybe if we renamed the Price DB some variation of the Price History
  DB or Market Price DB it would be clearer? ISTM the fundamental
  problem is getting inexperienced users to understand that market
  prices and realized prices are different and that only the latter
  apply directly to accounting. There should be a discussion of that
  in the Tutorial… but getting people to read docs is always a
  challenge.
 John,
 
 I think renaming and documenting* would be the best way to go.
 

Re: Rounding in the price db.

[John Ralls]

 On Aug 13, 2015, at 2:28 PM, David T. sunfis...@yahoo.com wrote:
 
 
 On Aug 13, 2015, at 6:52 AM, John Ralls jra...@ceridwen.us wrote:
 
 
 On Aug 13, 2015, at 10:51 AM, Geert Janssens geert.gnuc...@kobaltwit.be 
 wrote:
 
 On Thursday 13 August 2015 10:06:09 John Ralls wrote:
 
 First, there’s one other use for the price db: It provides the default
 price to the transfer dialog (gnc_xfer_dialog_update_price()). The
 current behavior aggravates some people because every entry tweaks
 the amount slightly so the user has to keep editing the value in the
 transfer dialog. As you can imagine this is irritating. For an
 extreme case see the thread in the user list
 (http://lists.gnucash.org/pipermail/gnucash-user/2015-August/061581.h
 tml) from a user in the Cayman Islands, which has its own currency but
 which has pegged it to the USD.
 
 Yes, I have followed that thread also. The rounding test may reduce the 
 irritation, but will probably not fix all of it.
 
 Right, which motivates the price-vs-calculated discussion below.
 
 
 In examining the transfer dialog price-update code I noticed that
 there’s an exception for the currencies that have been absorbed into
 the Euro. The case of our user from the Cayman Islands and the
 possibility of Grexit makes me wonder if we should have a different
 way of dealing with that. Those currencies’ prices are never updated,
 but that might change for the Drachma, and while the Cayman Islands
 fellow was arguing for similar treatment for his currency it’s
 entirely possible that the Cayman Islands might change the rate from
 time to time just as the Chinese government changes the rate on the
 Yuan/RMB.
 
 At one point I looked at this code and even started to implement a way 
 to have these static prices in a configuration file. That was very 
 early in my involvement with gnucash and I now consider that early work 
 way too naive to include in the code base. It did make me think about 
 the issue though and I now think the cleanest solution would be an 
 additional price source in F::Q that queries a db of static prices. 
 Ideally this price list is maintained independently of the F::Q source 
 such that even static prices can be updated if needed without requiring 
 users to upgrade their F::Q installation each time as well.
 
 That would keep the quote code in gnucash fairly straight-forward (no 
 need for the exception code anymore). And F::Q is already aimed at 
 having multiple price sources.
 
 As an intermediate solution we can also choose to keep the exception 
 code but move the prices themselves to a configuration file. This file 
 can then be manually updated if needed without having to rebuild gnucash 
 each time.
 
 I haven't thought out any details of this. These are just general ideas.
 
 Sigh. src/app-utils/gnc-euro.[ch]. Not only hard coded but not in engine 
 where it obviously belongs.
 Yes, obviously it should be redone as a datafile; I can’t imagine why those 
 currencies aren’t part of iso-4217-currencies.xml with a tag indicating 
 their absorption with a date — and for future umm, disturbances, a 
 de-absorption date. Whether that’s loaded or compiled probably makes no 
 difference since we have no good way of distributing updates between 
 releases. Regardless, it would give us a nice platform on which to expand 
 for pegged currencies.
 
 
 
 It’s obviously my hope that the 1 scu rule will prevent any jitter,
 but we should be prepared to adjust it if necessary. Mike proposed
 early on that we treat differently prices that are entered vs. those
 that are calculated so that they’re not subjected to jitter, but that
 makes me a bit nervous. We’d obviously have to tag them differently
 in the pricedb and it would create a new precedence: F::Q,
 user-direct, user-calc or some such. Is that worth considering?
 
 That's a difficult one. I understand the benefit of this. A user entered 
 price can be considered exact and preferred over a user calculated one. 
 So it would sit in between an F::Q fetched price and one that had to be 
 calculated from the different amounts in our selection system.
 
 On the other hand my fear is adding yet another type may add to the user 
 confusion instead of reducing it. Although if it's well documented the 
 difference between the tags should be fairly easy to learn and 
 understand.
 
 Users are already pretty thoroughly confused. A little more won’t do any 
 harm. ;-)
 
 Maybe if we renamed the Price DB some variation of the Price History DB or 
 Market Price DB it would be clearer? ISTM the fundamental problem is getting 
 inexperienced users to understand that market prices and realized prices are 
 different and that only the latter apply directly to accounting. There 
 should be a discussion of that in the Tutorial… but getting people to read 
 docs is always a challenge.
 
 
 John, 
 
 I think renaming and documenting* would be the best way to go. Considering 
 this a little more, it seems to me that there 

Re: Rounding in the price db.

[Mike Alexander]

--On August 13, 2015 at 10:06:09 AM +0100 John Ralls 
jra...@ceridwen.us wrote:



Another related thought: Answering a dialog box every time one enters
a two-currency transaction is going to annoy anyone who has to enter
a bunch of such transactions. I can think of several ways of dealing
with that, in order of my preference: A radio button on the transfer
dialog whose last value is retained, an “always do this” checkbox
on the what to do with the rate dialog, or a preference setting.
Which do you prefer (ignore the problem is another option)?


Actually, I think ignore the problem is a reasonable approach in this 
case.  If we get the prices in the Price DB sorted out properly, then 
the default in the transfer dialog will be correct in most cases which 
means the extra work for the user resulting from showing it is minimal. 
At least I wouldn't mind, and it would give me a chance to verify that 
the price chosen made sense.


When I'm entering foreign currency purchases (e.g., using a CAD or GBP 
credit card) that's pretty much what I do already.  All my expense 
accounts are USD and I update the Price DB daily so I generally just 
accept the default conversion from the transfer dialog in this case. 
It really doesn't slow me down much.  I think the problem comes if the 
default isn't good enough.


Mike


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[David T.]

 On Aug 12, 2015, at 9:27 AM, Geert Janssens geert.gnuc...@kobaltwit.be 
 wrote:
 
 On Wednesday 12 August 2015 14:13:46 John Ralls wrote:
 On Aug 12, 2015, at 9:23 AM, Geert Janssens
 geert.gnuc...@kobaltwit.be wrote: 
 On Tuesday 11 August 2015 23:12:58 Mike Alexander wrote:
 --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
 
 Exchange rates and prices is not my area at all. I never really used
 it. So I'm trying my best to imagine how the prices are being used.
 
 Having said that, here are my thoughts. Feel free to dismiss them if
 I'm talking nonsense.
 
 I'm not really sure about the price entered vs F::Q price. I would
 imagine that if you are tracking stock, you would be interested in
 the exact real price you bought/sold it, which is not necessarily
 exactly the price you get from F::Q. Wouldn't that mean that the
 price entered should be preferred over F::Q prices at least in some
 cases ?
 
 That seems the use case for which the transfer dialog is currently
 coded. It falls apart when a user is entering transfers by amount
 instead of by price.
 
 And perhaps you might even want multiple prices for one day if you
 happened to buy/sell at a big price difference intra-day. Perhaps
 that won't happen often, but it would be bad if it couldn't be
 modeled in gnucash.
 
 All of this assumes of course that the gnucash reports know which
 price to use given multiple choices.
 
 Half-baked idea: suppose a user enters a new transaction and uses
 the
 amount fields in the tranfer dialog. 

Re: Rounding in the price db.

[John Ralls]

 On Aug 12, 2015, at 4:18 PM, David T. sunfis...@yahoo.com wrote:
 John,
 
 One other common use case for the Price DB is to track a stock’s value over 
 time. In that circumstance, multiple price DB values (presumably no more than 
 one per day) would be used. Many users want this functionality, as evidenced 
 by the requests over the years to have mechanisms to provide historical 
 quotes or automatic retrieval, etc. These are driven (I believe) by the 
 desire to see how a commodity is or has performed over time. 
 
 And while it takes this discussion on a different trajectory, I think it is 
 nonetheless germane to note that how GnuCash uses and stores commodity values 
 doesn’t match the expectations of many users. Users are confused by the Price 
 In Transaction vs. Price in PriceDB distinction (I know I am, and I suspect I 
 am exhibiting it here!). 
 
 Since you are discussing fundamental issues with the PriceDB, I’ll take the 
 liberty of saying that I would love to have more PriceDB functionality—for 
 example, to be able to have bulk methods for adding or pruning prices at set 
 intervals (such as weekly or monthly); to optionally omit commodities with 
 zero balance holdings; to automatically skip over erroneous quotes and report 
 on problems after the fact. I am sure others have ideas as well. 

David,

Yup, that other use is included in “calculating values in reports”. No one’s 
suggesting anything that would break the net worth graphs.

I know about and understand the confusion about the difference between price in 
a split (it’s amount/value, where amount is the quantity of this account’s 
commodity and value what that amount is worth in the other account’s commodity) 
and the price stored in the price db, which might be the same if it’s recorded 
from a transaction but can also be from a manual entry in the price editor or a 
downloaded price from Finance::Quote. Do you have any suggestions to make the 
distinction easier to understand?

As for enhancements to online quote retrieval, that isn’t going to happen 
anytime soon unless someone steps up to do it. 

Regards,
John Ralls
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Mike Alexander]

--On August 12, 2015 at 10:23:09 AM +0200 Geert Janssens 
geert.gnuc...@kobaltwit.be wrote:



I'm not really sure about the price entered vs F::Q price. I would
imagine that if you are tracking stock, you would be interested in
the  exact real price you bought/sold it, which is not necessarily
exactly  the price you get from F::Q. Wouldn't that mean that the
price entered  should be preferred over F::Q prices at least in some
cases ?


I was thinking about multiple currency transactions when I said I would 
prefer F::Q prices to transaction prices in the price DB.  For stock, 
etc., transactions your point makes sense.  In that case the price 
implied by a buy or sell is more likely to be a real price that 
should be recorded in the price DB.  On the other hand, my experience 
is that the transaction price is more likely to match the F::Q price 
for stock transactions so it matters less which you use.  Considering 
all this, I guess I still prefer to use F::Q prices over transaction 
prices in the price DB if both exist.


To address another point, the Advanced Portfolio report only uses the 
price DB to calculate the current value of the commodity (and other 
things derived from current value such as unrealized gain).  Basis and 
realized gain are always calculated from actual transactions and their 
implied prices.  I'm not sure about other reports.


   Mike

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Geert Janssens]

On Tuesday 11 August 2015 23:12:58 Mike Alexander wrote:
 --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

Exchange rates and prices is not my area at all. I never really used it. 
So I'm trying my best to imagine how the prices are being used.

Having said that, here are my thoughts. Feel free to dismiss them if I'm 
talking nonsense.

I'm not really sure about the price entered vs F::Q price. I would 
imagine that if you are tracking stock, you would be interested in the 
exact real price you bought/sold it, which is not necessarily exactly 
the price you get from F::Q. Wouldn't that mean that the price entered 
should be preferred over F::Q prices at least in some cases ?

That seems the use case for which the transfer dialog is currently 
coded. It falls apart when a user is entering transfers by amount 
instead of by price.

And perhaps you might even want multiple prices for one day if you 
happened to buy/sell at a big price difference intra-day. Perhaps that 
won't happen often, but it would be bad if it couldn't be modeled in 
gnucash.

All of this assumes of course that the gnucash reports know which price 
to use given multiple choices.

Half-baked idea: suppose a user enters a new transaction and uses the 
amount fields in the tranfer dialog. Instead of unconditionally creating 
a new price based on this, we could go over the existing prices for that 
day and calculate if any of them would give the same amount results 
after rounding. 

Re: Rounding in the price db.

[Geert Janssens]

On Wednesday 12 August 2015 14:13:46 John Ralls wrote:
  On Aug 12, 2015, at 9:23 AM, Geert Janssens
  geert.gnuc...@kobaltwit.be wrote: 
  On Tuesday 11 August 2015 23:12:58 Mike Alexander wrote:
  --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
  
  Exchange rates and prices is not my area at all. I never really used
  it. So I'm trying my best to imagine how the prices are being used.
  
  Having said that, here are my thoughts. Feel free to dismiss them if
  I'm talking nonsense.
  
  I'm not really sure about the price entered vs F::Q price. I would
  imagine that if you are tracking stock, you would be interested in
  the exact real price you bought/sold it, which is not necessarily
  exactly the price you get from F::Q. Wouldn't that mean that the
  price entered should be preferred over F::Q prices at least in some
  cases ?
  
  That seems the use case for which the transfer dialog is currently
  coded. It falls apart when a user is entering transfers by amount
  instead of by price.
  
  And perhaps you might even want multiple prices for one day if you
  happened to buy/sell at a big price difference intra-day. Perhaps
  that won't happen often, but it would be bad if it couldn't be
  modeled in gnucash.
  
  All of this assumes of course that the gnucash reports know which
  price to use given multiple choices.
  
  Half-baked idea: suppose a user enters a new transaction and uses
  the
  amount 

Re: Rounding in the price db.

[John Ralls]

 On Aug 12, 2015, at 9:23 AM, Geert Janssens geert.gnuc...@kobaltwit.be 
 wrote:
 
 On Tuesday 11 August 2015 23:12:58 Mike Alexander wrote:
 --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
 
 Exchange rates and prices is not my area at all. I never really used it. 
 So I'm trying my best to imagine how the prices are being used.
 
 Having said that, here are my thoughts. Feel free to dismiss them if I'm 
 talking nonsense.
 
 I'm not really sure about the price entered vs F::Q price. I would 
 imagine that if you are tracking stock, you would be interested in the 
 exact real price you bought/sold it, which is not necessarily exactly 
 the price you get from F::Q. Wouldn't that mean that the price entered 
 should be preferred over F::Q prices at least in some cases ?
 
 That seems the use case for which the transfer dialog is currently 
 coded. It falls apart when a user is entering transfers by amount 
 instead of by price.
 
 And perhaps you might even want multiple prices for one day if you 
 happened to buy/sell at a big price difference intra-day. Perhaps that 
 won't happen often, but it would be bad if it couldn't be modeled in 
 gnucash.
 
 All of this assumes of course that the gnucash reports know which price 
 to use given multiple choices.
 
 Half-baked idea: suppose a user enters a new transaction and uses the 
 amount fields in the tranfer dialog. Instead of unconditionally creating 
 a new price based on this, we could go over the existing prices for that 
 day and calculate if 

Re: Rounding in the price db.

[John Ralls]

 On Aug 11, 2015, at 8:29 AM, Geert Janssens geert.gnuc...@kobaltwit.be 
 wrote:
 
 On Monday 10 August 2015 16:27:40 John Ralls wrote:
 On Aug 10, 2015, at 10:34 AM, Geert Janssens
 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.
 
 
 I'm probably slow here. What mess would that create ?

Rounding errors leading to imbalances. Suppose the amount I paid for a car in 
June got rounded to six significant digits: The pennies would get rounded off 
(12,345.67). 

Regards,
John Ralls


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[John Ralls]

 On Aug 10, 2015, at 10:44 PM, Mike Alexander m...@umich.edu wrote:
 
 --On August 10, 2015 at 4:27:40 PM +0100 John Ralls jra...@ceridwen.us 
 wrote:
 
 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.
 
 Six significant digits would probably do, although I would argue for a few 
 more to properly convert large quantities of a commodity.  However 10 decimal 
 places is easier to implement and is probably just as good. That seems to be 
 what the XE conversion tables at http://www.xe.com/currencytables/ use. 
 Even that falls down converting gold to Sao Tomean Dobra, but it works ok for 
 any real currency.  It gives 6 digits of accuracy converting between Kuwaiti 
 Dinar and Sao Tomean Dobra which is the biggest ratio I can find.

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. 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.

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?

Regards,
John Ralls



___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Geert Janssens]

On Monday 10 August 2015 16:27:40 John Ralls wrote:
  On Aug 10, 2015, at 10:34 AM, Geert Janssens
  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.
 

I'm probably slow here. What mess would that create ?

Geert

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Mike Alexander]

--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

Re: Rounding in the price db.

[John Ralls]

 On Aug 10, 2015, at 10:34 AM, Geert Janssens geert.gnuc...@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
 jra...@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.444615.  if you rounded
 this to 0.44, 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


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Mike Alexander]

--On August 10, 2015 at 4:27:40 PM +0100 John Ralls 
jra...@ceridwen.us wrote:



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.


Six significant digits would probably do, although I would argue for a 
few more to properly convert large quantities of a commodity.  However 
10 decimal places is easier to implement and is probably just as good. 
That seems to be what the XE conversion tables at 
http://www.xe.com/currencytables/ use. Even that falls down 
converting gold to Sao Tomean Dobra, but it works ok for any real 
currency.  It gives 6 digits of accuracy converting between Kuwaiti 
Dinar and Sao Tomean Dobra which is the biggest ratio I can find.


 Mike


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Geert Janssens]

On Sunday 09 August 2015 19:29:51 Mike Alexander wrote:
 --On August 9, 2015 at 8:35:04 PM +0100 John Ralls
 jra...@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.444615.  if you rounded
 this to 0.44, 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 ?

Geert

___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: 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 
jra...@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.444615.  if you rounded this 
to 0.44, 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
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Re: Rounding in the price db.

[Mike Alexander]

--On August 9, 2015 at 8:35:04 PM +0100 John Ralls jra...@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.444615.  if you rounded this to 
0.44, 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


___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel