Re: Rounding in the price db.

> 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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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 >

Re: Rounding in the price db.

> 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

Re: Rounding in the price db.

> 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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

> 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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

> 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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

e, 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> &

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

> 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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

> 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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

> 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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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,

Re: Rounding in the price db.

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

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,

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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.

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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.

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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.

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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:

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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,

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

(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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

-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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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

Re: Rounding in the price db.

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.

Re: Rounding in the price db.

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

Rounding in the price db.

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

Re: Rounding in the price db.

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