currency quep

[Joel Nelson-3]

hello all.

i have some experience implementing from the OMG CBO specs so i thought
the currency quep might be a good place to begin contributing and to
familiarize myself with the code base.  but first i have a couple of
questions:

is someone already working on the currency quep?

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)?

if anyone has any other thoughts on the issue, put them out on the list.

thanks,

joel

[Ferdinando M. Ametrano-2]

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

[Joel Nelson-3]

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

[Ferdinando M. Ametrano-2]

Hi Joel

>I think it might be wise to take the hit with the Time class.  It sounds
>like it has quite a few potential shortcomings. [...] in the systems I've
>worked on, having a flexible Time class (like DTime) has proven indispensable.

maybe I'm missing something, but I think that DTime is similar to
QuantLib::Date, while DAmountOfTime is similar to QuantLib:Time.
We could work on QuantLib::Date to make it more flexible and more similar
to DTime.

Am I missing something here?

looking forward to your QuEP

ciao -- Nando

[Luigi Ballabio-4]

Greetings everybody,

Note: rereading what I've written below, I realized I could sound a bit
harsh.  My intention was just to state a few facts and a few opinions of
mine (which probably shows a deep lack of PR skills to begin with :) , not
to throw them in anybody's face.

End of note.  On with the work.

>  At 7:59 PM -0800 12/26/01, Joel Nelson wrote:
>  Ferdinando Ametrano wrote
>  > 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

I, too, think that Nando has singled out exactly the classes we need.  I'm
inclined to keep the above and discard classes such as StateIdManager and
CurrencyBook which IMHO belong to an enclosing application layer rather
than to a library.  Also, I don't think that MoneyCalculator is needed
since unlike CORBA, C++ does have operator overloading among its features.

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

Also, I would point out that there are a number of guidelines and design
choices in QuantLib---albeit not fully exploited as yet---which pervade the
library and IMHO should be leveraged in the currency module even if it
meant to follow the specs a bit more in the spirit and a bit less in the
letter.

For instance, the conversion factor in an ExchangeRate instance is clearly
the kind of data which is best represented by a MarketElement---being the
more powerful for this.  Or again, rounding types could be implemented as
polymorphic strategies (as in "Strategy pattern") rather than an enum type.
But I'm digressing: I'm including a number of such remarks at the end of
the email.

My point is: the specification is clearly written with CORBA in mind, which
is good for the specification itself and the application layer but 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.

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

I think we have a naming problem here. Let me try to straighten things out.

QuantLib::Date is the class which could be made to conform to the
OMG::DTime interface.  All the functionalities are already there, the only
difference being that Date doesn't contain hour, minute and second
information.  For the reasons I stated above, I would rather wrap Date in
an adapter class to make it fully conformant---our guidelines prefer
d.month() to d.getMonth(), and I repute (d1-d2) more concise and more
expressive than d1.difference(d2).

QuantLib::Period is the best kept secret in QuantLib and expresses the
concept of a length of time such as "2 weeks", "3 days", "6 months", or "10
years".  It lacks hours, minutes, and seconds.  This class is the one which
can be modeled after OMG::DAmountOfTime.

QuantLib::Time is a typedef to double and we want it that way.  It is the
concept of "time" as used in differential equations and such.  It's the
physics thing if you like.  We need it for finite differences models, Monte
Carlo models, you name it.  And yes, it is unfortunate that it is named
just like the OMG "date" thing.




And now, my detailed considerations on the OMG specification.  Please
fasten your seatbelt.  I'll be referring to Appendix A of the specs,
"Consolidated IDL specifications".

A general consideration first: I would remove "get" from all getters
names, according to the QuantLib guidelines.

A.1:

ConversionType:
we can keep it as an enum.

RoundingType:
I'd rather have an abstract base class with a purely virtual method
round(amount) which will be implemented by derived classes. This would
also allow to use the same logic elsewhere.

Currency: see A2.

Money: see A2.

ExchangeRate:
1) I would keep the currencies themselves inside the class rather than
their mnemonics---the cost of carrying a Handle should be less than the
cost of carrying a std::string, too.
2) I would store the conversion factor as a MarketElement.
3) I would remove all setters.  In my opinion, changing a currency to an
existing exchange rate is much more confusing than actually useful.  Also,
the change of the conversion factor is managed through the MarketElement.

StateIdManager:
application layer.  Not really needed in the library, I think.

CurrencyBook:
application layer.  Not really needed in the library, also because we'll be
carrying around currency objects rather than mnemonics.

