irc pricedb discussion

Rob Browning
27 Feb 2001 15:04:07 -0600

It was suggested that this might be valuable info for the devel list
until I manage to write up an overview for the pricedb...

<cstim> rlb: any thought about weighted average commodity prices?

<rlb> cstim: yes - I was planning to reply later today, but my initial
answer is that the pricedb isn't the right place for that kind of
info.  A weighted average is a cached computation.  It varies based on
your set of transactions, and has to be computed when needed.

<grib> cstim: I agree with rlb.  There are too many params to a
weighted average to store all the possible results in the price db.

<rlb> cstim: now it is true that you may want to cache these values if
computing them is expensive, but that's no different than caching
account totals, etc.

<grib> I think basically the upshot is that the price db is just for
"spot quotes".

<cstim> some of those "spot quotes" are also stored with each
commodity transaction, aren't they?

<rlb> cstim: no.

<cstim> so how does buying USD 100 for EUR 150 affect the pricedb?

<rlb> cstim: all pricedb quotes are independent quotes.  There are no
explicit quotes in the register data, only implicit ones.

<rlb> cstim: It doesn't.

<rlb> cstim: there's an implicit quote in your example based on the
number of shares and value, but that's part of the transaction, and
not a pricedb quote per say.

<rlb> cstim: right now, the pricedb is primarily a place to put legacy
online quotes and new online quotes.  In the future it'll be used for
graphing and reporting...

<cstim> rlb: so the implicit price of a transaction and an entry in
the pricedb may differ, even if they occured at the same moment?

<rlb> cstim: yes, though they're not the same.  One's the official
record of an event (the one in your register/transaction), and one's a
piece of info that came from some "source" whether online
(i.e. "Finance::Quote"), or from the user via hand-entry.

<cstim> rlb: woo hoo. I understood what's going on. :)

<rlb> Implying any link other than the expected, though possibly
non-existent (imagine Yahoo has a day with corrupted data) correlation
would be "wrong".

<cstim> ?

<cstim> could you please say that again?

<rlb> cstim: You expect that a quote for IBM at instant X from yahoo
would match exactly with the implicit price from the transaction you
made at instant X to buy 100 shares, but that's just an expectation.
It might or might not end up being true.

<rlb> cstim: A case where it wouldn't be true (blatantly) is if yahoo
has a some kind of corruption at the time you ask for the quote.

<cstim> rlb: yes. Which leads to the next (new) question: How would
reports resolve contradictions? But that question may well be

<rlb> cstim: but there are other more likely and subtle possibilities.

<rlb> cstim: They won't.  Reports should present information "with
respect to" a particular source of information, and will only be
considered accurate to the extent that the source is accurate.

<cstim> rlb: well, at least any report would offer the option whether
it should use the implicit prices from the recorded transactions, or
the price quotes from the pricedb.

<rlb> cstim: for example, you could have an "audit-q3" report that
needs to be generated wrt some "official quotes".  These you would
probably hand-enter with a "source" tag of "user:my-company-audit-q3".
There should be a way to tell the report to use only quotes with that
"source".  Or similar...

<cstim> rlb: I agree. So that means that the resolving of
contradicting prices happens by letting the user chose one of the
price sources,

<rlb> cstim: something like that.  I consider all this to be in its
infancy, so I'm sure we'll have to work some of it out as we go along.

<rlb> cstim: the main point for now was to get *something* fairly
reasonble implemented, and to get us to a point where we're not
throwing away the user's old data anymore.

<cstim> rlb: another issue: I was wondering whether it's possible to
deal with both the pricedb and implicit prices from transactions under
the same API.

<cstim> right now both would be completely different.

<rlb> cstim: maybe, though I haven't thought through about whether or
not I think that's the "right thing(TM)".

<rlb> cstim: if nothing else, efficiency-wise, there will be a *huge*
difference between accessing the two.

<cstim> sure

<rlb> cstim: the pricedb, esp if you know you want quote for IBM in
USD on X, say, should be very fast.  Finding that in the implicit
prices would require a full account traversal.

<rlb> (or a query for all stock accounts followed by a traversal of
all the relevant splits).

<cstim> but from a report's point of view: once the report figured out
which prices to use, it should be able to go on from that point
independently of where that prices came from.

<cstim> that's my motivation to unify both approaches as much as

<rlb> cstim: but (not having thought this through), I'm wondering if
the types of reports you'd want for implicit quotes might not be
nearly always different from the types of reports you'd want from
pricedb quotes...  --> goonie

( has joined #gnucash

<rlb> the former seems more likely to be "capital gains" style reports
which involve crawling splits anyway, and the latter seem more likely
to be "daily value graph" style...

<rlb> dunno.

<cstim> dunno either

<rlb> cstim: I'd say lets move forward and hammer out what we need as
we need it.

<goonie> morning/afternoon all . .

<grib> hi goonie

<cstim> rlb: but I suppose there could be situations where a report
needs both

<goonie> rlb, cstim: it seems I have walked into a reporting
discussion . . .

<cstim> ho goonie

<rlb> cstim: also, an alternative might be to have an option that
would build a temporary pricedb given a list of splits.

<cstim> rlb: yeah, *that* sounds like a "good idea (TM)"

<rlb> cstim: or maybe a way to say "find all implicit quotes and merge
them into the main pricedb" (though unless we *really* need that, I
like it less...)

<cstim> rlb: because that's basically what I already coded

<rlb> goonie: howdy.

<cstim> btw does someone has a trademark on the "right thing (TM)"?

<rlb> Has anyone been having any trouble with

<rlb> cstim: no idea :>

<goonie> Coca-Cola has trademarked "the real thing" IIRC.

<dres> there's a trademark on bookshelf.  i wouldn't be surprised :)

<rlb> dres: retch.

<cstim> rlb: to wrap this up, maybe you could post an excerpt of this
discussion to the ML, for later reference, --- dres has changed the
topic to: Today's Gripe: People exchanging "What's right or wrong"
with "What's legal" :/

<cstim> the "legal thing(TM)"?

<rlb> cstim: or perhaps I should just write up a doc for the pricedb?

<rlb> :>

<cstim> :)

Rob Browning <> PGP=E80E0D04F521A094 532B97F5D64E3930