Re: currency quep intial - Re:currency quep

Posted by Joel Nelson-3 on Dec 31, 2001; 3:08am
URL: http://quantlib.414.s1.nabble.com/currency-quep-tp1814p1821.html

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