MoneyCalculator:
we can use operator overloading on class Money instead.  Informations such
as rounding type can be extracted by the money currency (I think rounding
rules for, e.g., Euro are determined, are they not?)  The base currency can
be kept as a static member of Money.  The same applies to the conversion
type.

MoneyFormatter:
we can keep it along with the other data formatters in the library.
However,
1) I would drop the pattern thing: if we use decimal notation for
fractions, the only information we really need is whether the currency
symbol is placed before or after the number, and this can be extracted from
the currency of the money we are formatting.
2) I would drop the parsing.  Doing it well would require a regex library.
Moreover, it belongs more to the application layer, not to the library.
3) I would remove setters and just give it a static toString(Money,...)
method which would be passed any needed argument.

ExchangeRateManager:
we can keep it.  Also, we could implement it so that adding an exchange
rate between two currencies automatically adds its reciprocal.

A.2:

Currency:
1) I would remove all setters.  It doesn't make sense to be able to, e.g.,
change the british pound symbol.  Once it is created, a currency should
stay constant.  Moreover, an interface reduced to couples of getters and
setters has no encapsulation at all---we might as well define Currency as a
struct with public data members.
2) To reduce the cost of carrying and copying around Currency objects, I
would use the pimpl idiom and store the data not in the Currency itself,
but in a CurrencyData struct instead.  The Currency class would contain a
pointer to a CurrencyData instance, thus making it a lot lighter to copy.
This would also allow to use the Singleton pattern for the CurrencyData
referring to a specific 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.

Money:
1) the currency would be stored as a Currency object and not its mnemonic.
2) I would remove all setters.  I would consider Money as a data type such
as double, int, or Date.  A variable of a data type is not changed but
rather reassigned.  Also, resetting value and currency independently
doesn't make sense.  An exchange rate should be explicitly used for
changing currency, not a bare m.setCurrency(newCurr).
3) Operator overloading would be used for arithmetic and logic.
m1.currency() == m2.currency() seems to me better C++ style than
m1.isOfSameCurrency(m2).

ExchangeRateDateBased:
I have to think about this.  One possiblity 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.

Factories:
mostly application layer.  Also, they are probably needed for CORBA, but
they don't add anything that isn't already in the constructor of the
corresponding class.

A.3:

Decimal:
I'm still trying to understand the usefulness of this.  This would be
hidden into Money anyway, so a combination of a double and a rounder object
would give all the needed functionality.  But I'm wide open to suggestions:
maybe I'm not seeing the obvious here.  Also, the double and the rounder
can be easily composed to yield this class anyway.

AmountOfTime:
QuantLib::Period can be morphed into this.  However, I would consider it a
data type and remove setters.

Time:
we could keep QuantLib::Date as we know and love it besides adding hour,
minute and seconds informations.  Wrapping it would be straightforward,
were OMG compliance needed.

Factories: see above.



Joel, it's your call. If you want to write the QuEP yourself, you're welcome.
If you want to work together on it, I'm available (we would have to find a
way to work together, though).


Bye for now (man, was this long)
                                      Luigi

--

[Joel Nelson-3]

hi Luigi.  thanks for responding.

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.

 >>  One class I think we should consider redesigning is the class you
 >>  mentioned below : Time...
 > I think we have a naming problem here. Let me try to straighten
 > things  out.
 >
 > QuantLib::Date is the class which could be made to conform to the
 > OMG::DTime interface.  All the functionalities are already there, the
 > only difference being that Date doesn't contain hour, minute and
 > second information.  For the reasons I stated above, I would rather wrap
 > Date in an adapter class to make it fully conformant---our guidelines
prefer
 > d.month() to d.getMonth(), and I repute (d1-d2) more concise and more
 > expressive than d1.difference(d2).
 >

Uh, sorry about my mistake.  i confused "time" with "date-time" and
missed the point of nando's mail.  it only took one look at the
documentation and examples to clear it up.

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.

 > QuantLib::Period is the best kept secret in QuantLib and expresses the
 > concept of a length of time such as "2 weeks", "3 days", "6 months",
or "10
 > years".  It lacks hours, minutes, and seconds.  This class is the one
which
 > can be modeled after OMG::DAmountOfTime.
 >

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.

 >
 >
 > And now, my detailed considerations on the OMG specification.  Please
 > fasten your seatbelt.  I'll be referring to Appendix A of the specs,
 > "Consolidated IDL specifications".
 >
 > A general consideration first: I would remove "get" from all getters
 > names, according to the QuantLib guidelines.

I come from a Java background so I generally leave the "get" in there
(kickback from java beans), but otherwise i don't really care.

 >
 > A.1:
 >
 > ConversionType:
 > we can keep it as an enum.

agreed.

 >
 > RoundingType:
 > I'd rather have an abstract base class with a purely virtual method
 > round(amount) which will be implemented by derived classes. This would
 > also allow to use the same logic elsewhere.

Good idea.

 >
 > Currency: see A2.
 >
 > Money: see A2.
 >
 > ExchangeRate:
 > 1) I would keep the currencies themselves inside the class rather than
 > their mnemonics---the cost of carrying a Handle should be less than the
 > cost of carrying a std::string, too.

i agree.  this is a corba kickback that we don't need.

 > 2) I would store the conversion factor as a MarketElement.

i need to take a look at the MarketElement class. I will get back to you
on this one.

 > 3) I would remove all setters.  In my opinion, changing a currency to an
 > existing exchange rate is much more confusing than actually useful.
Also,
 > the change of the conversion factor is managed through the MarketElement.
 >

same as above.

 > StateIdManager:
 > application layer.  Not really needed in the library, I think.
 >

not needed - i agree.

 > CurrencyBook:
 > application layer.  Not really needed in the library, also because
we'll be
 > carrying around currency objects rather than mnemonics.

 >
 > MoneyCalculator:
 > we can use operator overloading on class Money instead.  Informations
such
 > as rounding type can be extracted by the money currency (I think rounding
 > rules for, e.g., Euro are determined, are they not?)  The base
currency can
 > be kept as a static member of Money.  The same applies to the conversion
 > type.

i think it might be useful to keep the CurrencyBook.  besides holding a
single collection of the currencies created it also contains the
BaseCurrency.  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.  Without
the BaseCurrency it doesn't serve much of a purpose.

Let's discuss some more about this one.

 >
 > MoneyFormatter:
 > we can keep it along with the other data formatters in the library.
 > However,
 > 1) I would drop the pattern thing: if we use decimal notation for
 > fractions, the only information we really need is whether the currency
 > symbol is placed before or after the number, and this can be
extracted from
 > the currency of the money we are formatting.
 > 2) I would drop the parsing.  Doing it well would require a regex
library.
 > Moreover, it belongs more to the application layer, not to the library.
 > 3) I would remove setters and just give it a static toString(Money,...)
 > method which would be passed any needed argument.

i tend to like the pattern/parser but I agree that it is more
application layer anyway.  i will come back to this one when I've taken
a look at the current QuantLib formatters.

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

 >
 > A.2:
 >
 > Currency:
 > 1) I would remove all setters.  It doesn't make sense to be able to,
e.g.,
 > change the british pound symbol.  Once it is created, a currency should
 > stay constant.  Moreover, an interface reduced to couples of getters and
 > setters has no encapsulation at all---we might as well define
Currency as a
 > struct with public data members
 > 2) To reduce the cost of carrying and copying around Currency objects, I
 > would use the pimpl idiom and store the data not in the Currency itself,
 > but in a CurrencyData struct instead.  The Currency class would contain a
 > pointer to a CurrencyData instance, thus making it a lot lighter to copy.
 > This would also allow to use the Singleton pattern for the CurrencyData
 > referring to a specific currency.

cool.

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

 > Money:
 > 1) the currency would be stored as a Currency object and not its
mnemonic.

Makes sense.

 > 2) I would remove all setters.  I would consider Money as a data type
such
 > as double, int, or Date.  A variable of a data type is not changed but
 > rather reassigned.  Also, resetting value and currency independently
 > doesn't make sense.  An exchange rate should be explicitly used for
 > changing currency, not a bare m.setCurrency(newCurr).

I agree.

 > 3) Operator overloading would be used for arithmetic and logic.
 > m1.currency() == m2.currency() seems to me better C++ style than
 > m1.isOfSameCurrency(m2).

My background (Java) usually leads me away from operator overloading,
but it is more clear and concise.  I like it.

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

fyi. when we designed from this spec in the past we used the
ExchangeRate only for the EUR member currencies rates against the euro
the rest wrwere of a type similar to ExchangeRateDateBased.

 >
 > Factories:
 > mostly application layer.  Also, they are probably needed for CORBA, but
 > they don't add anything that isn't already in the constructor of the
 > corresponding class

