Re: [Quantlib-dev] Questions regarding amortizing bonds

[Luigi B. <lui...@gm...>]

Hi,

On Tue, 2009-03-17 at 10:28 -0700, snovik wrote:
> First of all, sorry for the long post.

No problem. And sorry for the delay.


> I can not understand why implementation of amortiting bonds is so complex
> and unfriendly. 
> 
> All bond constructors use some leg helper to produce coupon cashflows of
> some arbitrary notional schedule plus again some arbitrary final redemption.
> I see it being as flexbile as it could be.

Yes, the idea was to cover the general case.

> However if I want to have an
> amortizing bond I used to use a single original (not current) notional to
> produce "full" coupon cash flows which where then wrapped and adjusted for
> factor on each given factor date. Here factor is the bond paydown schedule,
> starting from 1 at issue and going to 0 at maturity or final paydown date.

Ok... so you're wrapping the coupons in instances of a wrapper class
that scales their amount--is that correct? Does the wrapper class
inherit from Coupon?


> Current implementation of amortizing bond requires me to pre-calculate
> already amortized (current) notionals and then send them to the bond
> constructor which then uses a leg helper and so on... and at the end still
> extracts amortized amounts from provided notionals.
> 
> My questions are:
> 
> First, I do not understand why I have to pre-calculate current notionals.
> Factors allow for basic bond comparision and if I need to model amortisation
> of bonds I am modelling factors which means that I am going to stick with my
> wrapper and avoid pre-calculation currently required. If I am using historic
> information to construct an amortizing bond, then factor information of much
> more readily available than current notionals which again leaves me with the
> wrapper.

I see your point. However, I think this can be fixed (from a user's
point of view) simply by adding another constructor that takes the
factors and builds the appropriate cashflows. Do you agree? I'd be happy
to include such a constructor if that makes the class easier to use.


> Second, when I am looking into the code, I fail to "wrap" ;) my head around
> it. Calculation of amortisation cash-flows is very straightforward if one
> uses factors that there is no need to store notionals, cashflows, schedules
> and redemptions and do any magic with them. I know memory if cheap these
> days and should be a low concern but only if it makes code easier or faster,
> not more complex ;)

Building and storing cashflows allows one to write and reuse generic
code; for instance, DiscountingBondEngine just calls npv(cashflows)
whether or not bonds are amortized, which does make the code easier.
Likewise, you can also make cash-flow analysis of them in a generic way
(for instance, the several yield calculations works the same way on
amortized and non-amortized bonds.)


> Finally, I do not understand why notionals are not allowed to increase (or
> be greater than final payment). There are plenty of in general amortizing
> instruments which are PIK-able, i.e. when interest can be capitalized (CLOs
> are like this to start with).

Ok, so if I understand correctly, when interest is capitalized you get
the interest from the coupon, put it back into the bond (which can be
seen as a negative cashflow that cancels out the coupon) and proceed
with an increased notional, right? If that's so, I guess that the
existing machinery can work and we can just lift the requirement. Are
you willing to try to fix the code (and also add the new constructor)
and send me a patch?

Thanks for the feedback,
	Luigi


-- 

The shortest way to do many things is to do only one thing at once. 
-- Samuel Smiles