Generalizing FD engines

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Generalizing FD engines

Joseph Wang
I've been doing some refactoring of the FD engines to make it more
amenable to being used for things other than stocks.  Before I check
anything in, I wanted a bit of feedback on the basic idea.

What I've been doing is to

* change the class structure so that only the final concrete class
inherits from VanillaOption::engine and DividiendOption::engine.  This
means that the abstract classes are more usable for things which are not
vanilla
options.

* change the internals of some of the abstract classes so that they
reference a pointer to OneAssetOption rather than to vanilla option.

The next step that I have in mind is to generalize the finite
differencing classes in which dividends are involved.  Right now they
take as an argument a pointer to DividendVanillaOption::argument.

What I have in mind is to change DividendVanillaOption::argument so that
ir multiply inheirits from VanillaOption::argument and a new class
called DividendSchedule.  The abstract classes for the fd pricing
engines will then take an argument of pointer OneAssetOption::argument
and another argument of a pointer to DividendSchedule.  This will let
the code be usable for things other than Vanilla options (for example,
it means that the code will be usable for convertible bonds on dividend
paying stocks).

DividendSchedule will then be changed into a class that inherits from a
class called PayoutSchedule.  PayoutSchedule will inheirit from the
abstract class Schedule.

Thoughts?


Reply | Threaded
Open this post in threaded view
|

Re: Generalizing FD engines

Ashish Kulkarni-6
Joseph Wang wrote:
> DividendSchedule will then be changed into a class that inherits from a 
> class called PayoutSchedule.  PayoutSchedule will inheirit from the 
> abstract class Schedule.
> 

There is already a concrete class called "Schedule" in QuantLib, which 
generates a schedule from a given spec or directly from given dates. I 
would suggest that DividendSchedule be defined as

DividendSchedule = std::pair >

or something similiar.

Regards,
Ashish

3i Infotech

Greetings!

ICICI Infotech is now 3i Infotech.

The e-mail addresses of the company's employees have been changed to <existing name>@3i-infotech.com. You are requested to take note of this new e-mail ID and make use of the same in future

"This e-mail message may contain confidential, proprietary or legally privileged information. It should not be used by anyone who is not the original intended recipient. If you have erroneously received this message, please delete it immediately and notify the sender. The recipient acknowledges that 3i Infotech or its subsidiaries and associated companies, (collectively "3i Infotech"), are unable to exercise control or ensure or guarantee the integrity of/over the contents of the information contained in e-mail transmissions and further acknowledges that any views expressed in this message are those of the individual sender and no binding nature of the message shall be implied or assumed unless the sender does so expressly with due authority of 3i Infotech. Before opening any attachments please check them for viruses and defects."

Reply | Threaded
Open this post in threaded view
|

Re: Generalizing FD engines

Luigi Ballabio-2
In reply to this post by Joseph Wang
On 04/05/05 05:21:25, Joseph Wang wrote:
> I've been doing some refactoring of the FD engines to make it more  
> amenable to being used for things other than stocks.  Before I check  
> anything in, I wanted a bit of feedback on the basic idea.

Joseph,
        apologies for the delay. Here we go:

> * change the class structure so that only the final concrete class  
> inherits from VanillaOption::engine and DividiendOption::engine.  This  
> means that the abstract classes are more usable for things which are not  
> vanilla options.

Ok.

> * change the internals of some of the abstract classes so that they  
> reference a pointer to OneAssetOption rather than to vanilla option.

Ok.

> The next step that I have in mind is to generalize the finite  
> differencing classes in which dividends are involved.  Right now they  
> take as an argument a pointer to DividendVanillaOption::argument.
>
> What I have in mind is to change DividendVanillaOption::argument so that  
> ir multiply inheirits from VanillaOption::argument and a new class called  
> DividendSchedule.  The abstract classes for the fd pricing engines will  
> then take an argument of pointer OneAssetOption::argument and another  
> argument of a pointer to DividendSchedule.  This will let the code be  
> usable for things other than Vanilla options (for example, it means that  
> the code will be usable for convertible bonds on dividend paying stocks).

