Bond class

[Joseph Wang]

Theo,

I was looking at your e-mail, and it gave me an idea....  One of the
things that you suggested was to create a BondParam class, but I was
wondering if it would work better to use aggregation instead of
inheiritance, so you'd have something like

class ConvertibleBond {
   Bond bond_;
   ConversionOption option_;
}

One could extend this and just have the conversion option be one type of
bond option.  So class bond would have a member which would be a list of
BondOption s.

class Bond {
(...) current class;
vector <BondOption> ;
}

Here converible bond would look like

class ConvertibleBond :: public Bond {
   (consturctor)
}




And as subclasses of BondOptions you'd have

class ConversionOption::public BondOption {
}

class ForcedConversionOption::public BondOption {
}

class RedemptionOption::public BondOption {
}

The other idea your e-mail gave me was to put the dividend information
into class stock.  So conversion option would look like

class ConversionOption::public BondOption {
    Stock stock_;
    (...)
}

Thoughts?

I think that if we come to an agreement about the overall structure of
the bond class, we can check something in with ConversionOption stubbed
out, and we can then focus on working on that.

[Theo Boafo]

Hi Joe,

 

Your ideas are good.  Lets see what Luigi thinks.

 

Basically we are entering the world of hybrids and if we can sort out the basic structure for the underlyings we can have several combinations, and this would help for the future.

 

The convertible as we know is a hybrid of stock and bond.  These days there are products such as IR/FX, IR/EQ, IR/inflation, IR/Credit in terms of Interest rate Hybrids, etc.

 

 

Regards

 

Theo

 

[Luigi Ballabio]

On 04/25/05 05:05:28, Joseph Wang wrote:

> Theo,
>
> I was looking at your e-mail, and it gave me an idea....  One of the  
> things that you suggested was to create a BondParam class, but I was  
> wondering if it would work better to use aggregation instead of  
> inheiritance, so you'd have something like
>
> class ConvertibleBond {
>   Bond bond_;
>   ConversionOption option_;
> }

Yes, this is a possibility. But I'm not sure how we should construct  
instances of such a class---passing the two components to the  
ConvertibleBond constructor would result in a two- or three-pass  
initialization, as in:
Bond b(...);
ConversionOption o(...);
ConvertibleBond cb(b, o);
which is a bit verbose (and might require to pass a number of parameters to  
both components) and exposes implementation details.
Passing the set of arguments to the ConvertibleBond constructor and having  
it dispatch them to the components might be more compact.


> One could extend this and just have the conversion option be one type of  
> bond option.  So class bond would have a member which would be a list of  
> BondOption s.
> class Bond {
> (...) current class;
> vector <BondOption> ;
> }
>
> Thoughts?

I'm not sure that it can be abstracted this way. Having an attached vector  
of options seems to assume that they can be applied independently, or at  
most in the given order, and that one can add their values to obtain the  
value of the instrument. But this is not always the case: for instance, a  
callable convertible bond cannot be modeled as a bond plus two options  
(conversion and callability.) Its value is not
bond + conversion(bond) + callability(bond)
but rather
bond + callability(bond+conversion(bond))
or something like it (since the convertibility affects the value of the  
callability, and the callability can prevent the conversion.) So in general  
there is an interplay between the options whose logic cannot be abstracted  
once and for all.

Later,
        Luigi

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

Humphrey's Requirements Uncertainty Principle:
        For a new software system, the requirements will not be completely
        known until after the users have used it.

[Wujiang Lou]

Given the variaties of bonds and bond-like instruments, building a class
hierarchy via inheritance is one way: conventional, often leading to a
big tree of classes which eventually becomes hard to manage. Consider
Bond, FloatingBond, FixedCouponBond, StepupCouponBond,
StepupFloatingBond, FixedCashFlowBond,...;
Now add callable feature to each of them by subclassing (CallableBond,
CallableFloatingBond, ...);
and make them all putable;
and make them all convertible;
and add sinking fund to them all;
... Any other features bankers may come along with;
   
You got an idea how the class tree will look like.

Another way is to adopt a generic concept of bond: a generic bond thinks
a bond-like instrument of some composing policies:
a coupon policy including Fixed, Floating, Stepup, Custom;
a principal policy including Fixed, Amortized, Prepayed;
a callable policy with European, American, Bermudan;
a putable policy;
a conversion policy;
a credit enhancement policy like sinking fund, collateralization;  
...
So your convertible bond might look like this:
FixedCouponPolicy fixedCpn;
ConvertiblePolicy conv;
GenericBond myPlainConverts(fixedCpn, conv);

This generic view might be more fitting for non-commercial,
experimentory analysis package like QuantLib.

Best,
-wujiang

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of Luigi
Ballabio
Sent: Tuesday, April 26, 2005 9:58 AM
To: Joseph Wang
Cc: [hidden email]; Daniel J. Duffy;
[hidden email]
Subject: [Quantlib-users] Re: Bond class


On 04/25/05 05:05:28, Joseph Wang wrote:

> Theo,
>
> I was looking at your e-mail, and it gave me an idea....  One of the
> things that you suggested was to create a BondParam class, but I was
> wondering if it would work better to use aggregation instead of
> inheiritance, so you'd have something like
>
> class ConvertibleBond {
>   Bond bond_;
>   ConversionOption option_;
> }

Yes, this is a possibility. But I'm not sure how we should construct
instances of such a class---passing the two components to the
ConvertibleBond constructor would result in a two- or three-pass
initialization, as in:
Bond b(...);
ConversionOption o(...);
ConvertibleBond cb(b, o);
which is a bit verbose (and might require to pass a number of parameters
to both components) and exposes implementation details.
Passing the set of arguments to the ConvertibleBond constructor and
having it dispatch them to the components might be more compact.


> One could extend this and just have the conversion option be one type
> of bond option.  So class bond would have a member which would be a
> list of BondOption s.
> class Bond {
> (...) current class;
> vector <BondOption> ;
> }
>
> Thoughts?

I'm not sure that it can be abstracted this way. Having an attached
vector of options seems to assume that they can be applied
independently, or at most in the given order, and that one can add their
values to obtain the value of the instrument. But this is not always the
case: for instance, a callable convertible bond cannot be modeled as a
bond plus two options (conversion and callability.) Its value is not
bond + conversion(bond) + callability(bond) but rather bond +
callability(bond+conversion(bond))
or something like it (since the convertibility affects the value of the
callability, and the callability can prevent the conversion.) So in
general there is an interplay between the options whose logic cannot be
abstracted once and for all.

Later,
        Luigi

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

Humphrey's Requirements Uncertainty Principle:
        For a new software system, the requirements will not be
completely
        known until after the users have used it.



-------------------------------------------------------
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 
--------------------------------------------------------
 
This is not an offer (or solicitation of an offer) to buy/sell the securities/instruments mentioned or an official confirmation.  Morgan Stanley may deal as principal in or own or act as market maker for securities/instruments mentioned or may advise the issuers.  This is not research and is not from MS Research but it may refer to a research analyst/research report.  Unless indicated, these views are the author's and may differ from those of Morgan Stanley research or others in the Firm.  We do not represent this is accurate or complete and we may not update this.  Past performance is not indicative of future returns.  For additional information, research reports and important disclosures, contact me or see https://secure.ms.com/servlet/cls.  You should not use e-mail to request, authorize or effect the purchase or sale of any security or instrument, to send transfer instructions, or to effect any other transactions.  We cannot guarantee that any such requests received via e-mail will be processed in a timely manner.  This communication is solely for the addressee(s) and may contain confidential information.  We do not waive confidentiality by mistransmission.  Contact me if you do not wish to receive these communications.  In the UK, this communication is directed in the UK to those persons who are market counterparties or intermediate customers (as defined in the UK Financial Services Authority's rules).

[Ashish Kulkarni-6]

Yep, using policy-based class design does make a lot of sense in this 
case. I've been reading the relevant chapters in "Modern C++ Design", 
and I'd say that this is a perfect case where they'd be useful.

> Given the variaties of bonds and bond-like instruments, building a class
> hierarchy via inheritance is one way: conventional, often leading to a
> big tree of classes which eventually becomes hard to manage. Consider
> Bond, FloatingBond, FixedCouponBond, StepupCouponBond,
> StepupFloatingBond, FixedCashFlowBond,...;
> Now add callable feature to each of them by subclassing (CallableBond,
> CallableFloatingBond, ...); 
> and make them all putable; 
> and make them all convertible; 
> and add sinking fund to them all;
> ... Any other features bankers may come along with;
>    
> You got an idea how the class tree will look like.
> 
> Another way is to adopt a generic concept of bond: a generic bond thinks
> a bond-like instrument of some composing policies: 
> a coupon policy including Fixed, Floating, Stepup, Custom; 
> a principal policy including Fixed, Amortized, Prepayed; 
> a callable policy with European, American, Bermudan; 
> a putable policy; 
> a conversion policy;
> a credit enhancement policy like sinking fund, collateralization;  
> ...
> So your convertible bond might look like this:
> FixedCouponPolicy fixedCpn;
> ConvertiblePolicy conv;
> GenericBond myPlainConverts(fixedCpn, conv);
> 
> This generic view might be more fitting for non-commercial,
> experimentory analysis package like QuantLib.
> 
> Best,
> -wujiang

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."