Binomial Engines - Greeks
Locked
 
|
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... |
|
|
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 |
|
|
In reply to this post by Toyin Akin
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 |
|
|
In reply to this post by Toyin Akin
Luigi,
Several of the greeks from a tree can be calculated from the current tree in memory. The Delta and Gamma are calculated using numerical differencing of the next two time steps. Theta requires the suggetion you provided below. If you also calculated the delta and gamma off your time shifted tree, you are calculating the d theta-ddelta and d theta-dgamma or second order derivatives. Vega and rho require also require a new tree calculation and a numerical differenceing using sigma+h or rate+h where h is a small increment but all other parameters are constant. Good Luck Joe 1. Re: Binomial Engines - Greeks (Luigi Ballabio) A man is not the center of his universe, rather those he loves are. So his focus should always be on them for they will provide him with love and happiness all of his life - Anonymous
Talk is cheap. Use Yahoo! Messenger to make PC-to-Phone calls. Great rates starting at 1¢/min. |
Re: Binomial Engines - Greeks
|
|
Here is an R implementation of the Pelseer/Vorst method for computing
greeks on the tree as in the paper "The Binomial Model and the Greeks." /Journal of Derivatives/, Spring 1994, 45-49 Best, Kris greek.binomial<- function(imod=1, TypeFlag="ce", S=100, X=110, r=0.05, q=0, tyr=1, sigma=0.3, nstep=100) { # greek.binomial(imod=1,TypeFlag= "pa", S = 50, X = 50, tyr=5/12, r = 0.1, q = 0, sigma = 0.4, nstep = 50) # the extended CRR tree with node extensions!. if (imod == 2) nstep <- nstep + nstep%%2 mstep<-nstep+2 TypeFlag = TypeFlag[1] z = NA if (TypeFlag == "ce" || TypeFlag == "ca") z <- +1 if (TypeFlag == "pe" || TypeFlag == "pa") z <- -1 if (is.na(z)) stop("TypeFlag misspecified: ce|ca|pe|pa") dtval = tyr/nstep udpvec <- BinTreeParams(imod, S, X, r, q, tyr, sigma, nstep) u <- udpvec[1] d <- udpvec[2] p <- udpvec[3] Df = exp(-r * dtval) OptionValue = z * (S * u^(0:mstep) * d^(mstep:0) - X) OptionValue = (abs(OptionValue) + OptionValue)/2 if (TypeFlag == "ce" || TypeFlag == "pe") { for (j in seq(from = mstep - 1, to = 2, by = -1)) for (i in 0:j) { { OptionValue[i + 1] = (p * OptionValue[i + 2] + (1 - p) * OptionValue[i + 1]) * Df } } } if (TypeFlag == "ca" || TypeFlag == "pa") { for (j in seq(from = mstep - 1, to = 2, by = -1)) for (i in 0:j) OptionValue[i + 1] = max((z * (S * u^i * d^(abs(i - j)) - X)), (p * OptionValue[i + 2] + (1 - p) * OptionValue[i + 1]) * Df) } #cat(OptionValue[1]," ", OptionValue[3]," ",OptionValue[2],"\n") greek.binomial<-(OptionValue[1]-OptionValue[3])/(S*u^2-S*d^2) } |
Pricing Callable Capped Floaters within a HullWhite Tree
|
|
In reply to this post by Luigi Ballabio
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. |
|
|
In reply to this post by Luigi Ballabio
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. |
|
|
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 |
Re: Pricing Callable Capped Floaters within a HullWhite Tree
|
|
In reply to this post by Toyin Akin
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
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. |
Re: Pricing Callable Capped Floaters within a HullWhite Tree
|
|
In reply to this post by Toyin Akin
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. |
Re: Pricing Callable Capped Floaters within a HullWhite Tree
|
|
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
|
Re: Pricing Callable Capped Floaters within a HullWhite Tree
|
|
Arnaud, I will send along any responses that I think will be helpful.
On 8/14/06, Ryan Smulktis <[hidden email]> wrote:
|
Re: Pricing Callable Capped Floaters within aHullWhite Tree
|
|
In reply to this post by Ryan Smulktis
On the topic of Monte-Carlo…. Can anyone
tell me what would be considered to be the ‘norms’ for the number
of Monte-Carlo interations, and steps per iteration, when revaluing an
instrument such as a European Lookback Call? – I’m interested in
performance of these algorithms, and have a benchmarked my code at 100,000
iterations and 1000 steps per iteration. What Monte-Carlo parameters would
normally be used? Thanks, Peter Moreton From:
[hidden email] [mailto:[hidden email]]
On Behalf Of 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 |
Re: Pricing Callable Capped Floaters within a HullWhite Tree
|
|
In reply to this post by Ryan Smulktis
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 |
«
Return to quantlib-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |