Re: convertible bond class and finite differencing

[Joseph Wang]

[hidden email] wrote:

> Hi luigi,
>  
> Many thanks for your comments.  Perhaps BondParams is not a good name
> but all these parameters or inputs are required for calculating PV for
> most fixed income instruments e.g. swaps and bonds.

Maybe we ought to have Bond inherit something else.  
FixedIncomeSecurity?  One problem with the Bond class is that there
seems to be a lot of calculation in there which seems to go against the
framework of separating pricing from the instruments.

>  
> How about this?
>  
>  
> We could have them in a struct say
>  
> struct  CashFlowSchedule{
>       public:
>              const Date& issueDate,
>              const Date& datedDate,
>              const Date& MaturityDate,
>              Integer settlementDays,
>              Rate coupon,
>              Frequency couponFrequency,
>              const DayCounter& couponFrequency,
>              const Calendar& calendar,
>              BusinessDayConvention convention,
>              Real redemption)
> }
>  
>  
> We may have to rewrite fixedcoupon bond to use this struct.
>  
>  
> Struct Price{
>     enum Type { Dirty, Clean};
>     Real price;
>     Type type;
> };
>  
> Struct Callability{
>     enum Type { Call, Put};
>     Price price;
>     Type type;
>     Date date;
> };
>  
> typedef vector<Callability> CallabilitySchedule;
>  
> Struct Dividend{
>     enum Type { Cash, Yield};
>     Real amount;
>     Type type;
>     Date date;
> };
>  
> typedef vector<Dividend> DividendSchedule;
>  
> Class ConvertibleBond: public FixedCouponBond {
> public:
>  ConvertibleBond(
>                   const boost::shared_ptr<stochasticProcess>& stochProc,
>                   Real  conversionRatio,  
>                   const DividendSchedule&  dividends,
>                   const CallabilitySchedule& callability,
>                   const Handle<Quote>& creditSpread,
>                   const CashFlowSchedule& cashflow,
>                  );  // constructor
>  virtual ~ConvertibleBond();
>  Real conversionRatio() const;
>  DividendSchedule dividends() const;
>  CallabilitySchedule callability() const;
>  Handle<Quote>& creditSpread() const;
> private:
>      Real conversionRatio_;
>      Spread creditSpreadRates_;
>      CallabilitySchedule callability_;
>      DividendSchedule dividends_;
>      Handle<Quote> creditSpread_;
> };  
>  
> Lets have some feedback on this?
>  
>  

I think you are on the right track, but a convertible bond doesn't
necessarily have to be a fixed coupon bond.  My inclination is to have
convertible bond use aggregation rather than inheritance.  The class
structure would be exactly like the one you had before, except that it
would have Bond as a member rather than a superclass.

I'd like to get something checked into the tree in the next week or so.  
We don't have to have all of the elements of a convertible bond ready,
but I think we are close enough to a structure that we can start working
off of.

FYI, I've been doing some work on the finite difference pricing engines
to make them less dependent on vanilla options.  A lot of the work is
replacing subclassing with aggregation so that the engines will
eventually work with the convertible bond class.





> Regards
>  
> Theo

[Theo Boafo]

Hi Joe,

 

Thanks for your comments, I think Luigi should comment also.  The reason why I have made the convertible bond class inherit from fixedcoupon bond is so that the bond parameters being passed via the convertible bond constructor can be passed to both  fixedcoupon bond and bond class so that one can use some of the existing methods for bond calculations.

 

Rather than inheritance we could use aggregation but Luigi's earlier comments suggested that maintenance could be difficult.

 

If we can finally agree on the structure then I can proceed.

 

On a different note I am trying to build and install boost libary on a new lap top and I am not sure its working as I am getting the following messages.

 

C:\temp\boost_1_32_0>bjam "-sTOOLS=vc-7_1" install
---------------------------------------------------------------------
skipping Boost.Python library build due to missing or incorrect configuration

 

couldn't find Python.h in "c:/tools/python/include"

 

You can configure the location of your python installation by setting:
PYTHON_ROOT    - currently "c:/tools/python"
PYTHON_VERSION - The 2-part python Major.Minor version number (e.g.
                 "2.2", NOT "2.2.1")  - currently "2.2"

 

The following are automatically configured from PYTHON_ROOT if not
otherwise set:

 

    PYTHON_LIB_PATH       - path to Python library object; currently
                          "c:/tools/python/libs"
---------------------------------------------------------------------
Jamfile:247: in load-jamfiles
*** argument error
* rule stage ( name : sources + : requirements * : local-build * )
* called with: ( include/boost-1_32 :  : <locate>C:\Boost <tree-subdirs>C:\temp\
boost_1_32_0 <target>install :  )
* missing argument sources
C:\temp\boost_1_32_0\tools/build/v1\boost-base.jam:2306:see definition of rule '
stage' being called
C:\temp\boost_1_32_0\tools\build\v1\bootstrap.jam:21: in boost-build
C:\temp\boost_1_32_0\boost-build.jam:16: in module scope

 

C:\temp\boost_1_32_0>

 

Regards

 

 

Theo

[Luigi Ballabio]

On 05/11/2005 11:22:53 AM, [hidden email] wrote:
> Hi Joe,
>
> Thanks for your comments, I think Luigi should comment also.

Yes, I should, but I'm a bit busy at this time. I'll try and comment  
shortly.

Later,
        Luigi