Binomial Engines - Greeks

[Toyin Akin]

Hi Luigi,

Normally pricing American options is done accurately via a tree and it's
hard to believe that Quantlib (well I think this is the case) does not
provide greeks for this common option type.

Any ideas or suggestions on the best way of enabling the BinomialEngine
class to ouput the greek results?

>From my 10 minute inspection one idea would be to obtain the process object
(within the calculate() method of the BinomialEngine.hpp file), extracting
out the relevant parameter from the process object, bumping the parameter,
constructing a new process object and then pricing.

In fact the manipulation that I suggest above is already done for normal
pricing. Thus this would just be a case of repeated construction of more
(bumped) process objects, repricing and then deducting from the base value.

Do you see a neater way to go about this? (Apart from doing all this
manipulation at the user level (ie - manipulate the parameters and repeat
all the calls at the testsuite level).

If the approach I mention is the way to go how soon do you think it can make
it into QuantLib (that is if this enhancement is also in QuantLibs
interest)?

Best Regards,
Toy out...

[Toyin Akin]

Also,

If this methodology is correct, then I'm sure the ConvertibleBond framework
can also benefit from this change...

Toy out...

>From: "Toyin Akin" <[hidden email]>
>To: [hidden email]
>CC: [hidden email],[hidden email]
>Subject: [Quantlib-users] Binomial Engines - Greeks
>Date: Wed, 21 Jun 2006 15:22:13 +0100
>
>
>Hi Luigi,
>
>Normally pricing American options is done accurately via a tree and it's
>hard to believe that Quantlib (well I think this is the case) does not
>provide greeks for this common option type.
>
>Any ideas or suggestions on the best way of enabling the BinomialEngine
>class to ouput the greek results?
>
> >From my 10 minute inspection one idea would be to obtain the process
>object
>(within the calculate() method of the BinomialEngine.hpp file), extracting
>out the relevant parameter from the process object, bumping the parameter,
>constructing a new process object and then pricing.
>
>In fact the manipulation that I suggest above is already done for normal
>pricing. Thus this would just be a case of repeated construction of more
>(bumped) process objects, repricing and then deducting from the base value.
>
>Do you see a neater way to go about this? (Apart from doing all this
>manipulation at the user level (ie - manipulate the parameters and repeat
>all the calls at the testsuite level).
>
>If the approach I mention is the way to go how soon do you think it can
>make
>it into QuantLib (that is if this enhancement is also in QuantLibs
>interest)?
>
>Best Regards,
>Toy out...
>
>
>
>
>_______________________________________________
>QuantLib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Jun 21, 2006, at 4:22 PM, Toyin Akin wrote:
> Normally pricing American options is done accurately via a tree and
> it's hard to believe that Quantlib (well I think this is the case)
> does not provide greeks for this common option type.
>
> Any ideas or suggestions on the best way of enabling the
> BinomialEngine class to ouput the greek results?

Toyin,
        apologies for the delay.  Usually we tend not to provide numerical
greeks, as the user can bump parameters himself---and moreover, he
could bump them of the quantity he likes instead of the one we though
sensible.

Instead, I think an often used trick for calculating Greeks on trees is
to move the tree origin a bit back in time so that the tree has three
nodes at today's date, the central one corresponding to the spot value.
Delta and Gamma can then be calculated by a difference formula. This is
an approach I'd like to have in the library if someone contributed it
(hint, hint...)

Later,
        Luigi

[Toyin Akin]

Hi all,

I am looking at the possibility of pricing callable capped floater using
QuantLib and it seems like most of the code to price such a product is more
or less within Quantlib already (parts of the logic is present in different
classes).

Basically I want to price, for each period, the following

Libor() - Caplet(Libor, X)*Notional*AccuralPeriod , callable @ $Y for each
period.

This has to be priced via a tree methodology and the Libor() - Cap(Libor,
X)*Notional*AccuralPeriod
part can be priced by

1) implementing the Libor() pricing via the float leg code that is part of
the DiscretizedSwap class
2) implementing the Caplet(Libor, X) pricing via the cap leg code that is
part of the DiscretizedCapFloor class

Thus these two legs can be pulled out to form a class like the
DiscretizedSwaption class.

The issue I have is how to price the callable part.

Now I have this little description of the callable algorithm from the
FinancialCAD web site :

###########################################################
The price of a callable capped floater is obtained by building a trinomial
interest rate tree, constructing the yield curve on each node of the tree,
and re-valuing the capped floater (note) on each node.  On nodes that are
exercise dates, the price of the note is compared to the call and/or put
price(s).  If it is possible for the issuer to call, and the call price is
less than the note price, then the call option is exercised and the price of
the option on that node is the difference between the call price and the
note price.  If the note is not called and it is possible for the holder to
put, and the put price is greater than the note price, then the put option
is exercised and the price of the option on that node is the difference
between the put price and the note price.  The option price is rolled back
to earlier nodes on the tree and re-calculated as above depending on whether
or not the option is exercised.  The option price rolled back to the value
date is added to the price of the non-callable capped floater on the value
date to get the price of the callable capped floater.
###########################################################

My question is regarding the statement " difference between the call price
and the note price".

Again the note can be computed easily via the "Libor() - Caplet(Libor,
X)*Notional*AccuralPeriod" expression. The note is priced backwards in time
and each time you step back, an extra coupon period is added onto the note
(at each node).

The tree that quantlib builds for interest rate pricing (ie - capfloor via
tree) assumes that you are standing on the start date of a coupon period
(see preAdjustValuesImpl() of the DiscretizedCapFloor() class). Thus you
cannot use the regular max(L-X,0) expression to value a cap, but a modified
version to take into account that you are standing on the start date of a
rate fixing and not the end.

Thus, FINALLY!!, the question I am asking : Is there an adjustment that one
needs to perform on this "difference between the call price and the note
price" because we are standing on the start date of each coupon period.

I am making the assumption that the $Y callable price is to be paid at the
each of each callable period. Is this the normal convention?

Long winded I know...!!
Toy out.

[Toyin Akin]

Hi,

Is there an implementation (and possibly an example of usage) of the
VanillaOptionPricer interface class that is present within the
/ql/cashflows/conundrumpricer.hpp file?

Toy out.

[Ferdinando M. Ametrano-3]

Hi Toyin

> Is there an implementation (and possibly an example of usage) of the
> VanillaOptionPricer interface class that is present within the
> /ql/cashflows/conundrumpricer.hpp file?
not yet, the author is working on it.
This mail should have been sent to quantlib-dev only, since the code
it's on the trunk, not released yet. Besides please do not cross post
to quantlib-users and quantlib-dev

ciao -- Nando

[Toyin Akin]

Hi,

Sorry about the cross-posting.
I will address all unreleased code queries to the dev list only.

Toy out.

>From: "Ferdinando Ametrano" <[hidden email]>
>To: "Toyin Akin" <[hidden email]>
>CC: [hidden email], [hidden email],
>[hidden email]
>Subject: Re: [Quantlib-users] CMS Options
>Date: Wed, 19 Jul 2006 10:48:33 +0200
>
>Hi Toyin
>
>>Is there an implementation (and possibly an example of usage) of the
>>VanillaOptionPricer interface class that is present within the
>>/ql/cashflows/conundrumpricer.hpp file?
>not yet, the author is working on it.
>This mail should have been sent to quantlib-dev only, since the code
>it's on the trunk, not released yet. Besides please do not cross post
>to quantlib-users and quantlib-dev
>
>ciao -- Nando

[Guowen Han]

Please keep in mind
1. the call schedule does not have to match the coupon schedule,
2. the quoted call price is kind of clean, and
3. the simulated prices are always dirty price and the backward induction values on the tree are kind of dirty price (including accrued interest)

So, the call prices are not necessary the paid off price when the calls are exercised.

Guowen


 

"Toyin Akin" <[hidden email]>
Sent by: [hidden email]

07/19/2006 03:40 AM

To	[hidden email]
cc	[hidden email], [hidden email]
Subject	[Quantlib-users] Pricing Callable Capped Floaters within a        HullWhite Tree

Hi all,

I am looking at the possibility of pricing callable capped floater using
QuantLib and it seems like most of the code to price such a product is more
or less within Quantlib already (parts of the logic is present in different
classes).

Basically I want to price, for each period, the following

Libor() - Caplet(Libor, X)*Notional*AccuralPeriod , callable @ $Y for each
period.

This has to be priced via a tree methodology and the Libor() - Cap(Libor,
X)*Notional*AccuralPeriod
part can be priced by

1) implementing the Libor() pricing via the float leg code that is part of
the DiscretizedSwap class
2) implementing the Caplet(Libor, X) pricing via the cap leg code that is
part of the DiscretizedCapFloor class

Thus these two legs can be pulled out to form a class like the
DiscretizedSwaption class.

The issue I have is how to price the callable part.

Now I have this little description of the callable algorithm from the
FinancialCAD web site :

###########################################################
The price of a callable capped floater is obtained by building a trinomial
interest rate tree, constructing the yield curve on each node of the tree,
and re-valuing the capped floater (note) on each node.  On nodes that are
exercise dates, the price of the note is compared to the call and/or put
price(s).  If it is possible for the issuer to call, and the call price is
less than the note price, then the call option is exercised and the price of
the option on that node is the difference between the call price and the
note price.  If the note is not called and it is possible for the holder to
put, and the put price is greater than the note price, then the put option
is exercised and the price of the option on that node is the difference
between the put price and the note price.  The option price is rolled back
to earlier nodes on the tree and re-calculated as above depending on whether
or not the option is exercised.  The option price rolled back to the value
date is added to the price of the non-callable capped floater on the value
date to get the price of the callable capped floater.
###########################################################

My question is regarding the statement " difference between the call price
and the note price".

Again the note can be computed easily via the "Libor() - Caplet(Libor,
X)*Notional*AccuralPeriod" expression. The note is priced backwards in time
and each time you step back, an extra coupon period is added onto the note
(at each node).

The tree that quantlib builds for interest rate pricing (ie - capfloor via
tree) assumes that you are standing on the start date of a coupon period
(see preAdjustValuesImpl() of the DiscretizedCapFloor() class). Thus you
cannot use the regular max(L-X,0) expression to value a cap, but a modified
version to take into account that you are standing on the start date of a
rate fixing and not the end.

Thus, FINALLY!!, the question I am asking : Is there an adjustment that one
needs to perform on this "difference between the call price and the note
price" because we are standing on the start date of each coupon period.

I am making the assumption that the $Y callable price is to be paid at the
each of each callable period. Is this the normal convention?

Long winded I know...!!
Toy out.



-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users


________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted
with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have
received this email in error, please notify us immediately and
delete the email and any attachments from your system. The
recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any
damage caused by any virus transmitted by this email.

[Toyin Akin]

Hey Guowen,

Thanks for the tip.
The dirty pricing bit is a big help for structures whose start date is in
the past.

I actually forgot about the fact that you can call on ANY date. However I
assume that coupon dates are the most commonly dates that are chosen for
calling any structure.

Thanks again,
Toy out...

>From: Guowen Han <[hidden email]>
>To: "Toyin Akin" <[hidden email]>
>CC:
>[hidden email],[hidden email],
>[hidden email],[hidden email]
>Subject: Re: [Quantlib-users] Pricing Callable Capped Floaters within
>a HullWhite Tree
>Date: Wed, 19 Jul 2006 09:07:08 -0400
>
>Please keep in mind
>1. the call schedule does not have to match the coupon schedule,
>2. the quoted call price is kind of clean, and
>3. the simulated prices are always dirty price and the backward induction
>values on the tree are kind of dirty price (including accrued interest)
>
>So, the call prices are not necessary the paid off price when the calls
>are exercised.
>
>Guowen
>
>
>
>
>
>
>"Toyin Akin" <[hidden email]>
>Sent by: [hidden email]
>07/19/2006 03:40 AM
>
>To
>[hidden email]
>cc
>[hidden email], [hidden email]
>Subject
>[Quantlib-users] Pricing Callable Capped Floaters within a      HullWhite
>Tree
>
>
>
>
>
>
>
>Hi all,
>
>I am looking at the possibility of pricing callable capped floater using
>QuantLib and it seems like most of the code to price such a product is
>more
>or less within Quantlib already (parts of the logic is present in
>different
>classes).
>
>Basically I want to price, for each period, the following
>
>Libor() - Caplet(Libor, X)*Notional*AccuralPeriod , callable @ $Y for each
>
>period.
>
>This has to be priced via a tree methodology and the Libor() - Cap(Libor,
>X)*Notional*AccuralPeriod
>part can be priced by
>
>1) implementing the Libor() pricing via the float leg code that is part of
>
>the DiscretizedSwap class
>2) implementing the Caplet(Libor, X) pricing via the cap leg code that is
>part of the DiscretizedCapFloor class
>
>Thus these two legs can be pulled out to form a class like the
>DiscretizedSwaption class.
>
>The issue I have is how to price the callable part.
>
>Now I have this little description of the callable algorithm from the
>FinancialCAD web site :
>
>###########################################################
>The price of a callable capped floater is obtained by building a trinomial
>
>interest rate tree, constructing the yield curve on each node of the tree,
>
>and re-valuing the capped floater (note) on each node.  On nodes that are
>exercise dates, the price of the note is compared to the call and/or put
>price(s).  If it is possible for the issuer to call, and the call price is
>
>less than the note price, then the call option is exercised and the price
>of
>the option on that node is the difference between the call price and the
>note price.  If the note is not called and it is possible for the holder
>to
>put, and the put price is greater than the note price, then the put option
>
>is exercised and the price of the option on that node is the difference
>between the put price and the note price.  The option price is rolled back
>
>to earlier nodes on the tree and re-calculated as above depending on
>whether
>or not the option is exercised.  The option price rolled back to the value
>
>date is added to the price of the non-callable capped floater on the value
>
>date to get the price of the callable capped floater.
>###########################################################
>
>My question is regarding the statement " difference between the call price
>
>and the note price".
>
>Again the note can be computed easily via the "Libor() - Caplet(Libor,
>X)*Notional*AccuralPeriod" expression. The note is priced backwards in
>time
>and each time you step back, an extra coupon period is added onto the note
>
>(at each node).
>
>The tree that quantlib builds for interest rate pricing (ie - capfloor via
>
>tree) assumes that you are standing on the start date of a coupon period
>(see preAdjustValuesImpl() of the DiscretizedCapFloor() class). Thus you
>cannot use the regular max(L-X,0) expression to value a cap, but a
>modified
>version to take into account that you are standing on the start date of a
>rate fixing and not the end.
>
>Thus, FINALLY!!, the question I am asking : Is there an adjustment that
>one
>needs to perform on this "difference between the call price and the note
>price" because we are standing on the start date of each coupon period.
>
>I am making the assumption that the $Y callable price is to be paid at the
>
>each of each callable period. Is this the normal convention?
>
>Long winded I know...!!
>Toy out.
>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share
>your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>QuantLib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>
>
>
>-----------------------------------------
>________________________________________________________
>DTCC DISCLAIMER: This email and any files transmitted with it are
>confidential and intended solely for the use of the individual or
>entity to whom they are addressed. If you have received this email
>in error, please notify us immediately and delete the email and any
>attachments from your system. The recipient should check this email
>and any attachments for the presence of viruses.  The company
>accepts no liability for any damage caused by any virus transmitted
>by this email.

>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share
>your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


>_______________________________________________
>QuantLib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Guowen Han]

One other thing you might want to take into consideration  will  be the call notice effect, this would have big impact on the simulated. Also, the call notice days may be different for different issuers1.

Guowen

"Toyin Akin" <[hidden email]>

07/19/2006 02:52 PM

To	Guowen Han <[hidden email]>
cc	[hidden email]
Subject	Re:Pricing Callable Capped Floaters within a HullWhite Tree

Hey Guowen,

Thanks for the tip.
The dirty pricing bit is a big help for structures whose start date is in
the past.

I actually forgot about the fact that you can call on ANY date. However I
assume that coupon dates are the most commonly dates that are chosen for
calling any structure.

Thanks again,
Toy out...

>From: Guowen Han <[hidden email]>
>To: "Toyin Akin" <[hidden email]>
>CC:
>[hidden email],[hidden email],
>[hidden email],[hidden email]
>Subject: Re: [Quantlib-users] Pricing Callable Capped Floaters within
>a                 HullWhite Tree
>Date: Wed, 19 Jul 2006 09:07:08 -0400
>
>Please keep in mind
>1. the call schedule does not have to match the coupon schedule,
>2. the quoted call price is kind of clean, and
>3. the simulated prices are always dirty price and the backward induction
>values on the tree are kind of dirty price (including accrued interest)
>
>So, the call prices are not necessary the paid off price when the calls
>are exercised.
>
>Guowen
>
>
>
>
>
>
>"Toyin Akin" <[hidden email]>
>Sent by: [hidden email]
>07/19/2006 03:40 AM
>
>To
>[hidden email]
>cc
>[hidden email], [hidden email]
>Subject
>[Quantlib-users] Pricing Callable Capped Floaters within a      HullWhite
>Tree
>
>
>
>
>
>
>
>Hi all,
>
>I am looking at the possibility of pricing callable capped floater using
>QuantLib and it seems like most of the code to price such a product is
>more
>or less within Quantlib already (parts of the logic is present in
>different
>classes).
>
>Basically I want to price, for each period, the following
>
>Libor() - Caplet(Libor, X)*Notional*AccuralPeriod , callable @ $Y for each
>
>period.
>
>This has to be priced via a tree methodology and the Libor() - Cap(Libor,
>X)*Notional*AccuralPeriod
>part can be priced by
>
>1) implementing the Libor() pricing via the float leg code that is part of
>
>the DiscretizedSwap class
>2) implementing the Caplet(Libor, X) pricing via the cap leg code that is
>part of the DiscretizedCapFloor class
>
>Thus these two legs can be pulled out to form a class like the
>DiscretizedSwaption class.
>
>The issue I have is how to price the callable part.
>
>Now I have this little description of the callable algorithm from the
>FinancialCAD web site :
>
>###########################################################
>The price of a callable capped floater is obtained by building a trinomial
>
>interest rate tree, constructing the yield curve on each node of the tree,
>
>and re-valuing the capped floater (note) on each node.  On nodes that are
>exercise dates, the price of the note is compared to the call and/or put
>price(s).  If it is possible for the issuer to call, and the call price is
>
>less than the note price, then the call option is exercised and the price
>of
>the option on that node is the difference between the call price and the
>note price.  If the note is not called and it is possible for the holder
>to
>put, and the put price is greater than the note price, then the put option
>
>is exercised and the price of the option on that node is the difference
>between the put price and the note price.  The option price is rolled back
>
>to earlier nodes on the tree and re-calculated as above depending on
>whether
>or not the option is exercised.  The option price rolled back to the value
>
>date is added to the price of the non-callable capped floater on the value
>
>date to get the price of the callable capped floater.
>###########################################################
>
>My question is regarding the statement " difference between the call price
>
>and the note price".
>
>Again the note can be computed easily via the "Libor() - Caplet(Libor,
>X)*Notional*AccuralPeriod" expression. The note is priced backwards in
>time
>and each time you step back, an extra coupon period is added onto the note
>
>(at each node).
>
>The tree that quantlib builds for interest rate pricing (ie - capfloor via
>
>tree) assumes that you are standing on the start date of a coupon period
>(see preAdjustValuesImpl() of the DiscretizedCapFloor() class). Thus you
>cannot use the regular max(L-X,0) expression to value a cap, but a
>modified
>version to take into account that you are standing on the start date of a
>rate fixing and not the end.
>
>Thus, FINALLY!!, the question I am asking : Is there an adjustment that
>one
>needs to perform on this "difference between the call price and the note
>price" because we are standing on the start date of each coupon period.
>
>I am making the assumption that the $Y callable price is to be paid at the
>
>each of each callable period. Is this the normal convention?
>
>Long winded I know...!!
>Toy out.
>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share
>your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>QuantLib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>
>
>
>-----------------------------------------
>________________________________________________________
>DTCC DISCLAIMER: This email and any files transmitted with it are
>confidential and intended solely for the use of the individual or
>entity to whom they are addressed. If you have received this email
>in error, please notify us immediately and delete the email and any
>attachments from your system. The recipient should check this email
>and any attachments for the presence of viruses.  The company
>accepts no liability for any damage caused by any virus transmitted
>by this email.


>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share
>your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


>_______________________________________________
>QuantLib-users mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-users




________________________________________________________
DTCC DISCLAIMER: This email and any files transmitted
with it are confidential and intended solely for the use of the
individual or entity to whom they are addressed. If you have
received this email in error, please notify us immediately and
delete the email and any attachments from your system. The
recipient should check this email and any attachments for the
presence of viruses. The company accepts no liability for any
damage caused by any virus transmitted by this email.

[Toyin Akin]

Hi all,

I have a few questions for you...

1) Volatility interpolation...

Let's assume that one has built a volatility smile based on linear
interpolation or a calibrated SABR curve and these volatilities are based on
5Y A/MM underlying swap rates. Now some annoying dude comes along and wants
to price a swaption based on 5Y S/BB swaps. However only 5Y A/MM vols are
quoted in the market. How does one go about adjusting the  5Y S/BB strike
rate to that of the 5Y A/MM strike so that an interpolation can be used? Is
this enough? Does one need to modify the interpolated volatility also? Or do
I tell the dude "we can't price it"!!! :-)

2)

Concerning the 'unfinished' CMS convexity adjustment class via replication.
Looking at the code (line #235 of the conundrumpricer.cpp class.). Shouldn't
this be x - forward (rather than x - strike)?

3)

Also based on the  'unfinished' CMS convexity adjustment class, I noticed
that the integration limit for CAPs is set to 1.0 (the strike value will
move from the given value all the way up to 1.0). If I am reading this right
and one uses a SABR model with mid to high-ish wing values, you can imply
volatility values over 100% during the replication!! Is it enough to instead
compute some percentage movement from the given strike (ie - 40%)? The same
is true for the downward direction.

That's all folks...

Toy out...

[Toyin Akin]

Hi,

My observations concerning point 2) is invalid as I have now associated it
with equ 2.12

Toy out.

>From: "Toyin Akin" <[hidden email]>
>To: [hidden email]
>Subject: [Quantlib-dev] SABR/CMS/Vol Interpolation...
>Date: Mon, 24 Jul 2006 11:17:33 +0100
>
>
>Hi all,
>
>I have a few questions for you...
>
>1) Volatility interpolation...
>
>Let's assume that one has built a volatility smile based on linear
>interpolation or a calibrated SABR curve and these volatilities are based
>on
>5Y A/MM underlying swap rates. Now some annoying dude comes along and wants
>to price a swaption based on 5Y S/BB swaps. However only 5Y A/MM vols are
>quoted in the market. How does one go about adjusting the  5Y S/BB strike
>rate to that of the 5Y A/MM strike so that an interpolation can be used? Is
>this enough? Does one need to modify the interpolated volatility also? Or
>do
>I tell the dude "we can't price it"!!! :-)
>
>2)
>
>Concerning the 'unfinished' CMS convexity adjustment class via replication.
>Looking at the code (line #235 of the conundrumpricer.cpp class.).
>Shouldn't
>this be x - forward (rather than x - strike)?
>
>3)
>
>Also based on the  'unfinished' CMS convexity adjustment class, I noticed
>that the integration limit for CAPs is set to 1.0 (the strike value will
>move from the given value all the way up to 1.0). If I am reading this
>right
>and one uses a SABR model with mid to high-ish wing values, you can imply
>volatility values over 100% during the replication!! Is it enough to
>instead
>compute some percentage movement from the given strike (ie - 40%)? The same
>is true for the downward direction.
>
>That's all folks...
>
>Toy out...
>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share
>your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>QuantLib-dev mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Toyin Akin]

However,

I believe I have found 2 other issues with the new CMS pricer.

1) The computation of the mDelta variable looks incorrect as line #284
creates a leg from spot and the top (numer) expression of line #289 is thus
huge. For a deal set in-arrears the numer formula should be zero and not
("PaymentDate - SpotDate") which for a CMS rate starting in 5 years,
Quarterly fixed resets would equal 5.25. Line #284 needs to pass the CMS
swaps fixing date and not the YieldCurve's ReferenceDate.

2) Line #214 returns the size of the schedule object which is not the same
as the number of periods within the underlying swap. One needs to reduce the
calculation by one.

Also, I do know that this class is unfinished and thus untested, however I
have an interest in this model as I previously integrated this model into a
pricing application while I worked for Jerome Lebuchoux (Author of Models
for CMS Caps - Euro Derivative, Risk 2000) and M Musiela (the M in the BGM
model).

It's nice to see a clear C++ version of the algorithm.

Toy out...

>From: "Toyin Akin" <[hidden email]>
>To: [hidden email]
>Subject: Re: [Quantlib-dev] SABR/CMS/Vol Interpolation...
>Date: Mon, 24 Jul 2006 15:45:08 +0100
>
>
>Hi,
>
>My observations concerning point 2) is invalid as I have now associated it
>with equ 2.12
>
>Toy out.
>
>
> >From: "Toyin Akin" <[hidden email]>
> >To: [hidden email]
> >Subject: [Quantlib-dev] SABR/CMS/Vol Interpolation...
> >Date: Mon, 24 Jul 2006 11:17:33 +0100
> >
> >
> >Hi all,
> >
> >I have a few questions for you...
> >
> >1) Volatility interpolation...
> >
> >Let's assume that one has built a volatility smile based on linear
> >interpolation or a calibrated SABR curve and these volatilities are based
> >on
> >5Y A/MM underlying swap rates. Now some annoying dude comes along and
>wants
> >to price a swaption based on 5Y S/BB swaps. However only 5Y A/MM vols are
> >quoted in the market. How does one go about adjusting the  5Y S/BB strike
> >rate to that of the 5Y A/MM strike so that an interpolation can be used?
>Is
> >this enough? Does one need to modify the interpolated volatility also? Or
> >do
> >I tell the dude "we can't price it"!!! :-)
> >
> >2)
> >
> >Concerning the 'unfinished' CMS convexity adjustment class via
>replication.
> >Looking at the code (line #235 of the conundrumpricer.cpp class.).
> >Shouldn't
> >this be x - forward (rather than x - strike)?
> >
> >3)
> >
> >Also based on the  'unfinished' CMS convexity adjustment class, I noticed
> >that the integration limit for CAPs is set to 1.0 (the strike value will
> >move from the given value all the way up to 1.0). If I am reading this
> >right
> >and one uses a SABR model with mid to high-ish wing values, you can imply
> >volatility values over 100% during the replication!! Is it enough to
> >instead
> >compute some percentage movement from the given strike (ie - 40%)? The
>same
> >is true for the downward direction.
> >
> >That's all folks...
> >
> >Toy out...
> >
> >
> >
> >-------------------------------------------------------------------------
> >Take Surveys. Earn Cash. Influence the Future of IT
> >Join SourceForge.net's Techsay panel and you'll get the chance to share
> >your
> >opinions on IT & business topics through brief surveys -- and earn cash
> >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> >_______________________________________________
> >QuantLib-dev mailing list
> >[hidden email]
> >https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
>
>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share
>your
>opinions on IT & business topics through brief surveys -- and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>_______________________________________________
>QuantLib-dev mailing list
>[hidden email]
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On 07/19/2006 09:40:46 AM, Toyin Akin wrote:
> I am looking at the possibility of pricing callable capped floater  
> using QuantLib and it seems like most of the code to price such a  
> product is more or less within Quantlib already (parts of the logic  
> is present in different classes).

