On Thu, 06 Jul 2000, Jon Trowbridge wrote:
> On Thu, Jul 06, 2000 at 12:33:04PM -0500, Richard Wackerbarth wrote:

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

This is correct. Exchange rates (prices) are a different "animal". Do the 
DIMENSIONAL analysis! We will need to store those in a two dimensional form 
rather than the single dimension for money.

Although you CAN always store a one dimensional quantity in a two dimensional 
space, there are penalties to pay for doing so.

If you critically look at the layer which must be placed on top of 
"rationals" to do the real financial calculations, I think that you will find 
that there is NO ADVANTAGE to be gained in storing the one dimensional values 
in 2-space. You will still have to pass them through the same calculational 
interface. Further, in the IMPLEMENTATION of that interface, you don't really 
gain anything by using the more complex representation.

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

They are NOT isomorphic in the sense that they can do the same things.

In my scheme, you cannot store an AMOUNT in the wrong representation.
However, I require a different "typedef" for Exchange Rates.

In Bill's scheme, he has only one "typedef" for the numeric value of both 
AMOUNTS and PRICES. I will argue that by the time you tack on the additional 
information needed to describe these differing items, you will still have 
different "typedef"s and have not gained anything by forcing them both into 
the same mold.

--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]


Reply via email to