currency quep intial - Re:currency quep

Posted by Joel Nelson-3 on Dec 26, 2001; 8:11pm
URL: http://quantlib.414.s1.nabble.com/currency-quep-tp1814p1816.html

Ferdinando Ametrano wrote

 > if anybody needs a reference, here it is:
 > ftp://ftp.omg.org/pub/docs/formal/00-06-29.pdf


I am working from this doc.


 > What I like is the Currency/Money/ExchangeRate design, including the
 > ExchangeRateManager, the MoneyFormatter, Conversion and Rounding types.
 > I see all this stuff as a building block for the FX framework, and in
 > this sense we could consider to use the OMG spec as guidelines.
 > We could start an iterative process toward strict conformance.
 > Of course if we can obtain strict conformance in only one step with a
 > *reasonable* effort I would not object.


I agree with you and it is in line with the work i have done previously.
    In the redesign of the forex module, we decided to follow the
"spirit" of the OMG documents for holding rates and converting
currencies more than directly trying to map the specs to our code.  I
think that approach makes sense with a lot of existing code base

Since we are building the currency module pretty much from the ground
level we can afford to follow the OMG spec a lot more closely.  However,
I agree with you - we don't need to go all out resigning all the related
classes at this point.  Once we have the FX framework in place, we can
re-evaluate the need.

Btw. I am talking about the CBO model and not necessarily the networked
object model.  In a core library like this, I don't think we need to
always be passing by value and such.  Anyone have other ideas on this?

One class I think we should consider redesigning is the class you
mentioned below : Time...


 >
 > If I got things right the QuantLib Date class could be redesigned to
 > conform to the OMG DTime class.
 > QuantLib::Time is currently only a typedef to double: it measures time
 > in years, with the ambiguity it does not know which DayCount convention
 > has been used to calculate it.
 > The OMG DAmountOfTime represents an absolute (positive) amount of time
 > that can be added to, subtracted from, or used to hold differences of
 > DTime objects. A DAmountOfTime object is defined as a specified number
 > of weeks, days, hours, minutes, and seconds. The link here is that every
 > Time calculation implies the calculation of a number of days.
 > I know that Time is used as negative quantity somewhere in QuantLib, but
 > I think  this can be changed, especially because I see a strong
 > rationale behind Time as an absolute positive amount of time: if you're
 > dealing with what happened in the past (i.e. before your reference_date)
 > you need actual dates (fixings, etc.). You only need Time when you're
 > calculating something with your analytics, that is something in the
future.
 >


Given what you've written, I think it might be wise to take the hit with
the Time class.  It sounds like it has quite a few potential
shortcomings.  Admittedly, I am not that familiar (yet) with the
requirements of quant systems.  However, in the systems I've worked on,
having a flexible Time class (like DTime) has proven indispensable.  I
would only imagine that we will find uses for it once we have it
implemented.


Let me know what you guys think.


joel