Toyin,
        I'm afraid I don't have time to go much into details (I'll be  
in vacation for two weeks starting today and I have a few things to  
finish before I leave.) However, the implementation of the payoff is as  
you sketched. As for the callable part, you can look at the code in  
DiscretizedSwaption for inspiration. Basically, at each exercise date  
you'll find the value of the note (Libor + cap) as you explained. The  
exercise price is paid at the exercise date itself, so at the i-th node  
you'll just set value[i] = min(value[i], price).

Hope this helps,
        Luigi


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

The box said "Use Windows 95 or better," so I got a Macintosh.

[Ryan Smulktis]

What is the best/recommended way to learn the QuantLib monte-carlo framework? I would like to ultimately use the monte-carlo framework in some development I'm doing. At this point I'm just trying to figure out how it works and what I will need to do to use the framework. I can obviously trace my way through one of the more simple examples (say some flavor of a VanillaOption? or other) but it would also be nice if there was a description of the different classes and their responsibilities. I didn't find the help file especially useful for this. Is there more detailed documentation some place that could help me? Or, should I just stick to tracing through the code? Thanks for any suggestions,

 

Ryan

[Ryan Smulktis]

Arnaud, I will send along any responses that I think will be helpful.

On 8/14/06, Ryan Smulktis <[hidden email]> wrote:

What is the best/recommended way to learn the QuantLib monte-carlo framework? I would like to ultimately use the monte-carlo framework in some development I'm doing. At this point I'm just trying to figure out how it works and what I will need to do to use the framework. I can obviously trace my way through one of the more simple examples (say some flavor of a VanillaOption? or other) but it would also be nice if there was a description of the different classes and their responsibilities. I didn't find the help file especially useful for this. Is there more detailed documentation some place that could help me? Or, should I just stick to tracing through the code? Thanks for any suggestions,

 

Ryan

[Luigi Ballabio]

On 08/14/2006 07:39:19 PM, Ryan Smulktis wrote:
> What is the best/recommended way to learn the QuantLib monte-carlo
> framework?

[Administrator note: please see the FAQ item at
  <http://quantlib.org/reference/faq.html#faq_lists_new_topic>
  about replying to an existing message to start a new topic. Thanks.]

Ryan,
        apologies for the delay---I was on vacation. The documentation  
has been a sore spot in the project for a long time. At this moment,  
your best bet is tracing the code. The long-term solution is to start  
lobbying me to write some documentation...

Later,
        Luigi


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

It is better to know some of the questions than all of the answers.
-- James Thurber