Application layer - I agree.

 >
 > A.3:
 >
 > Decimal:
 > I'm still trying to understand the usefulness of this.  This would be
 > hidden into Money anyway, so a combination of a double and a rounder
object
 > would give all the needed functionality.  But I'm wide open to
suggestions:
 > maybe I'm not seeing the obvious here.  Also, the double and the rounder
 > can be easily composed to yield this class anyway.
 >
 > 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.
 >
 > Time:
 > we could keep QuantLib::Date as we know and love it besides adding hour,
 > minute and seconds informations.  Wrapping it would be straightforward,
 > were OMG compliance needed.

i think we should go ahead and wrap it to include the time.  see my
comments on DTime above.

looking forward to your follow up,

joel

[Joel Nelson-4]

Ferdinando Ametrano wrote:
 > maybe I'm missing something, but I think that DTime is similar to
 > QuantLib::Date, while DAmountOfTime is similar to QuantLib:Time.
 > We could work on QuantLib::Date to make it more flexible and more
 > similar to DTime.
 >
 > Am I missing something here?

i was the one missing something:

i had the idea of "Date-Time" as in DTime in my head when i read that
QuantLib::Time was just a typedef of a double.  i went off on that and
missed your point entirely (the comparison with DAmountOfTime).

i also wasn't familiar with the existing code for treating Dates in
QuantLib.  I should have guessed that you already had something like
QuantLib:Date class.  On further inspection (uh, one glance at the docs)
I realize I had spoken out of turn.

since then i've taken a closer look at the QuantLib::Date class.  it has
all the implementation needed to deal with dates up to the day.  In my
experience, that is all the precision we need to deal with currencies.
However...(I will expand on this in my reply to Luigi.)

anyway, sorry for the confusion.

joel

[Luigi Ballabio-4]

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

[Joel Nelson-3]

this is just a quick reply to your latest comments.

as you have done, i have omitted anything that we've agreed on.  it will
all resurface in the QuEP anyway.

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

i have another mail i've typed up with some ideas on the DateTime class.
 i may send it out tomorrow (still playing around with some ideas).  to
give you a quick preview: i think it might be good to create a DateTime
abstract class and then let the DateTime wrapper be just one
implementation of DateTime.  the reason being that the current Date
class is clearly based on an internal representation in the form of an
Excel serial number.  This seems to work fine for everyone using
QuantLib::Date so far.  It even works for DateTime because it turns out
that Excel can represent HH:MM:SS after the decimal in the serial
number.  However, as it points out in the source code, this
implementation also shares some bugs with Excel to purposely make it
100% compatible. It is very conceivable that someone will want to come
along and implement "date-time" in a way that has nothing to do with
Excel.  Anyway, I will expand on this in the other mail to which i keep
eluding.

if we did go down that track, wouldn't that be a fit for using the Pimpl
idiom that i see you using with the Calendar classes?

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

i totally agree.  i was just getting a little carried away once i got
the point your made.  but i do think we should include some kind of
"init static rates" function for the benefit of the euro currencies.

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

exactly.  since you brought it to my attention, i have been taking a
look at the MarketElement class.  it seems that most of the added power
comes from the observer pattern you've used and the different subclasses
that can set up complex/interdependent MarketElements.  like you said,
the MarketElement is obviously meant to be dynamic, whereas the
ExchangeRateDateBased is historic and immutable.  

still i wonder if there still isn't a scope for adding start/end dates
to the dynamic ExchangeRate.  for example, as the exchange rate changes,
at certain intervals, the ExchangeRate can be stored for conversion at
some time in the future.  then again, maybe this could be up to some
client code watching for changes in the ExchangeRate.

these are just ideas.  the more i think about it, the less i think we
should add to the dynamic ExchangeRate.  With the flexibility of the
MarketElement, it should
 be straightforward for the client to set up it's own exchange rate
"logging".  we could always add this kind of gravy later.  what do you
think?

later on,

joel

[Luigi Ballabio-4]

Joel,
         you've been reading my mind. The two points that I quote below are
two things I've been thinking about lately. My quick followups:

At 12:45 AM 1/3/02 -0800, Joel Nelson wrote:
>the current Date class is clearly based on an internal representation in
>the form of an Excel serial number.  This seems to work fine for everyone
>using QuantLib::Date so far.  It even works for DateTime because it turns
>out that Excel can represent HH:MM:SS after the decimal in the serial
>number.  However, as it points out in the source code, this implementation
>also shares some bugs with Excel to purposely make it 100% compatible. It
>is very conceivable that someone will want to come along and implement
>"date-time" in a way that has nothing to do with Excel.

