Posted by
Ferdinando M. Ametrano-2 on
Dec 24, 2001; 8:53am
URL: http://quantlib.414.s1.nabble.com/currency-quep-tp1814p1815.html
Welcome aboard Joel.
>i have some experience implementing from the OMG CBO specs
if anybody needs a reference, here it is:
ftp://ftp.omg.org/pub/docs/formal/00-06-29.pdf
If I'm wrong and there is a more recent reference, please correct me.
More OMG references are linked from
http://quantlib.org/marketconventions.html>is someone already working on the currency quep?
No, as far as I know
>if not, i need to get a feel for how strictly we want to follow the OMG
>guidelines. Do we want to redesign (or wrap) the Date, Time, etc classes
>to conform to the CBO interfaces as well (following the OMG spec line for
>line)? Or do we want to use the OMG spec more as a guideline to design
>just the Currency classes (adapting the interface definitions to agree
>with the existing code)?
Here's my $0.2
I think it could be wise to rely on your previous *experience* with the OMG
CBO specs. If anybody wants to share his own experience, please join this
discussion.
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.
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.
ciao -- Nando