Login  Register

RE: Policy-Based Design/Templates/Quantlib

Posted by Lou, Wujiang on Jul 14, 2003; 7:15am
URL: http://quantlib.414.s1.nabble.com/Policy-Based-Design-Templates-Quantlib-tp2601p2607.html

This kind of template design for pricer (see after ==>) is less preferred in a trading system because in cases where multiple models are available for the same instrument, the trading system typically allows users to configure their model choice and let them switch around. This dynamic behavior vs the static polymorphism nature of template is mind twisting.

But quantlib may have other concerns that led to its current pricer design.

-Lou, Wujiang

-Zurich Capital Markets

 

==>

Or more relevant to quantlib:

Can someone elaborate on why SwaptionPricer is templated:

 

template<class ModelType>

        class SwaptionPricer : public PricingEngine,

                               public Patterns::Observer,

                               public Patterns::Observable

-----Original Message-----
From: Nehal Patel [mailto:[hidden email]]
Sent: Friday, July 11, 2003 11:20 AM
To: '[hidden email]'
Subject: [Quantlib-users] Policy-Based Design/Templates/Quantlib

Hi,

            I'm trying to get my head around using policy based design in C++ using templates; it seems that quantlib uses this approach a lot.  My basic question involves trying to figure out under what circumstances templates should be utilized in certain design features (with regard to policy based design - not so much with regards to generic container classes etc.)  As an example, imagine I was going to create a Bond class; I might do it as follows:

 

class Bond : public Security {

protected:

            PrinicipalSchedule principalSchedule;

            CouponSchedule couponSchedule;

            TerminationProvision terminationProvision;

            DefaultGuarantee defaultProvision;

      public: 

      //various useful methods go here

}

 

The basic idea is to abstract away certain things to provide enough flexibility to deal with issues like callabillity, amortizations,  bizarre payment dates, whatever.  Of course classes like TerminationProvision would have to be carefully crafted in order to handle the wide variety in which bonds can cease to exist.  This class would be used by various pricing engine objects to perform calculations.  But in any case I would think that my approach is more or less what someone with a Java background would attempt - with the understanding that occasionally some situations might require using 'instanceof'.

 

My question then is: in c++ is the above approach optimal or is there some more powerful paradigm that would utilize templated classes?

 

Or more relevant to quantlib:

Can someone elaborate on why SwaptionPricer is templated:

 

template<class ModelType>

        class SwaptionPricer : public PricingEngine,

                               public Patterns::Observer,

                               public Patterns::Observable

 

 

as opposed to something like

 

class SwaptionPricer : public PricingEngine,

                  public Patterns::Observer,

                  public Patterns::Observable  {

 

      Handle<SwaptionModel> model_;

 

}

 

class SwaptionModel {

            SwaptionResults calcSwaption(SwaptionParameters parameters);

}

 

 

Thanks,

Nehal



This email and any attachments are confidential and may be

legally privileged. No confidentiality or privilege is waived

or lost by any transmission in error. If you are not the

intended recipient you are hereby notified that any use,

printing, copying or disclosure is strictly prohibited.

Please delete this email and any attachments, without

printing, copying, forwarding or saving them and notify the

sender immediately by reply e-mail. Zurich Capital Markets

and its affiliates reserve the right to monitor all e-mail

communications through its networks. Unless otherwise

stated, any pricing information in this e-mail is indicative

only, is subject to change and does not constitute an offer

to enter into any transaction at such price and any terms in

relation to any proposed transaction are indicative only and

subject to express final confirmation.