Ok in principle, but I'd go for containment instead of inheritance; I'd  
inherit DividendVanillaOption::argument from VanillaOption::argument and  
add a DividendSchedule data member. It shouldn't make more difficult to  
pass both OneAssetOption::arguments* and DividendSchedule* to the abstract  
classes.

> DividendSchedule will then be changed into a class that inherits from a  
> class called PayoutSchedule.  PayoutSchedule will inheirit from the  
> abstract class Schedule.

Same here: I'd rather have a class DividendSchedule containing a Schedule  
(which remains concrete,) plus information on the amount of the dividends.

Later,
        Luigi

----------------------------------------

All parts should go together without forcing.  You must remember that the
parts you are reassembling were disassembled by you.  Therefore, if you
can't get them together again, there must be a reason.  By all means, do
not use a hammer.
-- IBM maintenance manual, 1925



Reply | Threaded
Open this post in threaded view
|

RE: Generalizing FD engines

cuchulainn
In reply to this post by Joseph Wang
Re: [Quantlib-users] Generalizing FD engines
 
Luigi
I have an initial design pattern for FD stuff. Still under dev. but it's flexible and loosely coupled.
 
Daniel

 

From: [hidden email] on behalf of Luigi Ballabio
Sent: Thu 07/04/2005 17:34
To: Joseph Wang
Cc: [hidden email]
Subject: Re: [Quantlib-users] Generalizing FD engines


On 04/05/05 05:21:25, Joseph Wang wrote:
> I've been doing some refactoring of the FD engines to make it more 
> amenable to being used for things other than stocks.  Before I check 
> anything in, I wanted a bit of feedback on the basic idea.

Joseph,
        apologies for the delay. Here we go:

> * change the class structure so that only the final concrete class 
> inherits from VanillaOption::engine and DividiendOption::engine.  This 
> means that the abstract classes are more usable for things which are not 
> vanilla options.

Ok.

> * change the internals of some of the abstract classes so that they 
> reference a pointer to OneAssetOption rather than to vanilla option.

Ok.


> The next step that I have in mind is to generalize the finite 
> differencing classes in which dividends are involved.  Right now they 
> take as an argument a pointer to DividendVanillaOption::argument.
>
> What I have in mind is to change DividendVanillaOption::argument so that 
> ir multiply inheirits from VanillaOption::argument and a new class called 
> DividendSchedule.  The abstract classes for the fd pricing engines will 
> then take an argument of pointer OneAssetOption::argument and another 
> argument of a pointer to DividendSchedule.  This will let the code be 
> usable for things other than Vanilla options (for example, it means that 
> the code will be usable for convertible bonds on dividend paying stocks).

Ok in principle, but I'd go for containment instead of inheritance; I'd 
inherit DividendVanillaOption::argument from VanillaOption::argument and 
add a DividendSchedule data member. It shouldn't make more difficult to 
pass both OneAssetOption::arguments* and DividendSchedule* to the abstract 
classes.

> DividendSchedule will then be changed into a class that inherits from a 
> class called PayoutSchedule.  PayoutSchedule will inheirit from the 
> abstract class Schedule.

Same here: I'd rather have a class DividendSchedule containing a Schedule 
(which remains concrete,) plus information on the amount of the dividends.

Later,
        Luigi

----------------------------------------

All parts should go together without forcing.  You must remember that the
parts you are reassembling were disassembled by you.  Therefore, if you
can't get them together again, there must be a reason.  By all means, do
not use a hammer.
-- IBM maintenance manual, 1925



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Quantlib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

Reply | Threaded
Open this post in threaded view
|

Re: Generalizing FD engines

Luigi Ballabio
On Apr 13, 2005, at 6:57 PM, Daniel J. Duffy wrote:

> I have an initial design pattern for FD stuff. Still under dev. but
> it's flexible and loosely coupled.

