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? |
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
|
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 |
In reply to this post by Joseph Wang
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: |
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 |
In reply to this post by Joseph Wang
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: |
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. |
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 |
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
|
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
|
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
|
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
|
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
|
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 |
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 |
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.) |
Free forum by Nabble | Edit this page |