Posted by
Luigi Ballabio-4 on
Jan 02, 2002; 3:24am
URL: http://quantlib.414.s1.nabble.com/currency-quep-tp1814p1822.html
Hi Joel,
At 03:02 AM 12/31/01 -0800, Joel Nelson wrote (with snipping by Luigi):
>i generally agree with your comments about the OMG spec:
>
> > My point is: the specification is clearly written with CORBA in mind,
> > which is good for the specification itself and the application
> > layerbut forces one to use only a limited set of language features.
> > However, QuantLib is a C++ library: let's use the full power of C++
> > instead. Conformance can be achieved by means of a wrapping layer.
>
>the value of the OMG design comes from its completeness: the basic model
>(Currency, Money, ExchangeRate, ExchangeRateManager) is a clean and
>sufficiently complete decomposition of the "Currency" domain to cover most
>needs. if we make sure we design in these basic classes (or use existing
>classes that encapsulate the logic) and cover their member fields (with
>the appropriate types for QuantLib) and methods (whether by function or
>operator passing/returning the appropriate types for QuantLib) then we'll
>end up with a solid currency module. i think we're all on the same page here.
I think so, too.
>I think that the QuantLib::Date is pretty complete. The Date is typically
>used to tell when a currency is in circulation and for choosing an
>exchange rate. In my experience, "end of day" rates were always used, so
>day level granularity would have been sufficient. This temps me to say
>that we don't *really* need to wrap QuantLib::Date for now. However, with
>24 hour trading, the idea of "end of day" is probably going to vanish at
>some point. Maybe it would be good to wrap it with a DateTime class up
>front and get this out of the way.
I agree. To wrap it into DateTime won't make any harm to any existing code.
We'll have time to debate whether to collapse date and time-of-day _into_ Date.
>This is going to be my biggest problem with the QuEP - i just don't know
>the existing code well enough yet. It is probably best to go back and
>forth and collaborate on the spec. I will start by responding briefly to
>your comments below. We can just email drafts back and forth but we need
>to come up with a tighter way to communicate. I will email you separately
>with some ideas.
If Nando gives you developer status (hint, hint), we can work on the QuEP
over CVS. For the time being we go by email. Here are a few comments to
your comments (skipping the parts where we already agree with each other):
> > CurrencyBook:
> > application layer.
> >
> > MoneyCalculator:
> > we can use operator overloading on class Money instead. The base currency
> > can be kept as a static member of Money. The same applies to the
> > conversion type.
>
>i don't really like moving BaseCurrency into a static member of Money. i
>generally don't like to have a static member out there in a class for
>which we will have many instances being passed around.
>
>i see your point on conversion type being static. i am just not sure i
>like it being in Money for the reason I mentioned above. could we leave a
>class with all static members like "MoneyCalculationParams" that contains
>both the BaseCurrency and the ConversionType? If we did this, then I
>would say that we don't need the CurrencyBook anymore.
I see your point. Yes, I like the settings class with static members. And
it's a real pity that C++ doesn't support macros like Scheme, or block
syntax like Ruby; I would have loved to be able to write:
withBaseCurrency(EUR) {
m1 = m2+m3;
}
But of course one can't have everything...
> > ExchangeRateManager:
> > we can keep it. Also, we could implement it so that adding an exchange
> > rate between two currencies automatically adds its reciprocal.
>
>adding the reciprocal might be costly in terms of memory to hold all the
>conversions. conversion tables grow pretty quickly if you are converting
>the daily valuations for many currencies over any length of time. it
>really depends on what we foresee as the bigger hit. memory v. cpu
>cycles, i guess. maybe i'm just being paranoid.
Well, I was only thinking of adding, say, USD/EUR when EUR/USD is added.
Sitting down to implement a real conversion table (one that would deduce
EUR/GBP from EUR/USD and USD/GBP) could make my head explode.
But on second thought, the simpler idea could be tricky too if there's any
rounding rule and stuff. I think we can skip it for the time being.
> > Currency:
> > 3) Specific currencies such as EUR or USD would not be constructed using
> > the generic Currency constructor, but would rather be implemented as
> > derived classes which initialize the CurrencyData with the appropriate
> > values. This would also allow to use the Singleton pattern for the latter.
>
>i'm not sure i understand 100%. do you mean that the major currencies
>would be implemented in derived classes so that upon instantiation (e.g.
>new USDCurrency() ) they would init CurrencyData with 'USD', 'U.S.
>Dollar", and such?
Yes, that is the idea.
>If so, it might make sense to implement the EUR so that it initializes
>that exchange rates of all the member currencies and adds them to the
>ExchangeRateManager as well. (That is, if i have gotten your drift.)
I hadn't thought of that, but I think it could be done. The only thing I'm
afraid of is the possibility of the dreadful "static initialization order
fiasco" (see
http://www.parashift.com/c++-faq-lite/ctors.html). It might
make sense to write a function which does the work and leave it to the
application to call it, instead of calling it during library initialization.
> > ExchangeRateDateBased:
> > I have to think about this. One possibility is to keep it as is. Another
> > is to implement the same functionality by using ExchangeRateManager for
> > storing ExchangeRates with an associated start and end date, and add
> > methods to the former to retrieve the stored ExchangeRate instances.
>
>i don't like the ExchangeRate without the dates. I don't think the
>conversion factor is any good without a start/end date to qualify it. if
>you need constant conversions you could add a member flag that specifies
>that. Then again, I need to take a closer look at the MarketElement class
>before going much further. I will come back to you on this.
You are right. I have been collapsing two concepts in my head which should
be kept separated instead. The ExchangeRate class with a MarketElement
would model the concept of "the current exchange rate"---an object whose
value dynamically changes so that you are notified of changes and always
get the most recent rate when you inspect it. The ExchangeRateDateBased
would model static values, and as such can store its value as a simple
double variable.
> > AmountOfTime:
> > QuantLib::Period can be morphed into this. However, I would consider it a
> > data type and remove setters.
>
>i need to take a look at QuantLib::Period. I am not sure we need to morph
>it into AmountOfTime if it works as is.
I think some amount of work is needed to get a useful Period class.
Currently it's just a simple class which can describe periods such as "6
months", "2 weeks" or "4 days" but not, say, "2 weeks and 4 days". Also, it
is not aware of the relationship between time units, so that if a Period
instance is created as "2 weeks" it is not able to present itself as "14
days". We'll have to think a bit more about this.
Bye for now,
Luigi