Daniel,
        it would be welcome. Maybe you and Joseph can get in touch and discuss
possible developments?

Luigi



Reply | Threaded
Open this post in threaded view
|

RE: Generalizing FD engines

cuchulainn
In reply to this post by Joseph Wang
Re: [Quantlib-users] Generalizing FD engines
If Joseph can tell me the PDE and problem domain I will try to make a C++ pattern structure. For me, most time is taken with requirements (i.e. PDE description). Programming part is a bit easier.
 
Maybe Joe's convertible bond example, a good one to get one's teeth into.
 
 
Ciao, a presto
 
Daniel


From: Luigi Ballabio [mailto:[hidden email]]
Sent: Wed 13/04/2005 21:40
To: Daniel J. Duffy
Cc: Joseph Wang; <[hidden email]>
Subject: Re: [Quantlib-users] Generalizing FD engines


On Apr 13, 2005, at 6:57 PM, Daniel J. Duffy wrote:

> I have an initial design pattern for FD stuff. Still under dev. but
> it's flexible and loosely coupled.

Daniel,
        it would be welcome. Maybe you and Joseph can get in touch and discuss
possible developments?

Luigi

Reply | Threaded
Open this post in threaded view
|

Re: Generalizing FD engines

Joseph Wang
Sorry for disappearing.  I've been busy some other projects.

Anyway.....

Daniel J. Duffy wrote:

> If Joseph can tell me the PDE and problem domain I will try to make a
> C++ pattern structure. For me, most time is taken with requirements
> (i.e. PDE description). Programming part is a bit easier.

Sure.  There is one model that is basically just Black-Scholes with
extra terms.  More complex models use two equations that separate things
into a bond component and a stock component.  The equations for are
described in ....

http://www.scicom.uwaterloo.ca/~paforsyt/convert.pdf

also notes on the CB project are at

http://wiki.quantlib.org/twiki/bin/view/Quantlib/ConvertibleBonds

To go off on a different topic related to what I've been working on in
the last week.....

One interesting thing about PRC stock markets is that they make perfect
sense if you don't think of them as efficient allocators of capital.  
Rather think of it as something more akin to the state lotteries that
some governments use to fund social welfare programs in the absence of
tax revenue.  The Shanghai Stock Exchange really is a casino whose
proceeds are used to fund unemployment benefits for state-owned enterprises.



Reply | Threaded
Open this post in threaded view
|

Re: Generalizing FD engines

Theo Boafo
Hi Joe,
 
Can you please update the convertible bond class with the corrections I made based on Luigi's comments.
I have not had a chance to familiarise with the Quantlib environment in terms of updating the site.
 
Please find attachments.
 
Regards
 
Theo
 
 