This has bugged me since a colleague of mine did a bit of profiling of our
application and found that a whole lot of time was spent into the
Calendar::isBusinessDay method. This is probably due to the fact that our
Date class contain a serial number, while the calendar rules are of course
expressed in terms of weekday, day of month and month---which causes the
latter to be recalculated each time isBusinessDay() is called.
I've been thinking of a few ideas for gaining a bit of speed which are not
quite clear enough to be put into QuEPs, such as adding memoization to the
Calendar implementations. One of these was to get away with the serial
number and store the actual day, month, year data. This would put a bit of
load on whoever passed or wanted serial numbers, but what the hey, if you
want to use a library from a spreadsheet you are already converting data
types and you can't expect all that speed. I guess I'll get a better grasp
of the issue when we discuss DateTime...

>i wonder if there still isn't a scope for adding start/end dates to the
>dynamic ExchangeRate.  for example, as the exchange rate changes, at
>certain intervals, the ExchangeRate can be stored for conversion at some
>time in the future.  then again, maybe this could be up to some client
>code watching for changes in the ExchangeRate.
>
>these are just ideas.  the more i think about it, the less i think we
>should add to the dynamic ExchangeRate.  With the flexibility of the
>MarketElement, it should
>be straightforward for the client to set up it's own exchange rate
>"logging".  we could always add this kind of gravy later.  what do you think?

Well, out of curiosity, I just implemented a Python class (using the
QuantLib-Python module) which logs to a file the times at which a
MarketElement changes and the values it gets. It took no more than 15
minutes and 20 lines of code. It shouldn't be any more difficult to do it
in C++, or to make it so that instead of logging to a file it creates an
ExchangeRateDateBased instance and adds it to ExchangeRateManager.

Later,
         Luigi

[Ferdinando M. Ametrano-2]

Hi all

I'm catching up with the currency QuEP thread. Great work guys!

Luigi wrote:
>If Nando gives you developer status (hint, hint), we can work on the QuEP
>over CVS.
I did that 3 weeks ago. Wasn't I smart? ;-)

Luigi:
>the specification is clearly written with CORBA in mind [...]
>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.

And Joel:
>the value of the OMG design comes from its completeness: [...] 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.
So much that I remember a crazy discussion with Luigi and Enrico about a
QuantLib-CORBA experiment aimed at exposing the whole QuantLib C++ to CORBA.
While that experiment would be really crazy I think that we can set up a
QuantLib-CORBA repository. To have a QuantLib based CORBA layer that
implements the full currency module and maybe also an experimental
TermStructure interface would be a GREAT achievement, something that would
really boost our project.

Looking for volunteers .... ;-)

ciao -- Nando

[Luigi Ballabio-4]

At 04:03 PM 1/3/02 +0100, Ferdinando Ametrano wrote:
>>If Nando gives you developer status (hint, hint), we can work on the QuEP
>>over CVS.
>I did that 3 weeks ago. Wasn't I smart? ;-)

I'm impressed. Did you borrow Guido van Rossum's time machine?

Bye,
         Luigi

[Joel Nelson-3]

> So much that I remember a crazy discussion with Luigi and Enrico about
> a QuantLib-CORBA experiment aimed at exposing the whole QuantLib C++
> to CORBA.
> While that experiment would be really crazy I think that we can set up
> a QuantLib-CORBA repository. To have a QuantLib based CORBA layer that
> implements the full currency module and maybe also an experimental
> TermStructure interface would be a GREAT achievement, something that
> would really boost our project.


is there some demand out there for using QuantLib via CORBA?  i'm just
trying to get an idea of the general interest in this endeavor.
 personally i would be more interested to wrap with a SOAP interface at
the moment.  i have had bad luck using CORBA for anything outside of
in-house experimentation.  we never could get the clients to agree to
buy the ORB (the right version anyway) that we wanted them to use and
they didn't like TAO for some reason.

i have been in enough meetings at different banks indicating that SOAP
is the "strategic direction" in which they are heading for distributed
systems.  i have come away with the distinct impression that they are
trying to move away from CORBA.  i would be curious to know what
everyone else thinks.

i agree that wrapping all of QuantLib with some kind of SOAP or CORBA
interface would be a real boost to the project.  myself, for example, i
plan eventually to be using QuantLib from a java front end (either
application <-> servlet <-> quantlib or application <-> quantlib).
 either way it's a gain.  they both beat JNI for using C++ code from java.

ta,

joel