struct Call {
 enum Type {  cashPrice, cleanPrice };
};
struct Dividend {
 enum Type { dollarDividend, dividendYield };
};
 
Class ConvertibleBond: public Bond {
public:
 ConvertibleBond();  // default constructor
 ConvertibleBond(Real  conversionRatio, 
                 Real  volatility,
                 Real  conversionPrice,
                 Real  maturity,
                 Real  creditSpreadRates,
                 call::Type  callType,
                 Dividend::Type  dividendType,
                 const map<Size,Real>& dividendInfo,
                 const map<Size,Real>& callSchedule,
                 const vector<Real>& riskFreeRate
                 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
                 );  // constructor
   
 ConvertibleBond( const ConvertibleBond &original);  // copy constructor
 ConvertibleBond& operator=( const ConvertibleBond &original);  // assignment operator
 
 virtual ~ConvertibleBond();
 virtual Real conversionRatio() const;
 virtual Real volatility() const;
 virtual Real conversionPrice() const;
 virtual Real cvBondMaturity() const;
 virtual Real creditSpreadRates() const;
 virtual Real dividendInfo() const;
 virtual Real callSchedule() const;
 virtual Real riskFreeRate() const;
 virtual map<Size,Real>& dividendInfo() const;
 virtual map<Size,Real>& callSchedule() const;
private:
 Real conversionRatio_,volatility_, conversionPrice_,cvBondMaturity_,creditSpreadRates_;
 map <Size,Real> dividendInfo_, callSchedule_;
 call::Type  callType_;
        Dividend::Type  dividendType_;
 vector <Real> riskFreeRate_;
       
}; 
 
 

---

Nitpicking by Luigi follows:

struct Call {
 enum Type {  cashPrice, cleanPrice };
};

I'm not sure that 'Call' is the right name. Maybe something like:

struct Price {
  enum Type { Dirty, Clean };
};

might better express the intent. As for Dividend, the name is OK, but there's a bit of redundancy (as in Dividend::dividendYield.) I'd go for

struct Dividend {
 enum Type { Cash, Yield };
};

On to the convertible bond scaffolding:

 ConvertibleBond();  // default constructor

is not needed; adding it would impose to all methods and/or to client code to check that a given bond is in a usable state (a default-initialized bond wouldn't.) By removing it we ensure that any given convertible is properly initialized.

 ConvertibleBond( const ConvertibleBond &original);  // copy constructor
 ConvertibleBond& operator=( const ConvertibleBond &original);  // assignment operator

are not needed either; the compiler is perfectly capable of generating and maintaining them on its own, whereas hand-writing them introduces maintenance problems (one must remember to update them if a data member is added or removed; the compiler wouldn't complain.)

Finally:

 ConvertibleBond(Real  conversionRatio, 
                 Real  volatility,
                 Real  conversionPrice,
                 Real  maturity,
                 Real  creditSpreadRates,
                 call::Type  callType,
                 Dividend::Type  dividendType,
                 const map<Size,Real>& dividendInfo,
                 const map<Size,Real>& callSchedule,
                 const vector<Real>& riskFreeRate,
                 ... (bond parameters)

Some comments in random order:

a) a number of typedefs exist beside Real that help express one's intent, such as Time, Volatility, Rate, Spread... they should be used to clarify the real-world type of variables, even though they're all doubles. The same apply to the return types of the corresponding methods.

b) aren't conversionRatio and conversionPrice redundant? Or is conversionPrice the current underlying price, in which case it should be renamed?

c) if map<Size,Real> is meant to be used as, e.g., callSchedule[i], wouldn't a vector be better suited?

d) isn't 'Real maturity' (which I guess should be 'Time maturity') already given by bondMaturityDate further down? If different, it should be passed as a Date instance anyway.

e) if the method allows it, we might want to have a puttability schedule as well as a callability one.

f) there are higher-level concept that could be used instead of low-level ones; for instance,

const vector<Real>& riskFreeRate

should be passed more generally as

const Handle<YieldTermStructure>& riskFreeRate

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.

End of nitpicking.

---

The purpose of this mini-project is to add functionality into QuantLib to evaluate the value of convertible bonds. My goal in doing this is to evaluate the effect of interest rates on convertible bonds which are near the money (which is the case with most Chinese convertible bonds) and to calculate implicit credit risk for Chinese companies trading convertible bonds on the Shanghai bond exchange.

The basis for this project is the paper by Tsiveriotis and Fernadanes (the TF model) published in the Journal of Fixed Income p. 95 9/1998.

The heart of the model involves evaluating two coupled PDE's

u_t + sigma^2 s^2/2 u_ss + r_g s u_s + r(u-v) - (r+r_c) v + f(t) = 0

and

v_t + sigma^2 s^2/2 v_ss + r_g s v_s - (r + r_c) v - f(t) = 0

where v is the value of a synthetic security that consists of the cash flows from the convertible bond.

The question is how does one put this into the finite differencing model in quantlib with maximum code re-use. The brute force method would be to create a completely new Evolver that fits into the FiniteDifferenceModel^? class. The big problem is that quantlib is right now designed for evaluating one PDE and not a system of PDE's. So one question is how one would generalize the code to handle systems of coupled PDE's. Thoughts?

To do this one has to create FiniteDifferencePricingEngines

-- TWikiGuest - 03 Apr 2005 *******START

Currently looking for ConvertibleBondCalculators^?... Non-confirmed critizism agains the paper by Tsiveriotis and Fernadanes (the TF model) has been put forward by Ayache, E.P. Forsyth and K. Vetzal. (2003) "Valuation of Convertible Bonds with Credit Risk", Journal of Derivatives, 9-30. Unfortunately I d not have access to the paper so I can't confirm.

-- TWikiGuest - 03 Apr 2005 *******END

-- TWikiGuest - 03 Apr 2005 *******START Found it!!!

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

-- TWikiGuest - 03 Apr 2005 *******END