convertible_bond.txt (2K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: Generalizing FD engines

cuchulainn
In reply to this post by Joseph Wang
Had a quick look at the interface of ConvertibleBond . The constriuctor has 20 input parameters! Wow!
 
IMHO I think that this class cabn be better refactored into mor loosely coupled an specialised classes. At the moment the class is a White Box and is dificult to maintain I reckon.
 
Daniel
 


From: [hidden email] [mailto:[hidden email]]
Sent: Thu 14/04/2005 10:23
To: [hidden email]; Daniel J. Duffy
Cc: [hidden email]; [hidden email]
Subject: Re: [Quantlib-users] Generalizing FD engines

Hi Joe,
 
Can you please update the convertible bond class with the corrections I made based on Luigi's comments.
I have not had a chance to familiarise with the Quantlib environment in terms of updating the site.
 
Please find attachments.
 
Regards
 
Theo
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Generalizing FD engines

Theo Boafo
I am looking into reducing the number of parameters but I need to get my head round the const Handle<StochasticProcess>& process
 
Luigi's original comments on this matter were as follows:
 
 Also, the set of parameters
Real  volatility,
Dividend::Type  dividendType,
const map<Size,Real>& dividendInfo,
const vector<Real>& riskFreeRate,
(as well as the current stock price) might be grouped as
const Handle<StochasticProcess>& process,
provided that we define a class similar to BlackScholesProcess? but with discrete dividends.
 
If we define a class with discrete dividends similar to the BlackScholes Process then we could reduce the input parameters to 15 or 16.
 
Any suggestions on other parmeters that can be grouped.
 
Regards
 
Theo
 
 
-----Original Message-----
From: Daniel J. Duffy <[hidden email]>
To: [hidden email]; [hidden email]
Cc: [hidden email]; [hidden email]
Sent: Thu, 14 Apr 2005 10:58:05 +0200
Subject: RE: [Quantlib-users] Generalizing FD engines

Had a quick look at the interface of ConvertibleBond . The constriuctor has 20 input parameters! Wow!
 
IMHO I think that this class cabn be better refactored into mor loosely coupled an specialised classes. At the moment the class is a White Box and is dificult to maintain I reckon.
 
Daniel
 


From: [hidden email] [mailto:[hidden email]]
Sent: Thu 14/04/2005 10:23
To: [hidden email]; Daniel J. Duffy
Cc: [hidden email]; [hidden email]
Subject: Re: [Quantlib-users] Generalizing FD engines

Hi Joe,
 
Can you please update the convertible bond class with the corrections I made based on Luigi's comments.
I have not had a chance to familiarise with the Quantlib environment in terms of updating the site.
 
Please find attachments.
 
Regards
 
Theo
 
 
Reply | Threaded
Open this post in threaded view
|

RE: Generalizing FD engines

cuchulainn
In reply to this post by Joseph Wang
Theo,
Are you working on this class? You could consider partitioning the problem into loosely coupled subsystems.
 
Daniel
 


From: [hidden email] [mailto:[hidden email]]
Sent: Thu 14/04/2005 15:51
To: Daniel J. Duffy; [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: [Quantlib-users] Generalizing FD engines

I am looking into reducing the number of parameters but I need to get my head round the const Handle<StochasticProcess>& process
 
Luigi's original comments on this matter were as follows:
 
 Also, the set of parameters
Real  volatility,
Dividend::Type  dividendType,
const map<Size,Real>& dividendInfo,
const vector<Real>& riskFreeRate,
(as well as the current stock price) might be grouped as
const Handle<StochasticProcess>& process,
provided that we define a class similar to BlackScholesProcess? but with discrete dividends.
 
If we define a class with discrete dividends similar to the BlackScholes Process then we could reduce the input parameters to 15 or 16.
 
Any suggestions on other parmeters that can be grouped.
 
Regards
 
Theo
 
 
-----Original Message-----
From: Daniel J. Duffy <[hidden email]>
To: [hidden email]; [hidden email]
Cc: [hidden email]; [hidden email]
Sent: Thu, 14 Apr 2005 10:58:05 +0200
Subject: RE: [Quantlib-users] Generalizing FD engines

Had a quick look at the interface of ConvertibleBond . The constriuctor has 20 input parameters! Wow!
 
IMHO I think that this class cabn be better refactored into mor loosely coupled an specialised classes. At the moment the class is a White Box and is dificult to maintain I reckon.
 
Daniel
 


From: [hidden email] [mailto:[hidden email]]
Sent: Thu 14/04/2005 10:23
To: [hidden email]; Daniel J. Duffy
Cc: [hidden email]; [hidden email]
Subject: Re: [Quantlib-users] Generalizing FD engines

Hi Joe,
 
Can you please update the convertible bond class with the corrections I made based on Luigi's comments.
I have not had a chance to familiarise with the Quantlib environment in terms of updating the site.
 
Please find attachments.
 
Regards
 
Theo
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Generalizing FD engines

Theo Boafo
Daniel,
 
Yes I am working on the class with Joe.
 
The initial plan is to have a class that meets all the criteria for a Convertible Bond and then implement a the binomial and trinomial pricing engine for it.  Joe is mainly looking at the FD approach.
 
Given that the Convertible Bond is a Hybrid Instrument made up of a bond and stock component.  Perhaps we could introduce a Hybrid Class to build other hybrid structures later on.
 
I am currently looking at the VanillaOption class to understand how that works in QuantLib so that I can group some of the input parameters to the Convertible Bond Class  such as
Real  volatility,
Dividend::Type  dividendType,
const map<Size,Real>& dividendInfo,
const vector<Real>& riskFreeRate,
(as well as the current stock price) into something like const Handle<StochasticProcess>& process, provided I can use or  define a class similar to BlackScholesProcess? but with discrete dividends.
 
Also we need to reuse any existing code or add to it and not re-invent the wheel
Given that the Convertible Bond class also inherits from Bond Class, I am forced to pass the Bond parameters via Convertible Bond to Bond Class.  If the Bond parameters were already grouped then that will also reduce the number of parameters as well.
 
So I am happy for suggestions and ideas.
 
 
Regards
 
Theo
 
 
-----Original Message-----
From: Daniel J. Duffy <[hidden email]>
To: [hidden email]; [hidden email]
Cc: [hidden email]; [hidden email]
Sent: Thu, 14 Apr 2005 17:21:14 +0200
Subject: RE: [Quantlib-users] Generalizing FD engines

Theo,
Are you working on this class? You could consider partitioning the problem into loosely coupled subsystems.
 
Daniel
 


From: [hidden email] [mailto:[hidden email]]
Sent: Thu 14/04/2005 15:51
To: Daniel J. Duffy; [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: [Quantlib-users] Generalizing FD engines

I am looking into reducing the number of parameters but I need to get my head round the const Handle<StochasticProcess>& process
 
Luigi's original comments on this matter were as follows:
 
 Also, the set of parameters
Real  volatility,
Dividend::Type  dividendType,
const map<Size,Real>& dividendInfo,
const vector<Real>& riskFreeRate,
(as well as the current stock price) might be grouped as
const Handle<StochasticProcess>& process,
provided that we define a class similar to BlackScholesProcess? but with discrete dividends.
 
If we define a class with discrete dividends similar to the BlackScholes Process then we could reduce the input parameters to 15 or 16.
 
Any suggestions on other parmeters that can be grouped.
 
Regards
 
Theo
 
 
-----Original Message-----
From: Daniel J. Duffy <[hidden email]>
To: [hidden email]; [hidden email]
Cc: [hidden email]; [hidden email]
Sent: Thu, 14 Apr 2005 10:58:05 +0200
Subject: RE: [Quantlib-users] Generalizing FD engines

Had a quick look at the interface of ConvertibleBond . The constriuctor has 20 input parameters! Wow!
 
IMHO I think that this class cabn be better refactored into mor loosely coupled an specialised classes. At the moment the class is a White Box and is dificult to maintain I reckon.
 
Daniel
 


From: [hidden email] [mailto:[hidden email]]
Sent: Thu 14/04/2005 10:23
To: [hidden email]; Daniel J. Duffy
Cc: [hidden email]; [hidden email]
Subject: Re: [Quantlib-users] Generalizing FD engines

Hi Joe,
 
Can you please update the convertible bond class with the corrections I made based on Luigi's comments.
I have not had a chance to familiarise with the Quantlib environment in terms of updating the site.
 
Please find attachments.
 
Regards
 
Theo
 
 
Reply | Threaded
Open this post in threaded view
|

RE: Generalizing FD engines

cuchulainn
In reply to this post by Joseph Wang
Theo,
That sounds great. I think indeed that grouping things in bigger classes is good. In general IMHO your objective should be to clusters, e.g.
 
An interface for everything about dividends
A mesh algorithm
Cirve objects
etc.
 
Having classes with 20 data members leads to problems.
 
Daniel
 


From: [hidden email] [mailto:[hidden email]]
Sent: Fri 15/04/2005 10:38
To: Daniel J. Duffy; [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: [Quantlib-users] Generalizing FD engines

Daniel,
 
Yes I am working on the class with Joe.
 
The initial plan is to have a class that meets all the criteria for a Convertible Bond and then implement a the binomial and trinomial pricing engine for it.  Joe is mainly looking at the FD approach.
 
Given that the Convertible Bond is a Hybrid Instrument made up of a bond and stock component.  Perhaps we could introduce a Hybrid Class to build other hybrid structures later on.
 
I am currently looking at the VanillaOption class to understand how that works in QuantLib so that I can group some of the input parameters to the Convertible Bond Class  such as
Real  volatility,
Dividend::Type  dividendType,
const map<Size,Real>& dividendInfo,
const vector<Real>& riskFreeRate,
(as well as the current stock price) into something like const Handle<StochasticProcess>& process, provided I can use or  define a class similar to BlackScholesProcess? but with discrete dividends.
 
Also we need to reuse any existing code or add to it and not re-invent the wheel
Given that the Convertible Bond class also inherits from Bond Class, I am forced to pass the Bond parameters via Convertible Bond to Bond Class.  If the Bond parameters were already grouped then that will also reduce the number of parameters as well.
 
So I am happy for suggestions and ideas.
 
 
Regards
 
Theo
 
 
-----Original Message-----
From: Daniel J. Duffy <[hidden email]>
To: [hidden email]; [hidden email]
Cc: [hidden email]; [hidden email]
Sent: Thu, 14 Apr 2005 17:21:14 +0200
Subject: RE: [Quantlib-users] Generalizing FD engines

Theo,
Are you working on this class? You could consider partitioning the problem into loosely coupled subsystems.
 
Daniel
 


From: [hidden email] [mailto:[hidden email]]
Sent: Thu 14/04/2005 15:51
To: Daniel J. Duffy; [hidden email]
Cc: [hidden email]; [hidden email]
Subject: Re: [Quantlib-users] Generalizing FD engines

I am looking into reducing the number of parameters but I need to get my head round the const Handle<StochasticProcess>& process
 
Luigi's original comments on this matter were as follows:
 
 Also, the set of parameters
Real  volatility,
Dividend::Type  dividendType,
const map<Size,Real>& dividendInfo,
const vector<Real>& riskFreeRate,
(as well as the current stock price) might be grouped as
const Handle<StochasticProcess>& process,
provided that we define a class similar to BlackScholesProcess? but with discrete dividends.
 
If we define a class with discrete dividends similar to the BlackScholes Process then we could reduce the input parameters to 15 or 16.
 
Any suggestions on other parmeters that can be grouped.
 
Regards
 
Theo
 
 
-----Original Message-----
From: Daniel J. Duffy <[hidden email]>
To: [hidden email]; [hidden email]
Cc: [hidden email]; [hidden email]
Sent: Thu, 14 Apr 2005 10:58:05 +0200
Subject: RE: [Quantlib-users] Generalizing FD engines

Had a quick look at the interface of ConvertibleBond . The constriuctor has 20 input parameters! Wow!
 
IMHO I think that this class cabn be better refactored into mor loosely coupled an specialised classes. At the moment the class is a White Box and is dificult to maintain I reckon.
 
Daniel
 


From: [hidden email] [mailto:[hidden email]]
Sent: Thu 14/04/2005 10:23
To: [hidden email]; Daniel J. Duffy
Cc: [hidden email]; [hidden email]
Subject: Re: [Quantlib-users] Generalizing FD engines

Hi Joe,
 
Can you please update the convertible bond class with the corrections I made based on Luigi's comments.
I have not had a chance to familiarise with the Quantlib environment in terms of updating the site.
 
Please find attachments.
 
Regards
 
Theo
 
 
Reply | Threaded
Open this post in threaded view
|

Re: Generalizing FD engines

Luigi Ballabio
In reply to this post by Theo Boafo
On 04/14/05 15:51:37, [hidden email] wrote:
> I am looking into reducing the number of parameters

Theo,
        I'm just throwing in some suggestions (i.e., don't take the  
following as the Chosen Interface.)
A first attempt might be:

class ConvertibleBond: public FixedCouponBond {
  public:
     ConvertibleBond(Real conversionRatio,
                     // underlying parameters
                     const boost::shared_ptr<StochasticProcess>& process,
                     const DividendSchedule& dividends,
                     // issuer parameters
                     const Handle<Quote>& creditSpread,
                     // callability
                     const CallabilitySchedule& callability,
                     // bond parameters
                     const Date& issueDate,
                     const Date& datedDate,
                     const Date& bondMaturityDate,
                     Integer settlementDays,
                     Rate coupon,
                     Frequency couponFrequency,
                     const DayCounter& dayCounter,
                     const Calendar& calendar,
                     BusinessDayConvention convention,
                     Real redemption = 100.0);
     // inspectors
     ...
  private:
     // data members---see above, except those already stored in base class
     ...
};

where we got down to 15; we might further group datedDate, maturityDate,  
couponFrequency and calendar into a single Schedule object and get down to  
12 if we made the corresponding change in FixedCouponBond (from which  
ConvertibleBond should inherit, rather than Bond.) Further reduction might  
be difficult, as the specification of a convertible bond does have a number  
of parameters---and not all of them can be grouped in a natural way  
("natural" as opposed to forcibly aggregate unrelated parameters into a  
Parameters struct which wouldn't correspond to a clear concept in the  
domain.)

The DividendSchedule class could be implemented in several ways. One  
possibility is:

struct Dividend {
     enum Type { Cash, Yield };
     Real amount;
     Type type;
     Date date;
};

typedef std::vector<Dividend> DividendSchedule;

Another is:

struct Dividend {
     enum Type { Cash, Yield };
     Real amount;
     Type type;
};

typedef std::vector<std::pair<Date,Dividend> > DividendSchedule;

Yet another uses the latter struct with:

typedef std::map<Date,Dividend> DividendSchedule;

And others might choose to encapsulate the container, in order to restrict  
access (the full vector or map interface might be too large):

class DividendSchedule {
   public:
     ...
     const Dividend& operator[](const Date&) const;
   private:
     std::map<Date,Dividend> schedule_;
};


The same applies to CallabilitySchedule, with some added fields; for  
instance,

struct Price {
     enum Type { Dirty, Clean };
     Real price;
     Type type;
};

struct Callability {
     enum Type { Call, Put };
     Price price;
     Type type;
     Date date;
};

typedef std::vector<Callability> CallabilitySchedule;

or again:

struct Callability {
     enum Type { Call, Put };
     Price price;
     Type type;
};

typedef std::vector<std::pair<Date,Callability> > CallabilitySchedule;

(using a map might not work, since there might be a callability and a  
puttability on the same date; a multimap would be required.)

Later,
        Luigi

----------------------------------------

I hate quotations.
-- Ralph Waldo Emerson



Reply | Threaded
Open this post in threaded view
|

Re: Generalizing FD engines

Luigi Ballabio
In reply to this post by Theo Boafo
Theo,
        I'll look at your changes. But I don't seem to be able to reach you  
directly at your AOL address---do you have any other address I can use  
without having to pass through the QuantLib list?

Thanks,
        Luigi

----------------------------------------

The economy depends about as much on economists as the weather does on
weather forecasters.
-- Jean-Paul Kauffmann



Reply | Threaded
Open this post in threaded view
|

Re: Generalizing FD engines

Joseph Wang
In reply to this post by Luigi Ballabio
Sorry for disappearing.   Got swamped with outside work....

What I can do over the weekend is to look at the discussion about
representing dividends and see if I can create a design for representing
them.  Also, I'll get started with the changes to the FD classes that I
suggested on the list about two weeks ago.  (That's the nice thing about
mailing lists, they remind you of what you were doing.)