On Thu, Jul 06, 2000 at 12:33:04PM -0500, Richard Wackerbarth wrote:
>
> The difference is in the storage.
>
> You propose to store
> (numerator, denominator==f(currency), currency)
> for each entry
> and hope that someone enforces the == relation.
>
> I, on the other hand would store only
> (numerator, currency)
> for each entry
> and store
> (currency, denominator==f(currency))
> only once in a different table.
I mentioned this issue before, but I'll mention it again:
I'd like to use whatever library comes out of this for storing
historical price data for various financial instruments. Certain
of these have changed "denominator" over time.
For example, certain UK Govt Bonds have decimalized recently. They
were previously quoted in 32nds, and are now quoted in 100ths. This
is particularly annoying, since you can't convert old prices to new
without loss of precision (i.e. 1/32 = 0.03125 = 3/100 + error).
In the "BG" scheme, I can store historical prices as
(price, 32, Gilts) or (price, 100, Gilts), with both being treated as
the same basic sort of thing. This is very convenient for doing a
longer-term analysis.
In the "RW" scheme, I have to store them as (price, Gilts_32) and
(price, Gilts_100), and I have to know that Gilts_32 and Gilts_100 are
different "commodities" only in the sense that they are quoted in
different terms, and that the true price history of these particularly
UK Govt Bonds come from concatenating the Gilt_32 and Gilt_100 price
series. This is certainly not undoable, but it is a pain.
Advocates of the "RW" scheme could certainly argue:
(1) That this is a very unusual or exotic example, or that it is
beyond the scope of what this library should seamlessly and
transparently be able to accomodate.
(2) That representing the prices of financial instruments is a
different matter that representing quantities of currency for
accounting purposes, and thus these kinds of issues shouldn't be
allowed to add complexity to a perfectly adequate design.
However, the "BG" scheme (apparently) give you the capability to deal
with the situation very simply, and in the "RW" scheme it must be
worked around with great pain and suffering... Which is OK, if it is
outside of the design goals. But based on this, I think that it would
be wrong to say that the BG and RW approaches are essentially
isomorphic.
I admit that this situation with British Gilts may seem fairly obscure
from the U.S. personal finance perspective, but it will become very
relevant to anyone writing code related to U.S. equities if/when the
NYSE and NASDAQ Exchanges decimalize.
-JT
--
GNU/Linux: Free your mind and your OS will follow.
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
