- CapeTools Calendars
General Description
These functions provide Calendar objects. Calendar objects contain a list of holidays. These Calendar objects can be passed to numerous functions that require date calculation or manipulation. This category does contain a few functions that you can use to query these Calendar objects.
Additionally, you can add and remove dates from these objects. You can also merge Calendar objects.
- CapeTools Indexes
General Description
These functions provide Index creation objects. An index object is used to provide information concerning how an interest rate is fixed over a period of time. They are applied to floating rate legs. A typical index is a LIBOR index fixed by BBA. All indexes have to define the period length (ie - three months) that the interest rate fixing is applied upon, the number of days before the start date of the interest rate period that the fixing must occur, the holiday center etc... A YieldCurve object is also needed in order to acquire the discount factors needed to compute the fixing.
An optional Basis Swap curve can be passed to the Index creation functions which will be stripped in order to compute a spread that will be added to the fixed (Index) rate.
Why a Basis swap curve?
As an example, the United States is awash in one month money (index) from mortgage payments, car payments, and everything else, so you have to pay someone to take it away and turn it into three month money (index). This payment is captured via a basis spread on the three month money (index). Each currency has its preferred index for creating floating legs, for the United States this is 3m Libor, for Euros its 6m Euribor. Whatever these indices are, they are usually called the currency's "cash" leg.
A floating payment (for the interval tSt to tEnd) is valued as:
V = notional * dcf(tSt, tEnd) * Rfwd * DF(tEnd),
where the dcf is the day count fraction of the interval, Rfwd is the forward rate for the index, and DF is ccy's discount factor to the pay date. This is just the definition of the forward rate.
The forward rate is .
RFwd = RTrue + bs(tEnd)
where bs is the forward basis spread for the index, and the true rate is just the rate you'd expect from the discount factor:
RTrue = ((DF(tSt)/DF(tEnd)) - 1) / dcf(tSt, tEnd)
Or if you like...
RTrue = [DF(tSt) - DF(tEnd)] / dcf(tSt,tEnd) * DF(tEnd)
Whenever you see a floating rate index in a deal, immediately replaces it with the basis spread plus the true rate, the true rate is the mathematically idealized rate for the currency. One usually assumes the forward basis spread curve bs(tEnd) doesn't change. The forward basis spread curves are stripped from the basis swap market.
Yon can view the stripped forward spread curve stored within an Index object by executing the ShowIndexFwdSpreads() function. These forward spread curves are the basis for pricing currency basis swaps.
- CapeTools Curves
General Description
Given deposit, futures, FRAs and Swap instruments, these functions can strip out a discount factor (yield) curve. One can also input discount factor rates directly, or strip from zero rates or forward rates.
Usually when pricing a floating leg, you need two yield curves. A fixing curve in order to fix the rate and a discount curve for discounting cashflows. You will see this in numerous functions where a fixing curve is passed to an Index function and a discount curve is passed to legs (or instruments) that require discounting.
Thus basically you have a special discount curve for calculating the forward rates but the discount factors within this curve are NOT used for discounting cashflows.
We have implemented a curve that produces both a fixing curve and a discounting curve within a single yieldcurve object. Thus the same yieldcurve key will be passed to both the FixingCurve parameter and the discountingCurve parameter when pricing an instrument that demands both parameters (see CapeTools XCCY Curves).
These curves can also serve as input to the interest rate risk engine in order to compute DELTA and GAMMA risk parameters for an interest rate structure.
- CapeTools XCCY Curves
General Description
Given deposit, futures, FRAs and Swap instruments, these functions can strip out a discount factor curve. One can also input discount factor rates directly, or strip from zero rates or forward rates.
Usually when pricing a floating leg, you need two yield curves. A fixing curve in order to fix the rate and a discount curve for discounting cashflows. You will see this in numerous functions where a fixing curve is passed to an Index function and a discount curve is passed to legs (or instruments) that require discounting.
Thus basically you have a special discount curve for calculating the forward rates but the discount factors within this curve are NOT used for discounting cashflows.
We have implemented several yieldcurve functions that produce both a fixing curve and a discounting curve within a single yieldcurve object. Thus the same yieldcurve key will be passed to both the FixingCurve parameter and the discountingCurve parameter when pricing an instrument that demands both parameters.
We have achieved this by including a cross currency swap range within this stripper.
Our approach automatically gets the cross currency swap market correct. This method assumes only that USD 3m Libor floating legs have no basis spreads. One then finds say the forward basis spread curve for, say, 6m Euribor by combining the 6m Euribor to 6m USD Libor basis swap with the 6m USD Libor to 3m USD Libor basis swap to obtain the 6m Euribor to 3m USD Libor basis swaps. N-year basis swap at X basis points swaps a 6m Euribor + X bp payments (paid semiannually) for N years against 3m USD Libor payments (paid quarterly) for N years. The basis swaps are liquidly quoted for 1y, 2y, 3y, 5y, 7y, and 10y. From this data, one assumes an interpolation method, and strips to get the forward basis spreads. (see CapeTools Indexes for a definition of a forward basis spread).
The discount factors within these curves we call the cash discount factors. However when one requests a fixing value the correct LIBOR rate will be returned (with the help of the stripped forward basis spread curve).
These curves can also serve as input to the interest rate risk engine in order to compute DELTA and GAMMA risk parameters for an interest rate structure.
The following curves strip out both the discount curve and a forward spread curve :
- MKTYC_XCCY_D() ( interpolation methodology applied to the internally created DISCOUNT FACTORS CURVE. )
- MKTYC_XCCY_Z() ( interpolation methodology applied to the internally created ZERO RATE CURVE. )
- MKTYC_XCCY_F() ( interpolation methodology applied to the internally created FORWARD RATE CURVE. )
You can view the created forward spread curve by executing the ShowYCFwdSpreads() function. The three strippers above require the use of a Multi-dimensional LevenbergMarquardt object and thus are not as fast as the simpler strippers contained within the 'CapeTools Curves' category of functions (uses a one-dimensional Newton object). Thus we have implemented the following three strippers that will take in as input forward spread curves already stripped out from the strippers presented above.
- MKTYC_XCCY_D2() ( interpolation methodology applied to the internally created DISCOUNT FACTORS CURVE. )
- MKTYC_XCCY_Z2() ( interpolation methodology applied to the internally created ZERO RATE CURVE. )
- MKTYC_XCCY_F2() ( interpolation methodology applied to the internally created FORWARD RATE CURVE. )
All the curves presented here, when passed to interest rate instruments that are subject to interest rate risk calculations (see the 'CapeTools IR Risk' category of functions) produce more accurate results (as opposed to specifying separate discounting and fixing curves) because there exists a relationship between the discounting factors and fixing rates. (If you bump the inputs of the yieldcurve, the discount factors are adjusted correctly for the purpose of discounting a cashflow, this is not the case if you specify separate curves, the discounting factors do not move if you bump the market rates).
- CapeTools Bond Curves
General Description
Given deposit, futures, FRAs and Bond instruments, these functions can strip out a discount factor (yield) curve.
- CapeTools Credit Curves
General Description
Given a risk-free curve (most of the curves stripped from the 'CapeTools Curves', 'CapeTools XCCY Curves' or 'CapeTools Bond Curves' category of functions) we can produce a risky curve. A risky curve has additional information regarding default probabilities and thus specific to a single organisation (or sector). A risky curve can be treated as a regular yieldcurve and can be passed to all instruments that require discounting curve. Risky discount factors will be used to discount the cashflows as opposed to the risk-free discount factors.
These risky-curves also serve as inputs to the credit derivative functions.
- CapeTools Credit Transition Matrix
General Description
These functions create and queries credit transition matrix objects. The entries within the credit transition matrix represent one-year ratings migration probabilities with the last column/row representing the default probabilities. Each row within the matrix should sum to 100.
- CapeTools Volatility Curves
General Description
These functions create volatility curves (or grids). These curves (whether one-dimensional or two-dimensional) can utilise a variety of interpolation methodologies in order to acquire a volatility value from the curve.
The following interest rate volatility curves can also serve as input to the interest rate risk engine (CapeTools IR Risk) in order to compute VEGA and VOLGA risk parameters for an interest rate structure :
The ATMVolMatrix object only models At-The-Money volatility. You provide a matrix of option start - underlying length combinations.
The ExpiryKVolMatrix object can model interst rate smiles, however it does this for only one underlying instrument (ie - volatility structure on caps/floors/swaptions where the underlying length (ie - 5Y swap rate) is the same for all points). You provide a matrix of option start - option strike combinations.
A single SABRVolCurve object can model the entire volatilities for all interest rate options within an interst rate market. Thus one object can model the smiles for all caps/floors/swaptions (regardless of instrument length, 3M, 5Y, 10Y or option starting times).
An alternative to the SABRVolCurve object would be a three-dimensional object that would have Option-Length, Underlying-Length and Strike as the three dimensions of the cube. However such an object (although would capture the volatility smile) would not be able to model the true movement of the volatility smile. It is also a difficult object to work with.
You can also use the EquitySABRVolCurve function to model equity type volatility curves via the SABR model.
- CapeTools Grouped Curves
General Description
These functions allow the grouping of several yield curves, credit curves or volatility curves. These are used by the interest rate portfolio functions or the basket default swap functions to help manage a large number of constructed curves.
- CapeTools Repo Curves
General Description
Given a list of repo instruments, these functions construct repurchase (repo) curves.
The repo curves generated here can be passed to the CapeTools Forward Bond or CapeTools Bond Options category of functions.
- CapeTools Display Curves
General Description
These functions query Yieldcurve objects for various information.
There are functions to display data for discount curves, zero rate curves, market curves and FwdSpread curves.
- CapeTools Query Curves
General Description
These functions query VolCurves and Yieldcurve objects for various information.
You can request for the market sensitivity of the instruments used within the underlying Volalility Curve objects (delta, gamma, vega and theta). This is useful if you are conducting risk-management calculations yourself.
You can also generate a market rate matrix for each of the ('UnderlyingStart' / 'UnderlyingEnd') instrument combination (for a unit notional of the underlying deposits/swaps). Basically a rates matrix where the rows are the rate start tenors and the columns are the rate Length (in a Tenor format also).
- CapeTools Query Credit Curves
General Description
Functions to query and price basic credit default swap (CDS) derivative instruments given a credit curve.
You can execute functions to compute the fair premiums from a CDS (including Binary CDS).
You can compute risky discount factors, default probabilities, default densities, hazard rates and survival probabilities.
- CapeTools Credit Default Swaps
General Description
Functions to create regular and binary credit default swap (CDS) objects. These objects can then be queried and priced via functions present within this category.
You can query for the following information :
- Dirty price
- Clean price
- Accrued premium
- Payoff value
- Par premium value
- Premium leg value
- Rho (risk) of the recovery rate (one percent additive change)
- BPV of the risk-free curve
You can also price an option on a CDS contract.
- CapeTools Credit Default Swaps (Bonds/FRN)
General Description
Functions to create regular and binary credit default swap (CDS) objects based on data extracted from a Bond, Floating leg or Fixed leg object. These CDS objects can then be queried and priced via functions present within this category.
The advantages of these functions over those present within the CapeTools Credit Default Swaps category of functions is that you specify the window in which you would like protection upon your chosen instrument.
The chosen instrument can be one of the objects constructed from the following functions or categories :
You can query for the following information :
- Dirty price
- Clean price
- Accrued premium
- Payoff value
- Par premium value
- Premium leg value
- Rho (risk) of the recovery rate (one percent additive change)
- BPV of the risk-free curve
You can also price an option on the CDS object.
- CapeTools Credit Link Bond/Notes
General Description
Functions to create regular and binary credit link bond/notes (CLN) objects based on data extracted from a Bond, Floating leg or Fixed leg object. These CLN objects can then be queried and priced via functions present within this category.
A CLN object is simply the sum of the price of the instrument (priced using the risky curve) plus the value of the default leg over the protection period.
The chosen instrument can be one of the objects constructed from the following functions or categories :
You can query for the following information :
- FairValue
- Accrued interest
- Fair value + accrued interest
- Payoff value
- Risky PV of the instrument
- Rho (risk) of the recovery rate (one percent additive change)
- CapeTools Exotic Options
General Description
Functions that price vanilla and Exotic options using variations of the black-scholes model. These functions do not create objects and take single-valued parameters. Thus these functions are the fastest in terms of execution speed, but not very flexable in terms of portfolio management, scenario analysis and pricing option strategies. However they all return risk numbers for every single double valued parameter (first and second derivatives including cross derivatives). Theta is (of course) computed even though it is a date parameter.
First order derivative risk numbers can be requested by simply passing in the name of the parameter (preceded by the 'd' character) into the 'Greek' parameter of these functions (ie - dStock).
Second order derivative risk numbers can be requested by simply passing in the name of the parameter (preceded by the 'd' character) ( repeated twice) into the 'Greek' parameter of these functions (ie - dStockdStock).
Cross derivative risk numbers can be requested by simply passing in the name of the parameters (preceded by the 'd' character) into the 'Greek' parameter of these functions (ie - dStockdTime or dTimedStock).
You can of course make use of the following (in-built) case-insensitive Greek values :
- DELTA
- GAMMA
- VEGA
- VOLGA
- THETA
However when pricing options composed of two underlyers, we suggest using the former notation for the common risk values.
The risk values computed are the mathematical definition of a derivative (via differentiation). Thus if you wish to compute the risk numbers for a given shift (ie - a one basis point change in the parameter), then you simply multiply the risk number by the requested shift.
All of the functions implemented here have been taken from. 'The Complete Guide To OPTION PRICING FORMULAS' by Espen Gaarder Haug. This book provides an in-depth analysis of every function described here. We have just implemented these functions in C++ and extended their functionality to include risk-numbers.
- CapeTools Storage
General Description
Functions that price vanilla and Exotic options using variations of the black-scholes model. These functions create portfolio objects. The benefit of these functions is that there are external functions to sort and group deals. You can mix option contracts from different currencies and finally you can price the whole portfolio a selection of the portfolio in any currency (via an FX manager object).
In addition, each parameter has a range object (excel range) as an input parameter. You can input a single-valued number in a range and if the function detects that the size of the other input ranges are longer, the function will automatically expand the single range to the same size. Every cell will contain the same constant number. This is used heavily within our examples.
You can commit the trades (portfolio) to disk via the numerous range-to XML and XML to range functions present within the 'CapeTools Utils' category of functions.
Once a portfolio has been created, the 'CapeTools Exotic Options Tools' category of functions is responsible for selecting, grouping and pricing these portfolios.
The SubOptionBook() function is responsible for selecting trades via an SQL type criteria and creating a new portfolio object.
The GroupOptionBook() function is responsible for grouping trades via an SQL type criteria and creating a new portfolio object.
The DisplayOptionGroups() function will display the unique columns of the grouped portfolio
The DisplayGRPOptionBook() function will display the trades within the selected group. A list of possible groups can be determined via the said DisplayOptionGroups() function.
The DisplayOptionBook() function will display the trades within a portfolio, sorted on a list of columns.
The PriceOptionBook() function will price the portfolio. This function holds a 'Greek' parameter and this parameter taylors what number are generated.
When priced, you can request the price for the total portfolio, the price of each trade. In addition you can request detailed information for each trade.
All of the functions implemented here have been taken from : 'The Complete Guide To OPTION PRICING FORMULAS' by Espen Gaarder Haug. This book provides an in-depth analysis of every function described here. We have just implemented these functions in C++ and extended their functionality to include risk-numbers.
- CapeTools Stock Option Portfolio
General Description
Functions that price vanilla and Exotic options using variations of the black-scholes model. These functions create portfolio objects. The benefit of these functions is that there are external functions to sort and group deals. You can mix option contracts from different currencies and finally you can price the whole portfolio a selection of the portfolio in any currency (via an FX manager object).
In addition, each parameter has a range object (excel range) as an input parameter. You can input a single-valued number in a range and if the function detects that the size of the other input ranges are longer, the function will automatically expand the single range to the same size. Every cell will contain the same constant number. This is used heavily within our examples.
Note : These functions are very similar to those contained within the 'CapeTools Storage' category of functions except that the parameter that receives dividend rate, foreign rate or holding costs have been dropped. Internally this value is set to zero (0). This simplifies calling these functions and in addition, some of the functions implemented within the 'CapeTools Storage' category cannot have this dividend rate, foreign rate or holding cost parameter set to zero.
You can commit the trades (portfolio) to disk via the numerous range to XML and XML to range functions present within the 'CapeTools Utils' category of functions.
Once a portfolio has been created, the 'CapeTools Exotic Options Tools' category of functions is responsible for selecting, grouping and pricing these portfolios.
The SubOptionBook() function is responsible for selecting trades via an SQL type criteria and creating a new portfolio object.
The GroupOptionBook() function is responsible for grouping trades via an SQL type criteria and creating a new portfolio object.
The DisplayOptionGroups() function will display the unique columns of the grouped portfolio
The DisplayGRPOptionBook() function will display the trades within the selected group. A list of possible groups can be determined via the said DisplayOptionGroups() function.
The DisplayOptionBook() function will display the trades within a portfolio, sorted on a list of columns.
The PriceOptionBook() function will price the portfolio. This function holds a 'Greek' parameter and this parameter taylors what number are generated.
When priced, you can request the price for the total portfolio, the price of each trade. In addition you can request detailed information for each trade.
All of the functions implemented here have been taken from : 'The Complete Guide To OPTION PRICING FORMULAS' by Espen Gaarder Haug. This book provides an in-depth analysis of every function described here. We have just implemented these functions in C++ and extended their functionality to include risk-numbers.
- CapeTools Futures Option Portfolio
General Description
Functions that price vanilla and Exotic options using variations of the black-scholes model. These functions create portfolio objects. The benefit of these functions is that there are external functions to sort and group deals. You can mix option contracts from different currencies and finally you can price the whole portfolio a selection of the portfolio in any currency (via an FX manager object).
In addition, each parameter has a range object (excel range) as an input parameter. You can input a single-valued number in a range and if the function detects that the size of the other input ranges are longer, the function will automatically expand the single range to the same size. Every cell will contain the same constant number. This is used heavily within our examples.
Note : These functions are very similar to those contained within the 'CapeTools Storage' category of functions except that the parameter that receives dividend rate, foreign rate or holding costs have been dropped. Internally this value is set to the same value as the 'rate' parameter. This simplifies calling these functions and in effect prices options on futures.
You can commit the trades (portfolio) to disk via the numerous range to XML and XML to range functions present within the 'CapeTools Utils' category of functions.
Once a portfolio has been created, the 'CapeTools Exotic Options Tools' category of functions is responsible for selecting, grouping and pricing these portfolios.
The SubOptionBook() function is responsible for selecting trades via an SQL type criteria and creating a new portfolio object.
The GroupOptionBook() function is responsible for grouping trades via an SQL type criteria and creating a new portfolio object.
The DisplayOptionGroups() function will display the unique columns of the grouped portfolio
The DisplayGRPOptionBook() function will display the trades within the selected group. A list of possible groups can be determined via the said DisplayOptionGroups() function.
The DisplayOptionBook() function will display the trades within a portfolio, sorted on a list of columns.
The PriceOptionBook() function will price the portfolio. This function holds a 'Greek' parameter and this parameter taylors what number are generated.
When priced, you can request the price for the total portfolio, the price of each trade. In addition you can request detailed information for each trade.
All of the functions implemented here have been taken from : 'The Complete Guide To OPTION PRICING FORMULAS' by Espen Gaarder Haug. This book provides an in-depth analysis of every function described here. We have just implemented these functions in C++ and extended their functionality to include risk-numbers.
- CapeTools Exotic Options Tools
General Description
The SubOptionBook() function is responsible for selecting trades via an SQL type criteria and creating a new portfolio object.
The GroupOptionBook() function is responsible for grouping trades via an SQL type criteria and creating a new portfolio object.
The DisplayOptionGroups() function will display the unique columns of the grouped portfolio
The DisplayGRPOptionBook() function will display the trades within the selected group. A list of possible groups can be determined via the said DisplayOptionGroups() function.
The DisplayOptionBook() function will display the trades within a portfolio, sorted on a list of columns.
The PriceOptionBook() function will price the portfolio. This function holds a 'Greek' parameter and this parameter taylors what number are generated.
You can of make use of the following (in-built) case-insensitive Greek values :
- DELTA
- GAMMA
- VEGA
- VOLGA
- THETA
However have have a more advanced interface for requesting Greeks. Assuming that you know before hand the name of the function that you used to create the portfolio originally and the list of the parameter names, you can request Greek values as so :
First order derivative risk numbers can be requested by simply passing in the name of the parameter (preceded by the 'd' character) into the 'Greek' parameter of these functions (ie - dStock).
Second order derivative risk numbers can be requested by simply passing in the name of the parameter (preceded by the 'd' character) ( repeated twice) into the 'Greek' parameter of these functions (ie - dStockdStock).
Cross derivative risk numbers can be requested by simply passing in the name of the parameters (preceded by the 'd' character) into the 'Greek' parameter of these functions (ie - dStockdTime or dTimedStock).
When pricing options composed of two underlyers, we suggest using this notation rather than the 'DELTA' value for requesting the delta value of the first underlyer parameter.
The risk values computed are the mathematical definition of a derivative (via differentiation). Thus if you wish to compute the risk numbers for a given shift (ie - a one basis point change in the parameter), then you simply multiply the risk number by the requested shift.
When priced, you can request the price for the total portfolio, the price of each trade. In addition you can request detailed information for each trade.
All of the functions implemented here have been taken from : 'The Complete Guide To OPTION PRICING FORMULAS' by Espen Gaarder Haug. This book provides an in-depth analysis of every function described here. We have just implemented these functions in C++ and extended their functionality to include risk-numbers.
- CapeTools Exotic Analysis
General Description
Functions that price vanilla and Exotic options using variations of the black-scholes model. These functions do not create objects ***BUT*** take range-valued parameters. Thus these functions are not as fast as those implemented within the 'CapeTools Exotic Options' category of functions, but are perfect for scenario analysis. These functions return risk numbers for every single double valued parameter (first and second derivatives including cross derivatives). Theta is (of course) computed even though it is a date parameter.
In addition, each parameter has a range object (excel range) as an input parameter. You can input a single-valued number in a range and if the function detects that the size of the other input ranges are longer, the function will automatically expand the single range to the same size. Every cell will contain the same constant number. This is used heavily within our examples.
A great usage for these functions is providing a range of numbers for one parameter while providing a constant value for the other parameters. This way you can see the effect of changing values (for any of the Greek values) over the changing values.
Another use is in constructing option strategies. The following strategies can be easily built using this function :
- Bull Call Spread
- Bull Put Spread
- Bear Call Spread
- Bear Put Spread
- Call Back Spread
- Put Back Spread
- Call Ratio Vertical Spread
- Put Ratio Vertical Spread
- Straddle
- Ratio Straddle
- Strangle
- Ratio Strangle
- Butterfly
- Xmas Tree
- Condor
For reference on these strategies, please refer to the excellent book : Option Volatility and Pricing by Sheldon Natenberg. Some of these strategies have been implemented for the regular black formula (see the 'CapeTools Option Strategy' category for stocks and 'CapeTools Exotic Legs' category for interest rate legs. )
First order derivative risk numbers can be requested by simply passing in the name of the parameter (preceded by the 'd' character) into the 'Greek' parameter of these functions (ie - dStock).
Second order derivative risk numbers can be requested by simply passing in the name of the parameter (preceded by the 'd' character) ( repeated twice) into the 'Greek' parameter of these functions (ie - dStockdStock).
Cross derivative risk numbers can be requested by simply passing in the name of the parameters (preceded by the 'd' character) into the 'Greek' parameter of these functions (ie - dStockdTime or dTimedStock).
You can of course make use of the following (in-built) case-insensitive Greek values :
- DELTA
- GAMMA
- VEGA
- VOLGA
- THETA
However when pricing options composed of two underlyers, we suggest using the former notation for the common risk values.
The risk values computed are the mathematical definition of a derivative (via differentiation). Thus if you wish to compute the risk numbers for a given shift (ie - a one basis point change in the parameter), then you simply multiply the risk number by the requested shift.
All of the functions implemented here have been taken from : 'The Complete Guide To OPTION PRICING FORMULAS' by Espen Gaarder Haug. This book provides an in-depth analysis of every function described here. We have just implemented these functions in C++ and extended their functionality to include risk-numbers.
- CapeTools Derivative Matrix
General Description
Functions that price vanilla and Exotic options using variations of the black-scholes model. These functions do not create objects ***BUT*** generate all the second order (including cross) derivatives and displays the results within a matrix.
The risk values computed are the mathematical definition of a derivative (via differentiation). Thus if you wish to compute the risk numbers for a given shift (ie - a one basis point change in the parameter), then you simply multiply the risk number by the requested shift. Thus for gamma risk (second derivative of the underlying price, for a one unit change of the underlying we multiply by (1^2 = 1). For a one basis point change in the underlying we multiply the results by (0.0001^2).
All of the functions implemented here have been taken from : 'The Complete Guide To OPTION PRICING FORMULAS' by Espen Gaarder Haug. This book provides an in-depth analysis of every function described here. We have just implemented these functions in C++ and extended their functionality to include risk-numbers.
- CapeTools Bump Risk
General Description
Functions that price vanilla and Exotic options using variations of the black-scholes model. These functions do not create objects ***BUT*** take range-valued parameters.
These functions are used to compute the changes in option values given a bump map that will be applied to one input parameter. The bump map can be a single value, a vector or a matrix input and will be simply added to the parameter that is to be bumped. The final result will be deducted from the base value. This function is very useful for scenario analysis.
These functions return risk numbers for every single double valued parameter (first and second derivatives including cross derivatives). Theta is (of course) computed even though it is a date parameter.
In addition, each parameter has a range object (excel range) as an input parameter. You can input a single-valued number in a range and if the function detects that the size of the other input ranges are longer, the function will automatically expand the single range to the same size. Every cell will contain the same constant number. This is used heavily within our examples.
First order derivative risk numbers can be requested by simply passing in the name of the parameter (preceded by the 'd' character) into the 'Greek' parameter of these functions (ie - dStock).
Second order derivative risk numbers can be requested by simply passing in the name of the parameter (preceded by the 'd' character) ( repeated twice) into the 'Greek' parameter of these functions (ie - dStockdStock).
Cross derivative risk numbers can be requested by simply passing in the name of the parameters (preceded by the 'd' character) into the 'Greek' parameter of these functions (ie - dStockdTime or dTimedStock).
You can of course make use of the following (in-built) case-insensitive Greek values :
- DELTA
- GAMMA
- VEGA
- VOLGA
- THETA
However when pricing options composed of two underlyers, we suggest using the former notation for the common risk values.
The risk values computed are the mathematical definition of a derivative (via differentiation). Thus if you wish to compute the risk numbers for a given shift (ie - a one basis point change in the parameter), then you simply multiply the risk number by the requested shift.
All of the functions implemented here have been taken from : 'The Complete Guide To OPTION PRICING FORMULAS' by Espen Gaarder Haug. This book provides an in-depth analysis of every function described here. We have just implemented these functions in C++ and extended their functionality to include risk-numbers.
- CapeTools Option Solver
General Description
These functions are used to solve for the value of a single double-valued parameter given the option premium's price. Volatility is often the most sought after parameter and once solved for, the result is called the implied volatility.
All of the functions implemented here have been taken from : 'The Complete Guide To OPTION PRICING FORMULAS' by Espen Gaarder Haug. This book provides an in-depth analysis of every function described here. We have just implemented these functions in C++ and extended their functionality to include risk-numbers.
- CapeTools Option Strategy
General Description
Prices a portfolio of option strategies on equity type underlyers (using the traditional black-scholes model). Possible option strategies are :
- Bull Call Spread
- Bull Put Spread
- Bear Call Spread
- Bear Put Spread
- Call Back Spread
- Put Back Spread
- Call Ratio Vertical Spread
- Put Ratio Vertical Spread
- Straddle
- Ratio Straddle
- Strangle
- Ratio Strangle
- Butterfly
- Xmas Tree
- Condor
Each row within the portfolio represents one strategy and when priced, you can request the price for the total portfolio, the price of each trade. In addition you can request detailed information for each trade.
- CapeTools Bonds
General Description
Functions for constructing a Bond object given a yieldcurve. You can construct FixedCoupon, FloatingRate, MoneyMarket or ZeroCoupon Bond objects.
You can query and price these bond objects via functions present within the 'CapeTools Query Bonds' category of functions.
- CapeTools Bonds (Yield)
General Description
Functions for constructing a Bond object given a yield-to-maturity value (YTM). You can construct FixedCoupon, FloatingRate, MoneyMarket or ZeroCoupon Bond objects.
In addition you can create currency specific FixedCoupon Bond objects. The following currency specific bonds are supported :
- Australian Commonwealth Government Bond (CGB)
- Austrian Federal Government Bond
- Belgian Government Bond (OLO)
- Canadian Treasury Bond (CANADA)
- Czech Government Bond
- Danish Government Bond (DGB)
- Dutch Government Bond (DSL)
- Finnish Government Bond (MARKKAS)
- French Government Bond (BTAN, OAT)
- German Federal Government Bond (BUND)
- Irish Government Bond (IGBS)
- Italian Government Bond (BTP)
- Japanese Government Bond (JGB)
- New Zealand Government Bond (NZG)
- Norwegian Government Bond
- Portuguese Government Bond (OT)
- South African Government Bond (GILT)
- Spanish Government Bond (BONOS)
- Swedish Government Bond (STATSSOBLIGATIONS)
- Swiss Government Bond (SGB)
- UK Government Bond (GILT)
- US Treasury Bond (TREASURY)
These bonds internally are all FixedCoupon Bond objects with a few of the parameters pre-programmed.
You can query and price these bond objects via functions present within the 'CapeTools Query Bonds' category of functions.
- CapeTools Bonds (Price)
General Description
Functions for constructing a Bond object given the Bond's clean price. You can construct FixedCoupon, FloatingRate, MoneyMarket or ZeroCoupon Bond objects.
In addition you can create currency specific FixedCoupon Bond objects. The following currency specific bonds are supported :
- Australian Commonwealth Government Bond (CGB)
- Austrian Federal Government Bond
- Belgian Government Bond (OLO)
- Canadian Treasury Bond (CANADA)
- Czech Government Bond
- Danish Government Bond (DGB)
- Dutch Government Bond (DSL)
- Finnish Government Bond (MARKKAS)
- French Government Bond (BTAN, OAT)
- German Federal Government Bond (BUND)
- Irish Government Bond (IGBS)
- Italian Government Bond (BTP)
- Japanese Government Bond (JGB)
- New Zealand Government Bond (NZG)
- Norwegian Government Bond
- Portuguese Government Bond (OT)
- South African Government Bond (GILT)
- Spanish Government Bond (BONOS)
- Swedish Government Bond (STATSSOBLIGATIONS)
- Swiss Government Bond (SGB)
- UK Government Bond (GILT)
- US Treasury Bond (TREASURY)
These bonds internally are all FixedCoupon Bond objects with a few of the parameters pre-programmed.
You can query and price these bond objects via functions present within the 'CapeTools Query Bonds' category of functions.
- CapeTools Query Bonds
General Description
Given Bond objects created via the 'CapeTools Bonds (Price)', 'CapeTools Bonds (Yield)' or 'CapeTools Bonds' categories of functions, the functions presented here can query for information or price the bond object.
- CapeTools Municipal Bonds
General Description
Functions for constructing a Municipal Bond object. A Municipal Bond object is really a portfolio of bonds with different maturities. However all the bonds use the same BusinessDayConvention, DayCounter and Coupon Frequency.
There are three Municipal Bond object creation functions. One that takes a YieldCurve, one that takes a clean price and finally one that takes a Yield-To-Maturity value.
Functions for querying and pricing these Municipal Bond objects are also present within this category.
- CapeTools Bond Portfolio
General Description
Functions for constructing a Portfolio of Bond objects.
There are three Portfolio Bond object creation functions. One that takes a YieldCurve, one that takes a clean price and finally one that takes a Yield-To-Maturity value.
Functions for querying and pricing these Portfolio Bond objects are also present within this category.
CapeTools Bond Portfolio Description
- CapeTools Forward Bonds
General Description
Functions for constructing Forward Bond Objects
There are two different functions for constructing Forward Bond objects. One that takes a repo curve (see CapeTools Repo Curves) and the other that takes a flat repo rate.
For functions that return derivative values, for example DRepo(), D2Repo(), DPrice() and D2Price(), the derivatives returned are the mathematically defined definition of a derivative. To convert this mathematical definition into a market move, simply multiply the result for the desired shift.
For example a one basis point change in the repo rate would require you to multiply the derivative value obtained from the DRepo() function by 0.00001 and the derivative value obtained from the D2Repo() function by 0.00001*0.00001.
- CapeTools Bond Options
General Description
Functions for constructing Bond Option Objects
There are two different functions for constructing Bond Option objects within this category. One that takes a repo curve (see CapeTools Repo Curves) and the other that takes a flat repo rate.
The functions presented here price European Bond Options. You will not generate accurate results if your underlying Bond object has any of the following features :
- Amortised Notionals
- Step Up/Down Coupon rates
This is because a Cox-Ross-Rubinstein Binomial Tree Engine is used to price the option and only the Bond Price is used from the Bond Object. The pricing algorithm here does not keep track of amortised/coupon values from cashflow to cashflow.
In addition, you cannot use this function if you require Bermudan type option prices.
In order to overcome these limitations, you need to use the Bond Option functions present within the [TOPIC]CapeTools IREngineOptions[TOPIC] category of functions. The Bond Option functions here utilize term-structure models.
- CapeTools FLOAT Legs
General Description
Creates interest rate floating leg objects. Amortised, Quanto, In-Arrear and constant-maturity-swap legs can be constructed.
Amortised legs can be constructed via the amortised versions of the leg objects or you can provide your own amortised notional values. If you are seeking to construct a regular, non amortised leg, simply pass in a single constant notional value to the notional range parameter.
These leg objects can be priced and queried via functions present within the 'CapeTools Query Legs' category of functions.
- CapeTools FIXED Legs
General Description
Creates interest rate FIXED leg objects. Amortised and non-amortised legs can be constructed.
Amortised legs can be constructed via the amortised versions of the leg objects or you can provide your own amortised notional values. If you are seeking to construct a regular, non amortised leg, simply pass in a single constant notional value to the notional range parameter.
These leg objects can be priced and queried via functions present within the 'CapeTools Query Legs' category of functions.
- CapeTools ZeroCoupon FLOAT Legs
General Description
Creates interest rate FIXED RATE leg objects that receive no cashflows until the maturity date of the leg.
These leg objects can be priced and queried via functions present within the 'CapeTools Query Legs' category of functions.
- CapeTools Averaging FLOAT Legs
General Description
Creates interest rate floating rate leg objects which averages a number of fixings within a paying coupon period. Amortised, Quanto, In-Arrear and constant-maturity-swap legs can be constructed.
Amortised legs can be constructed via the amortised versions of the leg objects or you can provide your own amortised notional values. If you are seeking to construct a regular, non amortised leg, simply pass in a single constant notional value to the notional range parameter.
These leg objects can be priced and queried via functions present within the 'CapeTools Query Legs' category of functions.
- CapeTools Compounding FLOAT Legs
General Description
Creates interest rate floating leg objects that receive no cashflows until the maturity date of the leg. Quanto, In-Arrear and constant-maturity-swap legs can be constructed.
These leg objects can be priced and queried via functions present within the 'CapeTools Query Legs' category of functions.
- CapeTools FIXED + FLOAT Legs
General Description
Creates interest rate inverse floater leg objects. Amortised, Quanto, In-Arrear and constant-maturity-swap floater legs can be constructed.
Amortised legs can be constructed via the amortised versions of the leg objects or you can provide your own amortised notional values. If you are seeking to construct a regular, non amortised leg, simply pass in a single constant notional value to the notional range parameter.
The payoff for this leg is in fact the difference of two coupons. The first a FIXED coupon rate, the second FLOAT rate. Thus for each coupon period, the coupon rate computed will be either a FIXED INVERSE FLOATER LEG [X - N*L] or a FLOAT INVERSE FLOATER LEG [N*L - X], where N is a positive integer gearing amount. N represents the 'FixingGearing' parameter within the function call. X is the FIXED coupon rate and L is the floating rate fixing.
These leg objects can be priced and queried via functions present within the 'CapeTools Query Legs' category of functions.
- CapeTools FIXED + AVERAGE FLOAT Legs
General Description
Creates interest rate inverse floater leg objects. Amortised, Quanto, In-Arrear and constant-maturity-swap floater legs can be constructed.
Amortised legs can be constructed via the amortised versions of the leg objects or you can provide your own amortised notional values. If you are seeking to construct a regular, non amortised leg, simply pass in a single constant notional value to the notional range parameter.
The payoff for this leg is in fact the difference of two coupons. The first a FIXED coupon rate, the second averages a number of fixings within the same paying coupon period. Thus for each coupon period, the coupon rate computed will be either a FIXED INVERSE FLOATER LEG [X - N*L] or a FLOAT INVERSE FLOATER LEG [N*L - X], where N is a positive integer gearing amount. N represents the 'FixingGearing' parameter within the function call. X is the FIXED coupon rate and L is the average of a number of fixings within the period.
These leg objects can be priced and queried via functions present within the 'CapeTools Query Legs' category of functions.
- CapeTools FIXED + COMPOUNDING FLOAT Legs
General Description
Creates interest rate inverse floater leg objects. Amortised, Quanto, In-Arrear and constant-maturity-swap floater legs can be constructed.
Amortised legs can be constructed via the amortised versions of the leg objects or you can provide your own amortised notional values. If you are seeking to construct a regular, non amortised leg, simply pass in a single constant notional value to the notional range parameter.
The payoff for this leg is in fact the difference of two coupons. The first a FIXED coupon rate, the second compounds a number of fixings within the same paying coupon period. Thus for each coupon period, the coupon rate computed will be either a FIXED INVERSE FLOATER LEG [X - N*L] or a FLOAT INVERSE FLOATER LEG [N*L - X], where N is a positive integer gearing amount. N represents the 'FixingGearing' parameter within the function call. X is the FIXED coupon rate and L is the result of a number of fixings compounded within the payment period.
These leg objects can be priced and queried via functions present within the 'CapeTools Query Legs' category of functions.
- CapeTools Exotic Legs
General Description
Creates an interest rate option strategy based on an floating interest rate leg (or an inverse floating leg). (using the traditional black model on futures). Possible option strategies are :
- Cap
- Floor
- Cap And Floor
- Bull Call Spread
- Bull Put Spread
- Bear Call Spread
- Bear Put Spread
- Butterfly
- Call Back Spread
- Put Back Spread
- Call Ratio Vertical Spread
- Put Ratio Vertical Spread
- Condor
- Straddle
- Strangle
- Xmas Tree
Each of the strategy above will be applied to each cashflow of the underlying leg.
In-Arrear legs on non-CMS indexes are not currently supported under this framework.
- CapeTools Query Legs
General Description
Functions to query for information given a leg object.
There are functions to query the details of a floating or fixed leg object. The underlying legs must have been created via leg creation functions within the following categories :
There are functions to display various cashflow details from the leg object as well as pricing the leg object.
In addition you can use the CreateStructure function to create a portfolio of leg objects
From this leg portfolio, you can solve for the flat coupon rate or flat margin rate across all the legs.
Furthermore, you can pass the object created from the CreateStructure function to the functions present within the CapeTools IR Risk category of functions in order to run complex interest rate risk analysis.
The CreateStructure function can take in objects created within the following category of functions :
However not all the legs (objects) created from these categories of functions are compatible for solving a flat margin/fixed coupon rate across all the legs (objects). The former list above lists the category of functions that satisfies this criterion.
From either of these lists, you can execute the PrcStructure function in order to see the aggregated PV.
Again interest rate risk can be conducted via the functions present within the CapeTools IR Risk category of functions.
- CapeTools Swaps
General Description
Functions to construct Swap Objects.
The types of swap objects that can be constructed are :
- FIX vs FIX
- FIX vs FLOAT
- FLOAT vs FLOAT
You can use the functions present within the CapeTools Query Swaps category of functions to query for information from these swap objects.
Please note that the SwapFIXFLT2 and SwapFIXFIX2 functions cannot be accessed from the Excel libraries because these functions have more than 21 argument parameters. Excel has a maximum limit of 20 parameters per function.
- CapeTools Query Swaps
General Description
Functions to query for information given a swap object.
The swap objects must have been created via the CapeTools Swaps category of functions.
There are functions to display detailed information regarding any of the legs contained within the swap structure as well as pricing the leg object.
- CapeTools Leg Portfolio
General Description
Functions to construct a portfolio of legs (Floating rate and Fixed rate leg).
In addition you can query for the total PV of the portfolio, the PV for each individual deal, basis point value (BPV) for the total portfolio, and the BPV for each individual deal.
Given an ID of a contract within the portfolio, you can request for more detailed information (a breakdown of the instrument cashflows).
- CapeTools Swap Portfolio
General Description
Functions to construct a portfolio of swaps (same currency).
In addition you can query for the total PV of the portfolio, the PV for each individual deal, basis point value (BPV) for the total portfolio, and the BPV for each individual deal.
Given an ID of a contract within the portfolio, you can request for more detailed information (a breakdown of the instrument cashflows).
- CapeTools Basis Swap Portfolio
General Description
Functions to construct a portfolio of interest rate basis swaps.
In addition you can query for the total PV of the portfolio, the PV for each individual deal, basis point value (BPV) for the total portfolio, and the BPV for each individual deal.
Given an ID of a contract within the portfolio, you can request for more detailed information (a breakdown of the instrument cashflows).
- CapeTools XCcy Swap Portfolio
General Description
Functions to construct a portfolio of cross-currency swaps.
In addition you can query for the total PV of the portfolio, the PV for each individual deal, basis point value (BPV) for the total portfolio, and the BPV for each individual deal.
Given an ID of a contract within the portfolio, you can request for more detailed information (a breakdown of the instrument cashflows).
- CapeTools CDS Swap Portfolio
General Description
Functions to construct a portfolio of regular and binary Credit Default Swap instruments.
In addition you can query for the total PV of the portfolio, the PV for each individual deal, basis point value (BPV) for the total portfolio, and the BPV for each individual deal.
Given an ID of a contract within the portfolio, you can request for more detailed information (a breakdown of the instrument cashflows).
- CapeTools CapFloor Portfolio
General Description
Functions to construct a portfolio of vanilla Cap/Floor instruments.
In addition you can query for the total PV of the portfolio and also the PV for each individual deal.
Given an ID of a contract within the portfolio, you can request for more detailed information.
There is also a function to construct a portfolio of Cap/Floor instruments where the prices are already known. From this one can request for the implied volatility for each Cap/Floor instrument.
- CapeTools Swaption Portfolio
General Description
Functions to construct a portfolio of vanilla swaption instruments.
In addition you can query for the total PV of the portfolio and also the PV for each individual deal.
Given an ID of a contract within the portfolio, you can request for more detailed information.
There is also a function to construct a portfolio of swaption instruments where the prices are already known. From this one can request for the implied volatility for each swaption instrument.
- CapeTools IR Risk
General Description
Functions to compute detailed interest rate risk analysis on a portfolio of deal types.
All of these reports take a Structure object which is created via the CreateStructure function.
A structure object can contain object deals created from the following categories of functions :
The following types of YieldCurve risk reports can be constructed :
The Gamma report contains all the information that the Delta report does.
YieldCurve risk is conducted by first identifying the points within the yieldcurve that all the deals within the structure object are sensitive to.
Then these points are bumped and all the deals repriced. Delta and/or Gamma risk is then computed and stored. Functions within the CapeTools Query IR Risk category of functions are then used to display the generated risk number for either all deals or a user-defined criteria.
The following types of VolCurve risk reports can be constructed :
The Volga report contains all the information that the Vega report does.
VolCurve risk is conducted by first identifying the points within the VolCurve that all the deals within the structure object are sensitive to.
Then these points are bumped and all the deals repriced. Vega and/or Volga (second derivative) risk is then computed and stored. Functions within the CapeTools Query IR Risk category of functions are then used to display the generated risk number for either all deals or a user-defined criteria.
These risk reports can be expensive (in time) especially for large portfolios and so the following functions can be used to read/write the internal state of any of the 5 risk reports above to a file.
These functions are useful for archiving risk reports or to quickly read a risk report in and then apply the same risk analysis one would normally do using the functions present within the CapeTools Query IR Risk category of functions.
The CreateSABRReport() is an very useful report as you can specify any of the three SABR parameters ('ALPHA', 'BETA' and 'RHO').
If the underlying VolCurve that is passed to the VegaRiskReport or VolgaRiskReport is a SABRVolCurve object that you will have realistic movement within the interest rate volatility smile than that of using the ExpiryKVolMatrix or ATMVolMatrix VolCurve objects. Normally when the At-The-Money volatility is bumped by 0.01, for example, the volatility smile does not move by 0.01 at all points. Traditional methods of bumping each point by 0.01 do not give a realistic movement of the volatility smile. The SABRVolCurve object captures this dynamic movement.
- CapeTools Query IR Risk
General Description
Functions to query risk reports produced by functions within the CapeTools IR Risk category of functions. There are four types of query functions within this category of functions.
The first are functions to query the report itself (Report functions). The types of legs, the list of legs and if one were to execute the QueryVCRiskReport() and QueryVCRiskReport() functions, which legs will be selected for the report.
The second category of functions are those that go out and actually produce the risk numbers (Query functions). These functions employ a kind of database SQL method in order to retrieve and aggregate the interest rate reports.
The third type of functions are those that act upon the YieldCurve or VolCurve that are to be manipulated (Curve functions). These functions simply returns a sensitivity curve/matrix of the instruments underlying the curves.
Finally the fourth type of functions are those that do not act upon the report itself, but rather the structure object (Structure functions). These functions simply report which legs within the structure object are sensitive to which curves (Yieldcurve or/and VolCurves).
Report functions are functions that help in determining the types of legs, leg types that are present within the report.
The following (Structure) functions provide a type of heat-map of the points that are to be manipulated during the construction of a riskreport (functions wihin the CapeTools IR Risk category of functions) :
Basically these functions take your structure object (generated via the CreateStructure() function) and the curve that is to be bumped and counts how many times each point within the curve (YieldCurve or VolCurve) are accessed. Thus you can see the points on the curve that have the largest concentration of activity given a structure.
The following (Structure) functions will display the list of legs within a structure object that are sensitive to the given curve (YieldCurve or VolCurve) :
The RiskGetYCVCSenLegs() function is quite interesting as it will return the list of legs that are sensitive to both the given VolCurve and YieldCurve.
The following (Curve) functions will display the sensitivity curve (in the case of a YieldCurve) or sensitivity matrix (in the case of a VolCurve) of the instruments underlying the curve. Thus for the 10Y Tenor within the YieldCurve, this will be the sensitivity (delta) of the 10 year swap rate from spot. For the 5Y into 10Y Volatility point on a SABR VolCurve, this will be the sensitivity (vega) of an At-The-Money 5Y into 10Y Swaption instrument :
The risk reports also store these sensitivity values and they can be extracted via the following functions (given a report object) :
These value are needed in order to output different risk report numbers (notional of the hedge instrument for example.)
The following (Report) functions list the leg names that are stored within the report :
These legs should correspond to the list of legs passed to the CreateStructure() function.
Each leg within a report is assigned a leg type. For example all legs created via functions contained within the 'CapeTools FLOAT Legs' category of functions are given a type of 'FLOAT'. When querying the risk reports you can supply a list of leg names, leg types or both.
Thus it is important to remember that a Leg-Name is an identifier for a single deal.
A Leg-Type however is a group of Leg-Names and thus is an identifier for a group of deals.
The following list provides the leg type assigned to the functions stored within the given function categories or functions :
The following (Report) functions will display the leg types given a risk report :
The following (Report) functions go further and display a two column range of LegName and the type associated with it :
The following (Report) functions will display a list of Leg-Name, given a Leg-Type. Thus if you pass in the type 'FLOAT', all objects created from the CapeTools FLOAT Legs category of functions and that have been processed by the risk report will be displayed :
From a combination of using the following functions above, you may have decided on a list of Leg-Names and/or Leg-Types that you wish to view a report from. You may also wish to see the whole list, but exclude certain Leg-Names and/or Leg-Types. Which legs will actually be selected given all the possible combinations?
The following list of (Report) functions allows you to view the resulting legs given Leg-Names and/or Leg-Types combinations with an exclusion criteria :
A powerful parameter to note is the 'Operation' parameter. Basically These functions take three lists :
- List of Leg-Names to view
- List of Leg-Types to view
- List of Leg-Names to exclude
How does the function, given this list, decide which legs to accept from the report and which legs to exclude?
This is where the 'Operation' parameter comes into play and takes on the following values, "And", "Or" and "Diff".
If the 'Operation' parameter is set to "And" then all the legs present in **BOTH** the Leg-Names (LimitToLegs parameter) **AND** Leg-Types (LimitToTypes parameter) are taken. Then the legs that are not wanted are excluded (ExcludeLegs parameter).
If the 'Operation' parameter is set to "Or" then all the legs present in **EITHER** the Leg-Names (LimitToLegs parameter) **OR** Leg-Types (LimitToTypes parameter) are taken. Then the legs that are not wanted are excluded (ExcludeLegs parameter).
If the 'Operation' parameter is set to "Diff" then basically we select all the legs within the report, apply the **AND** operator to generate a sub-list, throw away this sub-list and select whatever is left. Then the legs that are not wanted are excluded (ExcludeLegs parameter).
Executing the QueryLegsYCRiskReport or QueryLegsVCRiskReport will help you to ensure that you are using the correct logic when trying to compose a list of legs to base your report on.
Finally the following (Query) functions will apply a selection criteria to the generated report and list the risk numbers that you are requesting :
The parameters are similar to that of the QueryLegsYCRiskReport and QueryLegsVCRiskReport functions except that you also provide how you would like to see your risk numbers.
In the case of a Gamma or Volga Report, you can also request for Delta and Vega results as these are computed as well.
- CapeTools Simple Processes
General Description
Functions to construct various Equity, Future, FX or Commodity type process objects. A process object simulates an asset value (or a correlated set of asset values) over time.
The following asset functions can be used :
- GBSProcess() -Generalized BlackScholes Process.
- BS73Process() - Black-Scholes (1973) stochastic process.
- BlackProcess() - Black (1976) stochastic process.
- GKProcess() - Garman-Kohlhagen (1983) stochastic process.
- Merton76Process() - Merton (1976) Process.
Some basic stochastic process objects that can be constructed are :
- GBMProcess() - Geometric Brownian Motion Process.
- OUProcess() - OrnsteinUhlenbeck Process.
- SQRTProcess() - Square Root Process.
- SQRTProcess() - Square Root Process.
Finally you can group a collection of stochastic process objects along with a correlation matrix via the following function :
- CorrArrayProcesses() - Creates an array of correlated one dimensional stochastic processes.
All of these objects can be passed to various pricing functions (see the CapeTools EngineOptions category of functions).
You can set up your own simulation of these processes by using the functions contained within the CapeTools (Full) Process Simulation or CapeTools (Compact) Process Simulation category of functions.
Additionally you can carry out your own generic pricing via the GenericMCPricer, GenericTreePricer or GenericPDEPricer functions.
- CapeTools LMM Processes
General Description
Functions to construct Libor Market Model simulation process objects.
Given Libor Libor Market Model volatility and correlation specification objects (see CapeTools EngineOptions), creates a Libor Forward Market Simulation Process object to be used within the CapeTools LMM Process Simulation or CapeTools Generic IR LMM MonteCarlo Pricer category of functions.
Volatility and correlation specification objects can be produced via a call to any of the appropriate functions within the CapeTools LMM Volatility/Correlation Models category of functions.
Within the LMMSimProcess function, you can set the number of simulations to zero (0). In this case no simulations will be generated, but you can request a new simulation path from this object by executing the LMMNextPath function. This will return a 2 column array of rates and discount factors. You can also perform generic montecarlo pricing via the GenericLMM_MCPricer function.
- CapeTools IR Processes
General Description
Functions to construct short-rate model simulation process objects.
Currently, we only have one model defined and that is a single-factor Hull-White (extended Vasicek) Forward short-rate Model process object. Defined as : dr_t = (theta(t) - alpha*r_t)dt + sigma*dW_t, where alpha and sigma are constants
You can set up your own simulation of these processes by using the functions contained within the CapeTools (Full) IR Process Simulation or CapeTools (Compact) IR Process Simulation category of functions.
- CapeTools (Full) Process Simulation
General Description
Functions to construct and simulate Equity, Future, FX or Commodity type stochastic processes.
The (Full) indicates that if one wishes to conduct 50000 simulations, all 50000 simulations will be simulated in one shot, via the ProcessViewer function.
All further functions that refers to the object constructed by the ProcessViewer function simply reads data from the object. No further simulation takes place.
The benefit of this method is that enough information is returned for you to conduct your own customised monte-carlo pricing within your own environment (you can additionally use the functions present within the CapeTools Generic MonteCarlo Pricer category of functions.). Because all the paths are retained, with a little more work, you can compute the risk parameters of your product (not present within the CapeTools Generic MonteCarlo Pricer category of functions.)
Unfortunately, this object will utilize a lot of memory if you specify a huge amount of paths to be simulated.
You may want to use the DeleteObject() function to remove the simulation object from memory once you have priced you product.
Alternatively, you may want to use the functions present within the CapeTools (Compact) Process Simulation category of functions. Here each time you execute the MCNextStep function from a constructed StepMonteCarlo object a new path is generated and the previous path destroyed.
This uses less memory, but makes it difficult for you to compute risk numbers using the original paths.
- CapeTools (Compact) Process Simulation
General Description
Functions to construct and simulate Equity, Future, FX or Commodity type stochastic processes.
The (Compact) indicates that a single path will be simulated each time you call the MCNextStep function from a constructed StepMonteCarlo object.
The benefit of this method is that enough information is returned for you to conduct your own customised monte-carlo pricing within your own environment.
However it would be difficult to compute risk numbers as the original path would have been wiped from memory (if generating risk via perturbation).
Alternatively, you may want to use the functions present within the CapeTools (Full) Process Simulation category of functions. Under this scenario, if one wishes to conduct 50000 simulations, all 50000 simulations will be simulated in one shot, via the ProcessViewer function and all the paths are stored.
However you may want to use the DeleteObject() function to remove the simulation object from memory once you have priced you product.
- CapeTools (Full) IR Process Simulation
General Description
Functions to construct and simulate interest rate type stochastic processes.
The (Full) indicates that if one wishes to conduct 50000 simulations, all 50000 simulations of LIBOR paths will be simulated in one shot, via the IRProcessViewer function.
All further functions that refers to the object constructed by the IRProcessViewer function simply reads data from the object. No further simulation takes place.
The benefit of this method is that enough information is returned for you to conduct your own customised monte-carlo pricing within your own environment. Because all the paths are retained, with a little more work, you can compute the risk parameters of your product.
Unfortunately, this object will utilize a lot of memory if you specify a huge amount of paths to be simulated.
You may want to use the DeleteObject() function to remove the simulation object from memory once you have priced you product.
Alternatively, you may want to use the functions present within the CapeTools (Compact) IR Process Simulation category of functions. Here each time you execute the IRMCNextStep function from a constructed IRStepMonteCarlo object a new LIBOR path is generated and the previous path destroyed.
This uses less memory, but makes it difficult for you to compute risk numbers using the original paths.
- CapeTools (Compact) IR Process Simulation
General Description
Functions to construct and simulate interest rate type stochastic processes.
The (Compact) indicates that a single LIBOR path will be simulated each time you call the IRMCNextStep function from a constructed IRStepMonteCarlo object.
The benefit of this method is that enough information is returned for you to conduct your own customised monte-carlo pricing within your own environment.
However it would be difficult to compute risk numbers as the original path would have been wiped from memory (if generating risk via perturbation).
Alternatively, you may want to use the functions present within the CapeTools (Full) IR Process Simulation category of functions. Under this scenario, if one wishes to conduct 50000 simulations, all 50000 simulations of LIBOR paths will be simulated in one shot, via the IRProcessViewer function and all the paths are stored.
However you may want to use the DeleteObject() function to remove the simulation object from memory once you have priced you product.
- CapeTools LMM Process Simulation
General Description
Functions to construct and simulate interest rate type stochastic processes under the LMM model.
A single LIBOR path will be simulated each time you call the LMMNextPath function from a constructed LMMSimProcess object.
The benefit of this method is that enough information is returned for you to conduct your own customised monte-carlo pricing within your own environment.
However it would be difficult to compute risk numbers as the original path would have been wiped from memory (if generating risk via perturbation).
Alternatively, if you specified a number for the 'NoOfSims' parameter within the LMMSimProcess function, then under this scenario, if one wishes to conduct 50000 simulations, all 50000 simulations of LIBOR paths will be simulated in one shot and stored.
You then use a series of functions to extract information from the stored paths ( ie - LMMDisplayPath, LMMDisplayStep etc...).
However you may want to use the DeleteObject() function to remove the simulation object from memory once you have priced you product.
- CapeTools Generic PDE Pricer
General Description
Functions to price generic Equity/FX/Commodity structures under a PDE framework. If your product's payoff does not refer to asset prices in the past (ie - Asian options) you can use this framework. This framework can also handle bermudan callable structures
Here are some general rules to keep in mind regarding how the payoff grid will be processed :
- Rows are time points. As you read down the grid you are moving forward in time.
- Columns represent your payoff formulas. You can create as many columns as you like. Columns are there to help you split up your payoff, or for a payoff function within a cell to refer to other cells within the grid.
- For the PDE pricer, the pricing starts at the final timestep and prices from left to right.
- Formula expressions within a cell cannot refer to formula cells to the right of itself.
- Formula expressions within a cell cannot refer to formula cells above itself (past time points).
If you bear the 5 points in mind, this should aid you in constructing payoff grids.
Below is an example of a payoff table. This deal prices a callable structure (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | PayOff Col | PayOff Col | PayOff Col | PayOff Col |
|---|
| 1 | #19/07/2005# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 2 | #19/01/2006# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 3 | #19/07/2006# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 4 | #19/01/2007# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 5 | #19/07/2007# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 6 | #19/01/2008# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 7 | #19/07/2008# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 8 | #19/01/2009# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 9 | #19/07/2009# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 10 | #19/01/2010# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 11 | #19/07/2010# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 12 | #19/01/2011# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
The 'Repeat' column indicates that the instruction at the current step will be repeated for all the timesteps between this and the next.
Even though there are only 12 timesteps above, you can instruct the function to insert additional steps between each step.
Financial variables (case sensitive) :
- cRow - refers to the current Row with the payoff table. Within all the Financial functions listed below, we recommend that you always use this variable (with perhaps offset values, ie - cRow, cRow-1, cRow+2 etc...) instead of a fixed value (ie - 1, 2 etc...). This is important especially if you enable American type handling from one timestep to another. Using static integer values will generate incorrect results.
- cCol - refers to the current Column with the payoff table. Within all the financial functions listed below, we recommend that you always use this variable (with perhaps offset values, ie - cCol, cCol-1, cCol+2 etc...).
- pct - When an integer value is placed in front of this expression (no spaces), the function will interp the whole expression as a percent. (ie - 5pct => 0.05)
- bp - When an integer value is placed in front of this expression (no spaces), the function will interp the whole expression as basis points. (ie - 5bp => 0.0005)
- _XXX - Constant variables can be defined by filling in the 'ConstParams' parameter of the GenericPDEPricer() function. All variables must be defined with a leading underscore character ( ie - _XXX = 0.5)
Financial functions (case sensitive) :
- Asset(row) - Returns the asset value at the integer row indicated. Starts at 1. You may refer to future values of the asset's price because the PDE methodology prices backwards in time (from the last expiry date). The expression 'Asset(cRow)' retrieves the asset price for the current timestep. The expression 'Asset(cRow+1)' retrieves the asset price for the next timestep (in the future).
- Cell(row, col) - Retrieves a computed value within the PayOff Table. You can only refer to rows and columns below and to the left of the current cell location. You can also refer to the current cell location. This is because the PDE pricer prices backwards in time and thus past payoff values have not been computed as yet. The expression 'Cell(cRow, cCol-1)' retrieves the payoff value for the current timestep but at the previous column.
- GridRowMin(Row, startCol, endCol) - Retrieves the minimum value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowMax(Row, startCol, endCol) - Retrieves the maximum value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowAvg(Row, startCol, endCol) - Retrieves the average value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowSum(Row, startCol, endCol) - Retrieves the sum across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- Interp1D(nIndex, XValue ) - If any 1D interpolation objects have been passed into GenericPDEPricer() function (a maximum of 2 objects can be defined), then you can execute this function within your payoff grid. The 'nIndex' parameter refers to the intepolation object (1-based). 'XValue' is the value where the interpolation is to be performed. The interpolation object will not extrapolate values.
- Interp2D(nIndex, XValue, YValue) - If any 2D interpolation objects have been passed into GenericPDEPricer() function (a maximum of 2 objects can be defined), then you can execute this function within your payoff grid. The 'nIndex' parameter refers to the intepolation object (1-based). 'XValue' and 'YValue' are the values where the interpolation is to be performed. The interpolation object will not extrapolate values.
- iff(condition, a, b) - Tests for the condition and returns the value of 'a' if true or 'b' if false.
- PVCol(Column) - Requests the PV value of the indicated column up to the current step (cRow). This function must be used when pricing Bermudan / American type products.
Predefined functions (case sensitive) :
- sin(x) ( sine function )
- cos(x) ( cosine function )
- tan(x) ( tangens function )
- asin(x) ( arcus sine function )
- acos(x) ( arcus cosine function )
- atan(x) ( arcus tangens function )
- sinh(x) ( hyperbolic sine function )
- cosh(x) ( hyperbolic cosine function )
- tanh(x) ( hyperbolic tangens function )
- asinh(x) ( hyperbolic arcus sine function )
- acosh(x) ( hyperbolic arcus cosine function )
- atanh(x) ( hyperbolic arcur tangens function )
- log2(x) ( logarithm to the base 2 )
- log10(x) ( logarithm to the base 10 )
- log(x) ( logarithm to the base 10 )
- ln(x) ( logarithm to the base e (2.71828...)
- exp(x) ( e raised to the power of x )
- sqrt(x) ( square root of a value )
- sign(x) ( sign function ) -1=(if x<0), 1=(if x>0 )
- rint(x) ( round to nearest integer )
- abs(x) ( absolute value )
- min(a,b,c,d,e,...) ( min of all arguments ie - min(-2,1,5,-6) )
- max(a,b,c,d,e,...) ( max of all arguments ie - max(-2,1,5,-6) )
- sum(a,b,c,d,e,...) ( sum of all arguments ie - sum(-2,1,5,-6) )
- avg(a,b,c,d,e,...) ( mean value of all arguments ie - avg(-2,1,5,-6) )
- ite(x,y,z) ( if ... then ... else ... : ie - ite(a<b, 5.0, -3.0) )
Predefined operators :
- + ( addition )
- - ( subtraction )
- * ( multiplication )
- / ( division )
- ^ ( raise x to the power of y )
Predefined operators that can be used within the first parameter of the ite() or iff() function :
- and ( logical and )
- or ( logical or )
- <= ( less or equal )
- >= ( greater or equal )
- != ( not equal )
- == ( equal to )
- > ( greater than )
- < ( less than )
- Brackets, '(' and ')', can also be used to simplify expressions.
Some possible examples of what is possible now follow (Today = 19/07/2005):
Vanilla Option. (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2006# | FALSE | max(Asset(cRow) - 10, 0) | |
Sum of two Vanilla Options (Call and Put). (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2006# | FALSE | 100 | max(Asset(cRow) - Cell(cRow, cCol-1), 0) + PVCol(cCol) |
| 2 | #19/07/2007# | FALSE | 90 | max(Cell(cRow, cCol-1) - Asset(cRow), 0) |
American Option (Repeat column and PVCol() function are used differently). (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2005# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 1 | #19/07/2006# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
Delayed start American Option (starts at 19/10/2005, today is 19/07/2005). (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/10/2005# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 1 | #19/10/2006# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
Bermudan Option. (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2005# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 2 | #19/01/2006# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 3 | #19/07/2006# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 4 | #19/01/2007# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 5 | #19/07/2007# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 6 | #19/01/2008# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 7 | #19/07/2008# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 8 | #19/01/2009# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 9 | #19/07/2009# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
Starts as American then becomes Bermudan Option. (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2005# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 2 | #19/01/2006# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 3 | #19/07/2006# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 4 | #19/01/2007# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 5 | #19/07/2007# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 6 | #19/01/2008# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 7 | #19/07/2008# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 8 | #19/01/2009# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 9 | #19/07/2009# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
Chooser Option. (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | PayOff Col | |
|---|
| 1 | #19/07/2005# | FALSE | | max(PVCol(cCol-1), PVCol(cCol)) | |
| 2 | #19/07/2006# | FALSE | max(Asset(cRow) - 10, 0) | max(10 - Asset(cRow), 0) | |
Compound Option (european on european). (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2006# | FALSE | max(8.0 - PVCol(cCol), 0) | |
| 2 | #19/01/2007# | FALSE | max(Asset(cRow) - 10, 0) | |
Compound Option (european on american, delayed by 2 days). (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2006# | FALSE | max(8.0 - PVCol(cCol), 0) | |
| 2 | 21/07/2006# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 3 | #19/07/2008# | FALSE | max(Asset(cRow) - 10, 0) | |
- CapeTools Generic Tree Pricer
General Description
Functions to price generic Equity/FX/Commodity structures under a Binomial Tree framework. If your product's payoff does not refer to asset prices in the past (ie - Asian options) you can use this framework. This framework can also handle bermudan callable structures
Here are some general rules to keep in mind regarding how the payoff grid will be processed :
- Rows are time points. As you read down the grid you are moving forward in time.
- Columns represent your payoff formulas. You can create as many columns as you like. Columns are there to help you split up your payoff, or for a payoff function within a cell to refer to other cells within the grid.
- For the Binomial Tree pricer, the pricing starts at the final timestep and prices from left to right.
- Formula expressions within a cell cannot refer to formula cells to the right of itself.
- Formula expressions within a cell cannot refer to formula cells above itself (past time points).
If you bear the 5 points in mind, this should aid you in constructing payoff grids.
Below is an example of a payoff table. This deal prices an callable structure (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | PayOff Col | PayOff Col | PayOff Col | PayOff Col |
|---|
| 1 | #19/07/2005# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 2 | #19/01/2006# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 3 | #19/07/2006# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 4 | #19/01/2007# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 5 | #19/07/2007# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 6 | #19/01/2008# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 7 | #19/07/2008# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 8 | #19/01/2009# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 9 | #19/07/2009# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 10 | #19/01/2010# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 11 | #19/07/2010# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
| 12 | #19/01/2011# | FALSE | Asset(cRow) + 10pct | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(Cell(cRow, cCol-1) - _var1, 0.0) | max(Cell(cRow, cCol-1), PVCol(cCol)) |
The 'Repeat' column indicates that the instruction at the current step will be repeated for all the timesteps between this and the next.
Even though there are only 12 timesteps above, you can instruct the function to insert additional steps between each step.
Financial variables (case sensitive) :
- cRow - refers to the current Row with the payoff table. Within all the Financial functions listed below, we recommend that you always use this variable (with perhaps offset values, ie - cRow, cRow-1, cRow+2 etc...) instead of a fixed value (ie - 1, 2 etc...). This is important especially if you enable American type handling from one timestep to another. Using static integer values will generate incorrect results.
- cCol - refers to the current Column with the payoff table. Within all the financial functions listed below, we recommend that you always use this variable (with perhaps offset values, ie - cCol, cCol-1, cCol+2 etc...).
- pct - When an integer value is placed in front of this expression (no spaces), the function will interp the whole expression as a percent. (ie - 5pct => 0.05)
- bp - When an integer value is placed in front of this expression (no spaces), the function will interp the whole expression as basis points. (ie - 5bp => 0.0005)
- _XXX - Constant variables can be defined by filling in the 'ConstParams' parameter of the GenericTreePricer() function. All variables must be defined with a leading underscore character ( ie - _XXX = 0.5)
Financial functions (case sensitive) :
- Asset(row) - Returns the asset value at the integer row indicated. Starts at 1. You may refer to future values of the asset's price because the Tree methodology prices backwards in time (from the last expiry date). The expression 'Asset(cRow)' retrieves the asset price for the current timestep. The expression 'Asset(cRow+1)' retrieves the asset price for the next timestep (in the future).
- Cell(row, col) - Retrieves a computed value within the PayOff Table. You can only refer to rows and columns below and to the left of the current cell location. You can also refer to the current cell location. This is because the Tree pricer prices backwards in time and thus past payoff values have not been computed as yet. The expression 'Cell(cRow, cCol-1)' retrieves the payoff value for the current timestep but at the previous column.
- GridRowMin(Row, startCol, endCol) - Retrieves the minimum value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowMax(Row, startCol, endCol) - Retrieves the maximum value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowAvg(Row, startCol, endCol) - Retrieves the average value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowSum(Row, startCol, endCol) - Retrieves the sum across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- Interp1D(nIndex, XValue ) - If any 1D interpolation objects have been passed into GenericTreePricer() function (a maximum of 2 objects can be defined), then you can execute this function within your payoff grid. The 'nIndex' parameter refers to the intepolation object (1-based). 'XValue' is the value where the interpolation is to be performed. The interpolation object will not extrapolate values.
- Interp2D(nIndex, XValue, YValue) - If any 2D interpolation objects have been passed into GenericTreePricer() function (a maximum of 2 objects can be defined), then you can execute this function within your payoff grid. The 'nIndex' parameter refers to the intepolation object (1-based). 'XValue' and 'YValue' are the values where the interpolation is to be performed. The interpolation object will not extrapolate values.
- iff(condition, a, b) - Tests for the condition and returns the value of 'a' if true or 'b' if false.
- PVCol(Column) - Requests the PV value of the indicated column up to the current step (cRow). This function must be used when pricing Bermudan / American type products.
Predefined functions (case sensitive) :
- sin(x) ( sine function )
- cos(x) ( cosine function )
- tan(x) ( tangens function )
- asin(x) ( arcus sine function )
- acos(x) ( arcus cosine function )
- atan(x) ( arcus tangens function )
- sinh(x) ( hyperbolic sine function )
- cosh(x) ( hyperbolic cosine function )
- tanh(x) ( hyperbolic tangens function )
- asinh(x) ( hyperbolic arcus sine function )
- acosh(x) ( hyperbolic arcus cosine function )
- atanh(x) ( hyperbolic arcur tangens function )
- log2(x) ( logarithm to the base 2 )
- log10(x) ( logarithm to the base 10 )
- log(x) ( logarithm to the base 10 )
- ln(x) ( logarithm to the base e (2.71828...)
- exp(x) ( e raised to the power of x )
- sqrt(x) ( square root of a value )
- sign(x) ( sign function ) -1=(if x<0), 1=(if x>0 )
- rint(x) ( round to nearest integer )
- abs(x) ( absolute value )
- min(a,b,c,d,e,...) ( min of all arguments ie - min(-2,1,5,-6) )
- max(a,b,c,d,e,...) ( max of all arguments ie - max(-2,1,5,-6) )
- sum(a,b,c,d,e,...) ( sum of all arguments ie - sum(-2,1,5,-6) )
- avg(a,b,c,d,e,...) ( mean value of all arguments ie - avg(-2,1,5,-6) )
- ite(x,y,z) ( if ... then ... else ... : ie - ite(a<b, 5.0, -3.0) )
Predefined operators :
- + ( addition )
- - ( subtraction )
- * ( multiplication )
- / ( division )
- ^ ( raise x to the power of y )
Predefined operators that can be used within the first parameter of the ite() or iff() function :
- and ( logical and )
- or ( logical or )
- <= ( less or equal )
- >= ( greater or equal )
- != ( not equal )
- == ( equal to )
- > ( greater than )
- < ( less than )
- Brackets, '(' and ')', can also be used to simplify expressions.
Some possible examples of what is possible now follow (Today = 19/07/2005):
Vanilla Option. (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2006# | FALSE | max(Asset(cRow) - 10, 0) | |
Sum of two Vanilla Options (Call and Put). (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2006# | FALSE | 100 | max(Asset(cRow) - Cell(cRow, cCol-1), 0) + PVCol(cCol) |
| 2 | #19/07/2007# | FALSE | 90 | max(Cell(cRow, cCol-1) - Asset(cRow), 0) |
American Option (Repeat column and PVCol() function are used differently). (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2005# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 1 | #19/07/2006# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
Delayed start American Option (starts at 19/10/2005, today is 19/07/2005). (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/10/2005# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 1 | #19/10/2006# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
Bermudan Option. (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2005# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 2 | #19/01/2006# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 3 | #19/07/2006# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 4 | #19/01/2007# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 5 | #19/07/2007# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 6 | #19/01/2008# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 7 | #19/07/2008# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 8 | #19/01/2009# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 9 | #19/07/2009# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
Starts as American then becomes Bermudan Option. (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2005# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 2 | #19/01/2006# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 3 | #19/07/2006# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 4 | #19/01/2007# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 5 | #19/07/2007# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 6 | #19/01/2008# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 7 | #19/07/2008# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 8 | #19/01/2009# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 9 | #19/07/2009# | FALSE | max(Asset(cRow) - 10, PVCol(cCol)) | |
Chooser Option. (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | PayOff Col | |
|---|
| 1 | #19/07/2005# | FALSE | | max(PVCol(cCol-1), PVCol(cCol)) | |
| 2 | #19/07/2006# | FALSE | max(Asset(cRow) - 10, 0) | max(10 - Asset(cRow), 0) | |
Compound Option (european on european). (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2006# | FALSE | max(8.0 - PVCol(cCol), 0) | |
| 2 | #19/01/2007# | FALSE | max(Asset(cRow) - 10, 0) | |
Compound Option (european on american, delayed by 2 days). (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2006# | FALSE | max(8.0 - PVCol(cCol), 0) | |
| 2 | 21/07/2006# | TRUE | max(Asset(cRow) - 10, PVCol(cCol)) | |
| 3 | #19/07/2008# | FALSE | max(Asset(cRow) - 10, 0) | |
- CapeTools Generic MonteCarlo Pricer
General Description
Functions to price generic Equity/FX/Commodity structures under a MonteCarlo framework. If your product's payoff does not refer to asset prices in the future (ie - Bermudan / American options) you can use this framework.
Here are some general rules to keep in mind regarding how the payoff grid will be processed :
- Rows are time points. As you read down the grid you are moving forward in time.
- Columns represent your payoff formulas. You can create as many columns as you like. Columns are there to help you split up your payoff, or for a payoff function within a cell to refer to other cells within the grid.
- For the MonteCarlo pricer, the pricing starts at the first timestep and prices from left to right.
- Formula expressions within a cell cannot refer to formula cells to the right of itself.
- Formula expressions within a cell cannot refer to formula cells below itself (future time points).
If you bear the 5 points in mind, this should aid you in constructing payoff grids.
Below is an example of a payoff table. The Step column is not required.
| Step | EventDate | Repeat? | PayOff Col | PayOff Col | PayOff Col | PayOff Col |
|---|
| 1 | #19/07/2005# | FALSE | Asset(1, cRow) + _a + 5pct | Asset(2, cRow) + Interp1D(1,cRow) - 100bp | GridRowAvg(cRow, cCol-2, cCol-1) | |
| 2 | #19/01/2006# | FALSE | Asset(1, cRow) + _a + 5pct | Asset(2, cRow) + Interp1D(1,cRow) - 100bp | GridRowAvg(cRow, cCol-2, cCol-1) | |
| 3 | #19/07/2006# | FALSE | Asset(1, cRow) + _a + 5pct | Asset(2, cRow) + Interp1D(1,cRow) - 100bp | GridRowAvg(cRow, cCol-2, cCol-1) | |
| 4 | #19/01/2007# | FALSE | Asset(1, cRow) + _a + 5pct | Asset(2, cRow) + Interp1D(1,cRow) - 100bp | GridRowAvg(cRow, cCol-2, cCol-1) | |
| 5 | #19/07/2007# | FALSE | Asset(1, cRow) + _a + 5pct | Asset(2, cRow) + Interp1D(1,cRow) - 100bp | GridRowAvg(cRow, cCol-2, cCol-1) | |
| 6 | #19/01/2008# | FALSE | Asset(1, cRow) + _a + 5pct | Asset(2, cRow) + Interp1D(1,cRow) - 100bp | GridRowAvg(cRow, cCol-2, cCol-1) | |
| 7 | #19/07/2008# | FALSE | Asset(1, cRow) + _a + 5pct | Asset(2, cRow) + Interp1D(1,cRow) - 100bp | GridRowAvg(cRow, cCol-2, cCol-1) | |
| 8 | #19/01/2009# | FALSE | Asset(1, cRow) + _a + 5pct | Asset(2, cRow) + Interp1D(1,cRow) - 100bp | GridRowAvg(cRow, cCol-2, cCol-1) | |
| 9 | #19/07/2009# | FALSE | Asset(1, cRow) + _a + 5pct | Asset(2, cRow) + Interp1D(1,cRow) - 100bp | GridRowAvg(cRow, cCol-2, cCol-1) | |
| 10 | #19/01/2010# | FALSE | Asset(1, cRow) + _a + 5pct | Asset(2, cRow) + Interp1D(1,cRow) - 100bp | GridRowAvg(cRow, cCol-2, cCol-1) | |
| 11 | #19/07/2010# | FALSE | Asset(1, cRow) + _a + 5pct | Asset(2, cRow) + Interp1D(1,cRow) - 100bp | GridRowAvg(cRow, cCol-2, cCol-1) | |
| 12 | #19/01/2011# | FALSE | Asset(1, cRow) + _a + 5pct | Asset(2, cRow) + Interp1D(1,cRow) - 100bp | GridRowAvg(cRow, cCol-2, cCol-1) | max(GridColMin(cCol-1, 1, cRow) - AssetMin(1, 1, cRow), 0.0) * DCF(1, cRow) |
The 'Repeat' column indicates that the instruction at the current step will be repeated for all the timesteps between this and the next.
Even though there are only 12 timesteps above, you can instruct the function to insert additional steps between each step.
Financial variables (case sensitive) :
- cRow - refers to the current Row with the payoff table. Within all the Financial functions listed below, we recommend that you always use this variable (with perhaps offset values, ie - cRow, cRow-1, cRow+2 etc...) instead of a fixed value (ie - 1, 2 etc...). This is important especially if you enable American type handling from one timestep to another. Using static integer values will generate incorrect results.
- cCol - refers to the current Column with the payoff table. Within all the financial functions listed below, we recommend that you always use this variable (with perhaps offset values, ie - cCol, cCol-1, cCol+2 etc...).
- pct - When an integer value is placed in front of this expression (no spaces), the function will interp the whole expression as a percent. (ie - 5pct => 0.05)
- bp - When an integer value is placed in front of this expression (no spaces), the function will interp the whole expression as basis points. (ie - 5bp => 0.0005)
- _XXX - Constant variables can be defined by filling in the 'ConstParams' parameter of the GenericMCPricer() function. All variables must be defined with a leading underscore character ( ie - _XXX = 0.5)
Financial functions (case sensitive) :
- Asset(AssetNo, TimeStep)) - Retrieves the value of an asset value of an asset at the requested 'TimeStep'. If a CorrArrayProcesses process object was passed into the MonteCarlo pricer, the 'AssetNo is the index into this asset array. If a single Process object was passed in, the 'AssetNo' should equal one (1).
- Cell(row, col) - Retrieves a computed value within the PayOff Table. You can only refer to rows and columns below and to the left of the current cell location. You can also refer to the current cell location. This is because the MonteCarlo pricer prices forwards in time and thus future payoff values have not been computed as yet. The expression 'Cell(cRow, cCol-1)' retrieves the payoff value for the current timestep but at the previous column.
- DCF(AssetNo, TimeStep)) - Retrieves the discount value of an asset at the requested 'TimeStep'. . If a CorrArrayProcesses process object was passed into the MonteCarlo pricer, the 'AssetNo is the index into this asset array. If a single Process object was passed in, the 'AssetNo' should equal one (1). Unlike some of the other pricers, the MonteCarlo pricer does not discount values. This function is needed in order to compute the discount factor needed for discounting. The discount factor curve will be retrieved from the Process object indicated by the 'AssetNo' parameter.
- DCF2(AssetNo, FromTimeStep, ToTimeStep)) - Retrieves the discount value between two timeSteps (ie - discount factor between step 'FromTimeStep' and 'ToTimeStep'). If a CorrArrayProcesses process object was passed into the MonteCarlo pricer, the 'AssetNo is the index into this asset array. If a single Process object was passed in, the 'AssetNo' should equal one (1). Unlike some of the other pricers, the MonteCarlo pricer does not discount values. This function is needed in order to compute the discount factor needed for discounting. The discount factor curve will be retrieved from the Process object indicated by the 'AssetNo' parameter.
- AssetMin(AssetNo, startRow, endRow) - Retrieves the minimum asset value from a starting to an ending 'step' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- AssetMax(AssetNo, startRow, endRow) - Retrieves the maximum asset value from a starting to an ending 'step' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- AssetSum(AssetNo, startRow, endRow) - Retrieves the sum of the asset's value from a starting to an ending 'step' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- AssetAvg(AssetNo, startRow, endRow) - Retrieves the average of the asset's value from a starting to an ending 'step' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- GridRowMin(Row, startCol, endCol) - Retrieves the minimum value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowMax(Row, startCol, endCol) - Retrieves the maximum value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowAvg(Row, startCol, endCol) - Retrieves the average value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowSum(Row, startCol, endCol) - Retrieves the sum across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridColMin(Col, startRow, endRow) - Retrieves the minimum value across the rows of the PayOff table (given a column value). For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- GridColMax(Col, startRow, endRow) - Retrieves the maximum value across the rows of the PayOff table (given a column value). For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- GridColAvg(Col, startRow, endRow) - Retrieves the average value across the rows of the PayOff table (given a column value). For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- GridColSum(Col, startRow, endRow) - Retrieves the sum value across the rows of the PayOff table (given a column value). For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- Interp1D(nIndex, XValue ) - If any 1D interpolation objects have been passed into GenericMCPricer() function (a maximum of 2 objects can be defined), then you can execute this function within your payoff grid. The 'nIndex' parameter refers to the intepolation object (1-based). 'XValue' is the value where the interpolation is to be performed. The interpolation object will not extrapolate values.
- Interp2D(nIndex, XValue, YValue) - If any 2D interpolation objects have been passed into GenericMCPricer() function (a maximum of 2 objects can be defined), then you can execute this function within your payoff grid. The 'nIndex' parameter refers to the intepolation object (1-based). 'XValue' and 'YValue' are the values where the interpolation is to be performed. The interpolation object will not extrapolate values.
- iff(condition, a, b) - Tests for the condition and returns the value of 'a' if true or 'b' if false.
Predefined functions (case sensitive) :
- sin(x) ( sine function )
- cos(x) ( cosine function )
- tan(x) ( tangens function )
- asin(x) ( arcus sine function )
- acos(x) ( arcus cosine function )
- atan(x) ( arcus tangens function )
- sinh(x) ( hyperbolic sine function )
- cosh(x) ( hyperbolic cosine function )
- tanh(x) ( hyperbolic tangens function )
- asinh(x) ( hyperbolic arcus sine function )
- acosh(x) ( hyperbolic arcus cosine function )
- atanh(x) ( hyperbolic arcur tangens function )
- log2(x) ( logarithm to the base 2 )
- log10(x) ( logarithm to the base 10 )
- log(x) ( logarithm to the base 10 )
- ln(x) ( logarithm to the base e (2.71828...)
- exp(x) ( e raised to the power of x )
- sqrt(x) ( square root of a value )
- sign(x) ( sign function ) -1=(if x<0), 1=(if x>0 )
- rint(x) ( round to nearest integer )
- abs(x) ( absolute value )
- min(a,b,c,d,e,...) ( min of all arguments ie - min(-2,1,5,-6) )
- max(a,b,c,d,e,...) ( max of all arguments ie - max(-2,1,5,-6) )
- sum(a,b,c,d,e,...) ( sum of all arguments ie - sum(-2,1,5,-6) )
- avg(a,b,c,d,e,...) ( mean value of all arguments ie - avg(-2,1,5,-6) )
- ite(x,y,z) ( if ... then ... else ... : ie - ite(a<b, 5.0, -3.0) )
Predefined operators :
- + ( addition )
- - ( subtraction )
- * ( multiplication )
- / ( division )
- ^ ( raise x to the power of y )
Predefined operators that can be used within the first parameter of the ite() or iff() function :
- and ( logical and )
- or ( logical or )
- <= ( less or equal )
- >= ( greater or equal )
- != ( not equal )
- == ( equal to )
- > ( greater than )
- < ( less than )
- Brackets, '(' and ')', can also be used to simplify expressions.
Some possible examples of what is possible now follow (Today = 19/07/2005):
Vanilla Option. (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2006# | FALSE | max(Asset(1, cRow) - 10, 0) * DCF(1, cRow) | |
Two Vanilla Options (Call and Put). (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | PayOff Col | PayOff Col | |
|---|
| 1 | #19/07/2006# | FALSE | 100 | max(Asset(1, cRow) - Cell(cRow, cCol-1), 0) * DCF(1, cRow) | | |
| 2 | #19/07/2007# | FALSE | 90 | max(Cell(cRow, cCol-1) - Asset(1, cRow), 0) * DCF(1, cRow) | GridColSum(cCol-1, 1, cRow) | |
Asian Lookback Option. (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | PayOff Col | |
|---|
| 1 | #19/07/2005# | FALSE | Asset(1, cRow) | | |
| 2 | #19/01/2006# | FALSE | Asset(1, cRow) | | |
| 3 | #19/07/2006# | FALSE | Asset(1, cRow) | | |
| 4 | #19/01/2007# | FALSE | Asset(1, cRow) | | |
| 5 | #19/07/2007# | FALSE | Asset(1, cRow) | max(GridColAvg(cCol-1, 1, cRow) - GridColMax(cCol-1, 1, cRow), 0) * DCF(1, cRow) | |
Asian Option with fixed strike. (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | PayOff Col | |
|---|
| 1 | #19/07/2005# | FALSE | Asset(1, cRow) | | |
| 2 | #19/01/2006# | FALSE | Asset(1, cRow) | | |
| 3 | #19/07/2006# | FALSE | Asset(1, cRow) | | |
| 4 | #19/01/2007# | FALSE | Asset(1, cRow) | | |
| 5 | #19/07/2007# | FALSE | Asset(1, cRow) | max(GridColAvg(cCol-1, 1, cRow) - 10, 0) * DCF(1, cRow) | |
Asian Option with fixed strike (daily averaging). (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2005# | TRUE | | |
| 2 | #19/01/2006# | TRUE | | |
| 3 | #19/07/2006# | TRUE | | |
| 4 | #19/01/2007# | TRUE | | |
| 5 | #19/07/2007# | FALSE | max(AssetAvg(1, 1, cRow) - 10, 0) * DCF(1, cRow) | |
Asian Option with floating strike. (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | PayOff Col | |
|---|
| 1 | #19/07/2005# | FALSE | Asset(1, cRow) | | |
| 2 | #19/01/2006# | FALSE | Asset(1, cRow) | | |
| 3 | #19/07/2006# | FALSE | Asset(1, cRow) | | |
| 4 | #19/01/2007# | FALSE | Asset(1, cRow) | | |
| 5 | #19/07/2007# | FALSE | Asset(1, cRow) | max(GridColAvg(cCol-1, 1, cRow) - Cell(cRow, cCol), 0) * DCF(1, cRow) | |
Asian Option with floating strike (daily averaging). (The Step column is not required).
| Step | EventDate | Repeat? | PayOff Col | |
|---|
| 1 | #19/07/2005# | TRUE | | |
| 2 | #19/01/2006# | TRUE | | |
| 3 | #19/07/2006# | TRUE | | |
| 4 | #19/01/2007# | TRUE | | |
| 5 | #19/07/2007# | FALSE | max(AssetAvg(1, 1, cRow) - Cell(cRow, cCol), 0) * DCF(1, cRow) | |
Quanto Asian Basket Option with floating strike. (The Step column is not required).
This example was picked up from one of the QuantLib's mailing list (with some modifications).
Let us consider a quanto asian basket average rate option, which has as underlying 2 equities quoted in currencies AAA and BBB (the values are not "real word" data).
Underlying #1: current price = 75 AAA, dividend yield = 3.1%, volatility = 20%
Underlying #2: current price = 100 BBB, dividend yield = 2%, volatility = 15%
AAA risk free rate: 5.1%
BBB risk free rate: 3.5%
Exchange rate AAA/BBB: 1.5
Volatility of exchange rate AAA/BBB: 15%
Correlation between Underlying #2 and the exchange rate = 0.4
The option is paid in currency AAA and has the payoff of a quanto asian
Basket (note: in the payoff there is no exchange rate):
Basket1 = underlying1[samplingDate1] + underlying2[samplingDate1]
Basket2 = underlying1[samplingDate2] + underlying2[samplingDate2]
.
.
.
BasketN = underlying1[samplingDateN] + underlying2[samplingDateN]
Average = (basket1 + basket2 + ... + basketN) / N
Strike: 175
Sampling dates: 19/07/2005, 19/01/2006, 19/07/2006, 19/01/2007, 19/07/2007
Expiry date: 19/07/2007
Payoff at expiry = max(0; Average - Strike)
One can use the following payoff table :
| Step | EventDate | Repeat? | PayOff Col | PayOff Col | PayOff Col | PayOff Col | |
|---|
| 1 | #19/07/2005# | FALSE | Asset(1, cRow) | Asset(2, cRow) | Cell(cRow, cCol-2)+Cell(cRow, cCol-1) | | |
| 2 | #19/01/2006# | FALSE | Asset(1, cRow) | Asset(2, cRow) | Cell(cRow, cCol-2)+Cell(cRow, cCol-1) | | |
| 3 | #19/07/2006# | FALSE | Asset(1, cRow) | Asset(2, cRow) | Cell(cRow, cCol-2)+Cell(cRow, cCol-1) | | |
| 4 | #19/01/2007# | FALSE | Asset(1, cRow) | Asset(2, cRow) | Cell(cRow, cCol-2)+Cell(cRow, cCol-1) | | |
| 5 | #19/07/2007# | FALSE | Asset(1, cRow) | Asset(2, cRow) | Cell(cRow, cCol-2)+Cell(cRow, cCol-1) | max(GridColAvg(cCol-1, 1, cRow) - 175, 0) * DCF(1, cRow) | |
In terms of the assets themselves, we would construct a CorrArrayProcesses() object and fill it with just 2 process objects created via the GBSProcess() function.
The correlation matrix used in the simulation is consequently just 2x2 and has only the correlations between the assets.
For the first process, GBSProcess(), we would consider the following arguments.
- Asset price = 75
- Volatility = 0.2
- Rate = 0.051
- dividend yield = 0.031
However for the second process, GBSProcess(), we would consider the following arguments.
- Asset price = 100
- Volatility = 0.15
- Rate = 0.035 - (correlation * volAsset2 * volExRate)
- dividend yield = 0.02
Thus the Rate value for the second process will equal : 0.035 - (0.4 * 0.15 * 0.15).
The reason why the second process's rate value is modified is because the currency of this asset is not equal to the payment currency. If you do not want to use a FX rate in the expression then a Quanto adjustment must be made to the 'rate' parameter. You also see that we use the DCF(1, cRow) function within the payoff table. The first parameter indicates which asset's discounting curve are we using. In this case, Asset #1's discounting curve.
When pricing Quanto products, there is no need to construct another process object to simulate the exchange rate.
- CapeTools Generic IR LMM MonteCarlo Pricer
General Description
Functions to price generic interest rate structures under a LMM MonteCarlo framework. If your product's payoff does not refer to asset prices in the future (ie - Bermudan / American options) you can use this framework.
Here are some general rules to keep in mind regarding how the payoff grid will be processed :
- Rows are time points. As you read down the grid you are moving forward in time.
- Columns represent your payoff formulas. You can create as many columns as you like. Columns are there to help you split up your payoff, or for a payoff function within a cell to refer to other cells within the grid.
- For the MonteCarlo pricer, the pricing starts at the first timestep and prices from left to right.
- Formula expressions within a cell cannot refer to formula cells to the right of itself.
- Formula expressions within a cell cannot refer to formula cells below itself (future time points).
- No payoff formulas must be present within the very first timestep and you can never refer to the very first time step (we call this step, time step 0).
If you bear the 6 points in mind, this should aid you in constructing payoff grids.
Below is an example of a payoff table. The Step column is not required.
| Step | EventDate | PayOff Col | PayOff Col | PayOff Col | PayOff Col |
|---|
| 0 | #21/07/2006# | | | | |
| 1 | #23/10/2006# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 2 | #22/01/2007# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 3 | #23/04/2007# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 4 | #23/07/2007# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 5 | #22/10/2007# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 6 | #21/01/2008# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 7 | #21/04/2008# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 8 | #21/07/2008# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 9 | #21/10/2008# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 10 | #21/01/2009# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 11 | #21/04/2009# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 12 | #21/07/2009# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 13 | #21/10/2009# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 14 | #21/01/2010# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 15 | #21/04/2010# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 16 | #21/07/2010# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 17 | #21/10/2010# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 18 | #21/01/2011# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 19 | #21/04/2011# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | |
| 20 | #21/07/2011# | Libor(cRow) + _a | Interp1D(1,cRow) | GridRowSum(cRow, cCol-2, cCol-1) | max(GridColMin(cCol-1, 1, cRow) - LiborMin(1, cRow), 0.0) * DCF(cRow) * Cvg(cRow) |
Note the following definitions :
- DCF(date) = Discount factor.at the given 'date'
.
- Coverage(start, end) = Year fraction between 'start' and 'end' dates.
- CashRate(start, end) = ((DCF(start)/DCF(end)) - 1) / Coverage(start, end)
- Libor(start, end) = CashRate(start, end) + FwdSpread(end)
- If a yieldcurve stripper was used without utilizing cross-currency swaps against the dollar and the Index object does not specify any Basis Swap curves then the FwdSpread(end) function will be equal to zero (0).
- If a yieldcurve stripper was used utilizing cross-currency swaps against the dollar, then the CashRate() function uses only the discounting curve and the rate will not equal the LIBOR rate. The forward spread is the difference between the CashRate() and the Libor() rate.
- If a yieldcurve stripper was used without utilizing cross-currency swaps against the dollar but the Index object does specify a Basis Swap curve then the CashRate() function will return the LIBOR rate. However the Index object specifies a spread to be added to the LIBOR rate and this spread is encapsulated within the FwdSpread() function.
Financial variables (case sensitive) :
- cRow - refers to the current Row with the payoff table. Within all the Financial functions listed below, we recommend that you always use this variable (with perhaps offset values, ie - cRow, cRow-1, cRow+2 etc...) instead of a fixed value (ie - 1, 2 etc...). This is important especially if you enable American type handling from one timestep to another. Using static integer values will generate incorrect results.
- cCol - refers to the current Column with the payoff table. Within all the financial functions listed below, we recommend that you always use this variable (with perhaps offset values, ie - cCol, cCol-1, cCol+2 etc...).
- pct - When an integer value is placed in front of this expression (no spaces), the function will interp the whole expression as a percent. (ie - 5pct => 0.05)
- bp - When an integer value is placed in front of this expression (no spaces), the function will interp the whole expression as basis points. (ie - 5bp => 0.0005)
- _XXX - Constant variables can be defined by filling in the 'ConstParams' parameter of the GenericLMM_MCPricer() function. All variables must be defined with a leading underscore character ( ie - _XXX = 0.5)
Financial functions (case sensitive) :
- Libor(row) - Returns the libor value between the previous time step and this time step. Thus the LIBOR rate will be FIXED at the previous timestep and PAID at the current timestep.
- CashRate(row) - Returns the CashRate value between the previous time step and this time step. Thus the CashRate rate will be FIXED at the previous timestep and PAID at the current timestep.
- Cvg(row) - Returns the year fraction between the previous time step and this time step.
- FwdSpread(row) - Returns the Forward Spread at the given time step.
- Cell(row, col) - Retrieves a computed value within the PayOff Table. You can only refer to rows and columns below and to the left of the current cell location. You can also refer to the current cell location. This is because the MC pricer prices forwards in time and thus future payoff values have not been computed as yet. The expression 'Cell(cRow, cCol-1)' retrieves the payoff value for the current timestep but at the previous column.
- DCF(TimeStep) - Retrieves the discount value of an asset at the requested 'TimeStep'. Unlike some of the other pricers, the MonteCarlo pricer does not discount values. This function is needed in order to compute the discount factor needed for discounting. The discount factor curve will be retrieved from the Process object indicated by the 'AssetNo' parameter.
- DCF2(FromTimeStep, ToTimeStep) - Retrieves the discount value between two timeSteps (ie - discount factor between step 'FromTimeStep' and 'ToTimeStep'). Unlike some of the other pricers, the MonteCarlo pricer does not discount values. This function is needed in order to compute the discount factor needed for discounting. The discount factor curve will be retrieved from the Process object indicated by the 'AssetNo' parameter.
- LiborMin(startRow, endRow) - Retrieves the minimum LIBOR value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- LiborMax(startRow, endRow) - Retrieves the maximum LIBOR value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- LiborAvg(startRow, endRow) - Retrieves the average of the LIBOR value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- LiborSum(startRow, endRow) - Retrieves the sum of the LIBOR values across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- CashRateMin(startRow, endRow) - Retrieves the minimum LIBOR value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- CashRateMax(startRow, endRow) - Retrieves the maximum LIBOR value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- CashRateAvg(startRow, endRow) - Retrieves the average of the LIBOR value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- CashRateSum(startRow, endRow) - Retrieves the sum of the LIBOR values across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- GridRowMin(Row, startCol, endCol) - Retrieves the minimum value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowMax(Row, startCol, endCol) - Retrieves the maximum value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowAvg(Row, startCol, endCol) - Retrieves the average value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowSum(Row, startCol, endCol) - Retrieves the sum across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridColMin(Col, startRow, endRow) - Retrieves the minimum value across the rows of the PayOff table (given a column value). For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- GridColMax(Col, startRow, endRow) - Retrieves the maximum value across the rows of the PayOff table (given a column value). For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- GridColAvg(Col, startRow, endRow) - Retrieves the average value across the rows of the PayOff table (given a column value). For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- GridColSum(Col, startRow, endRow) - Retrieves the sum value across the rows of the PayOff table (given a column value). For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- Interp1D(nIndex, XValue ) - If any 1D interpolation objects have been passed into GenericLMM_MCPricer() function (a maximum of 2 objects can be defined), then you can execute this function within your payoff grid. The 'nIndex' parameter refers to the intepolation object (1-based). 'XValue' is the value where the interpolation is to be performed. The interpolation object will not extrapolate values.
- Interp2D(nIndex, XValue, YValue) - If any 2D interpolation objects have been passed into GenericLMM_MCPricer() function (a maximum of 2 objects can be defined), then you can execute this function within your payoff grid. The 'nIndex' parameter refers to the intepolation object (1-based). 'XValue' and 'YValue' are the values where the interpolation is to be performed. The interpolation object will not extrapolate values.
- iff(condition, a, b) - Tests for the condition and returns the value of 'a' if true or 'b' if false.
Predefined functions (case sensitive) :
- sin(x) ( sine function )
- cos(x) ( cosine function )
- tan(x) ( tangens function )
- asin(x) ( arcus sine function )
- acos(x) ( arcus cosine function )
- atan(x) ( arcus tangens function )
- sinh(x) ( hyperbolic sine function )
- cosh(x) ( hyperbolic cosine function )
- tanh(x) ( hyperbolic tangens function )
- asinh(x) ( hyperbolic arcus sine function )
- acosh(x) ( hyperbolic arcus cosine function )
- atanh(x) ( hyperbolic arcur tangens function )
- log2(x) ( logarithm to the base 2 )
- log10(x) ( logarithm to the base 10 )
- log(x) ( logarithm to the base 10 )
- ln(x) ( logarithm to the base e (2.71828...)
- exp(x) ( e raised to the power of x )
- sqrt(x) ( square root of a value )
- sign(x) ( sign function ) -1=(if x<0), 1=(if x>0 )
- rint(x) ( round to nearest integer )
- abs(x) ( absolute value )
- min(a,b,c,d,e,...) ( min of all arguments ie - min(-2,1,5,-6) )
- max(a,b,c,d,e,...) ( max of all arguments ie - max(-2,1,5,-6) )
- sum(a,b,c,d,e,...) ( sum of all arguments ie - sum(-2,1,5,-6) )
- avg(a,b,c,d,e,...) ( mean value of all arguments ie - avg(-2,1,5,-6) )
- ite(x,y,z) ( if ... then ... else ... : ie - ite(a<b, 5.0, -3.0) )
Predefined operators :
- + ( addition )
- - ( subtraction )
- * ( multiplication )
- / ( division )
- ^ ( raise x to the power of y )
Predefined operators that can be used within the first parameter of the ite() or iff() function :
- and ( logical and )
- or ( logical or )
- <= ( less or equal )
- >= ( greater or equal )
- != ( not equal )
- == ( equal to )
- > ( greater than )
- < ( less than )
- Brackets, '(' and ')', can also be used to simplify expressions.
- CapeTools Generic IR Tree Pricer
General Description
Functions to price generic interest rate structures under an interest rate tree framework. If your product's payoff does not refer to LIBOR RATES in the past (ie - Asian options) you can use this framework.
Here are some general rules to keep in mind regarding how the payoff grid will be processed :
- Rows are time points. As you read down the grid you are moving forward in time.
- Columns represent your payoff formulas. You can create as many columns as you like. Columns are there to help you split up your payoff, or for a payoff function within a cell to refer to other cells within the grid.
- For the Tree pricer, the pricing starts at the last timestep and prices from left to right.
- Formula expressions within a cell cannot refer to formula cells to the right of itself.
- Formula expressions within a cell cannot refer to formula cells above itself (past time points).
- Given any step within your payoff table, the current step is defined as the fixing date and the next step is the payment date.
- No payoff formulas may be present within the very last timestep (used as a holder for the last rate payment date).
If you bear the 7 points in mind, this should aid you in constructing payoff grids.
Below is an example of a payoff table. This deal prices a cap (sum of caplets). The Step column is not required.
| Step | EventDate | PayOff Col | PayOff Col | PayOff Col | PayOff Col |
|---|
| 1 | #21/07/2006# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 2 | #23/10/2006# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 3 | #22/01/2007# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 4 | #23/04/2007# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 5 | #23/07/2007# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 6 | #22/10/2007# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 7 | #21/01/2008# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 8 | #21/04/2008# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 9 | #21/07/2008# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 10 | #21/10/2008# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 11 | #21/01/2009# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 12 | #21/04/2009# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 13 | #21/07/2009# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 14 | #21/10/2009# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 15 | #21/01/2010# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 16 | #21/04/2010# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 17 | #21/07/2010# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 18 | #21/10/2010# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 19 | #21/01/2011# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) + PVCol(cCol) |
| 20 | #21/04/2011# | Libor(cRow) | ZCB(cRow) | Caplet(_X, 0.0) * Cvg(cRow) * _Notional | Cell(cRow, cCol-1) |
| 21 | #21/07/2011# | | | | |
Note the following financial definitions :
- DCF(date) = Discount factor.at the given 'date'
.
- Coverage(start, end) = Year fraction between 'start' and 'end' dates.
- CashRate(start, end) = ((DCF(start)/DCF(end)) - 1) / Coverage(start, end)
- Libor(start, end) = CashRate(start, end) + FwdSpread(end)
- If a yieldcurve stripper was used without utilizing cross-currency swaps against the dollar and the Index object does not specify any Basis Swap curves then the FwdSpread(end) function will be equal to zero (0).
- If a yieldcurve stripper was used utilizing cross-currency swaps against the dollar, then the CashRate() function uses only the discounting curve and the rate will not equal the LIBOR rate. The forward spread is the difference between the CashRate() and the Libor() rate.
- If a yieldcurve stripper was used without utilizing cross-currency swaps against the dollar but the Index object does specify a Basis Swap curve then the CashRate() function will return the LIBOR rate. However the Index object specifies a spread to be added to the LIBOR rate and this spread is encapsulated within the FwdSpread() function.
Financial variables (case sensitive) :
- cRow - refers to the current Row with the payoff table. Within all the Financial functions listed below, we recommend that you always use this variable (with perhaps offset values, ie - cRow, cRow-1, cRow+2 etc...) instead of a fixed value (ie - 1, 2 etc...). This is important especially if you enable American type handling from one timestep to another. Using static integer values will generate incorrect results.
- cCol - refers to the current Column with the payoff table. Within all the Financial functions listed below, we recommend that you always use this variable (with perhaps offset values, ie - cCol, cCol-1, cCol+2 etc...).
- pct - When an integer value is placed in front of this expression (no spaces), the function will interp the whole expression as a percent. (ie - 5pct => 0.05)
- bp - When an integer value is placed in front of this expression (no spaces), the function will interp the whole expression as basis points. (ie - 5bp => 0.0005)
- _XXX - Constant variables can be defined by filling in the 'ConstParams' parameter of the GenericIRTreePricer() function. All variables must be defined with a leading underscore character ( ie - _XXX = 0.5)
Financial functions (case sensitive) :
- Libor(row) - Returns the libor value between the current time step and the next time step. Thus the LIBOR rate will be FIXED at this timestep and PAID at the next timestep.
- CashRate(row) - Returns the CashRate value between the current time step and the next time step. Thus the CashRate rate will be FIXED at this timestep and PAID at the next timestep.
- ZCB(row) - Returns the zero coupon bond (discount factor) value up to the current (rate fixing) timestep.
Because the the current step is defined as the fixing date and the next step is the payment date, you cannot price a caplet via the following expression [max(Libor(cRow) - strike, dTest)]. Expressions like these only work if the current step is the payment step. However we have provided the correct functions for you to price caplets/floorlets.
- Caplet(strike, dTest) - Returns the caplet value [max(Libor(cRow) - strike, dTest)] between the current time step and the next time step.
- Floorlet(strike, dTest) - Returns the floorlet value [max(strike - Libor(cRow), dTest)] between the current time step and the next time step.
- Cvg(row) - Returns the year fraction between the previous time step and this time step.
- FwdSpread(row) - Returns the Forward Spread at the given time step.
- Cell(row, col) - Retrieves a computed value within the PayOff Table. You can only refer to rows and columns below and to the left of the current cell location. You can also refer to the current cell location. This is because the Tree pricer prices backwards in time and thus past payoff values have not been computed as yet. The expression 'Cell(cRow, cCol-1)' retrieves the payoff value for the current timestep but at the previous column.
- LiborMin(startRow, endRow) - Retrieves the minimum LIBOR value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- LiborMax(startRow, endRow) - Retrieves the maximum LIBOR value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- LiborAvg(startRow, endRow) - Retrieves the average of the LIBOR value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- LiborSum(startRow, endRow) - Retrieves the sum of the LIBOR values across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- CashRateMin(startRow, endRow) - Retrieves the minimum LIBOR value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- CashRateMax(startRow, endRow) - Retrieves the maximum LIBOR value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- CashRateAvg(startRow, endRow) - Retrieves the average of the LIBOR value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- CashRateSum(startRow, endRow) - Retrieves the sum of the LIBOR values across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- ZCBMin(startRow, endRow) - Retrieves the minimum zero coupon bond value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- ZCBMax(startRow, endRow) - Retrieves the maximum zero coupon bond value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- ZCBAvg(startRow, endRow) - Retrieves the average of the zero coupon bond value across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- ZCBSum(startRow, endRow) - Retrieves the sum of the zero coupon bond values across a starting and ending 'TimeStep' range. For the 'startRow' and 'endRow' parameters you can only refer to rows above or equal to the current cell location (past dates).
- GridRowMin(Row, startCol, endCol) - Retrieves the minimum value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowMax(Row, startCol, endCol) - Retrieves the maximum value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowAvg(Row, startCol, endCol) - Retrieves the average value across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- GridRowSum(Row, startCol, endCol) - Retrieves the sum across the columns of the PayOff table (given a 'TimeStep' or row value). For the 'startCol' and 'endCol' parameters you can only refer to columns to the left or equal to the current cell location.
- Interp1D(nIndex, XValue ) - If any 1D interpolation objects have been passed into GenericIRTreePricer() function (a maximum of 2 objects can be defined), then you can execute this function within your payoff grid. The 'nIndex' parameter refers to the intepolation object (1-based). 'XValue' is the value where the interpolation is to be performed. The interpolation object will not extrapolate values.
- Interp2D(nIndex, XValue, YValue) - If any 2D interpolation objects have been passed into GenericIRTreePricer() function (a maximum of 2 objects can be defined), then you can execute this function within your payoff grid. The 'nIndex' parameter refers to the intepolation object (1-based). 'XValue' and 'YValue' are the values where the interpolation is to be performed. The interpolation object will not extrapolate values.
- iff(condition, a, b) - Tests for the condition and returns the value of 'a' if true or 'b' if false.
Predefined functions (case sensitive) :
- sin(x) ( sine function )
- cos(x) ( cosine function )
- tan(x) ( tangens function )
- asin(x) ( arcus sine function )
- acos(x) ( arcus cosine function )
- atan(x) ( arcus tangens function )
- sinh(x) ( hyperbolic sine function )
- cosh(x) ( hyperbolic cosine function )
- tanh(x) ( hyperbolic tangens function )
- asinh(x) ( hyperbolic arcus sine function )
- acosh(x) ( hyperbolic arcus cosine function )
- atanh(x) ( hyperbolic arcur tangens function )
- log2(x) ( logarithm to the base 2 )
- log10(x) ( logarithm to the base 10 )
- log(x) ( logarithm to the base 10 )
- ln(x) ( logarithm to the base e (2.71828...)
- exp(x) ( e raised to the power of x )
- sqrt(x) ( square root of a value )
- sign(x) ( sign function ) -1=(if x<0), 1=(if x>0 )
- rint(x) ( round to nearest integer )
- abs(x) ( absolute value )
- min(a,b,c,d,e,...) ( min of all arguments ie - min(-2,1,5,-6) )
- max(a,b,c,d,e,...) ( max of all arguments ie - max(-2,1,5,-6) )
- sum(a,b,c,d,e,...) ( sum of all arguments ie - sum(-2,1,5,-6) )
- avg(a,b,c,d,e,...) ( mean value of all arguments ie - avg(-2,1,5,-6) )
- ite(x,y,z) ( if ... then ... else ... : ie - ite(a<b, 5.0, -3.0) )
Predefined operators :
- + ( addition )
- - ( subtraction )
- * ( multiplication )
- / ( division )
- ^ ( raise x to the power of y )
Predefined operators that can be used within the first parameter of the ite() or iff() function :
- and ( logical and )
- or ( logical or )
- <= ( less or equal )
- >= ( greater or equal )
- != ( not equal )
- == ( equal to )
- > ( greater than )
- < ( less than )
- Brackets, '(' and ')', can also be used to simplify expressions.
- CapeTools LMM Volatility/Correlation Models
General Description
Functions to create correlation and volatility models used by the Libor Market Model (LMM) LiborMarketModel() and LiborMarketModel() functions.
The correlation Model objects that can be created are :
- LMMLinearExpCorrModel() (Exponential correlation model - rho{i,j}=e^{(-beta*abs(i-j))})
- LMMFixedVolModel() (Extended exponential correlation model - rho{i,j}=rho+(1-rho)*e^{(-beta*abs(i-j))})
The volatility Model objects that can be created are :
- LMMLinearExpVolModel() (Linear exponential volatility model - sigma(t)=((a*(T{i}-t)+d)*exp{-b(T{i}-t)}+c))
- LMMLinearExpVolModel2() (Extended linear-exponential volatility model - sigma(t)=k_i*((a*(T{i}-t)+d)*exp{-b(T{i}-t)}+c))
- LMMFixedVolModel() (Constant volatilities)
There are also two LMM process functions to be used for the LMM montecarlo framework.
- CapeTools Models
General Description
Functions to create interest rate model objects that can be calibrated via the various interest rate calibration functions present within the 'CapeTools Calibration' category of functions. The interest rate Model objects that can be created are :
- BlackModel() ( Black's Option Formula : can be passed to the BlackCapFloorEngine() or the BlackSwaptionEngine() objects)
- G2TwoFactorModel() (Two factor additive ShortRate Model)
- HullWhite1FModel() (Single-factor Hull-White (extended Vasicek) ShortRate Model object)
- BK1FModel() (Single-factor BlackKarasinski ShortRate Model object)
- Vasicek1FModel() (Single-factor Vasicek ShortRate Model object)
- LiborMarketModel() (Forward Libor Market Model object)
- CapeTools Payoff
General Description
Functions to price option products under a pricing engine framework.
To price a single product under this framework, you require 5 objects to be constructed. These are :
- A pricing engine object
- An exercise object
- A payoff object
- One or more process objects
- A pricer object
The pricing engine object specifies the method of calculation (Tree, MC, direct, integration etc...).
The exercise object specifies the date(s) that exercise can take place.
The payoff object specifies the payoff function.
The process object(s) specifies the characteristics of the underlyer(s) whether Equity, FX or Commodity.
The pricer object takes in the Engine, Exercise, Payoff and Process objects and compute a price.
This category of contains the Payoff objects that are to be passed to option pricing functions (see the 'CapeTools EngineOptions' category of functions). The following Payoff types can be constructed :
- PlainVanilla() ( For a call max(price-strike,0.0), for a put max(strike-price,0.0) )
- PercentageStrike() ( Strike expressed as a percentage. For a call, price*max(1-moneyness,0.0), for a put, price*max(moneyness-1,0.0) )
- CashOrNothing() ( Binary cash-or-nothing payoff. For a call, if(price-strike is greater than 0.0 , cashPayoff , 0.0), for a put, if(strike-price is greater than 0.0 , cashPayoff , 0.0) )
- AssetOrNothingPayoff() ( Binary asset-or-nothing payoff. For a call, if(price-strike is greater than 0.0 , price , 0.0), for a put, if(strike-price is greater than 0.0 , price , 0.0) )
- Gap() ( Binary gap payoff. For a call, if(price-strike is greater than 0.0 , price-strikePayoff , 0.0), for a put, if(strike-price is greater than 0.0 , strikePayoff-price , 0.0) )
- Gap() ( Binary gap payoff. For a call, if(price-strike is greater than 0.0 , price-strikePayoff , 0.0), for a put, if(strike-price is greater than 0.0 , strikePayoff-price , 0.0) )
You can also create a generic payoff function via the following function :
The custom Generic PayOff function takes one underlyer (x) and up to 16 constant arguments (strike being one of them). x represents the underlying price (stock, FX Rate etc...) and will be populated during the pricing. Parameters 'a' through 'n' are the user defined constants. The constant e is predefined as 2.718281828459045235360287; the constant pi is predefined as 3.141592653589793238462643.
Within this function you define both the 'call' and 'put' formulas and then indicate which one is to be priced. (ie callFormula=max(x-strike,a+b*c), putFormula=max(strike-x,a+b*c) )
Valid functions and operators that can be used within the payoff expressions are :
Predefined functions (case sensitive) :
- sin(x) ( sine function )
- cos(x) ( cosine function )
- tan(x) ( tangens function )
- asin(x) ( arcus sine function )
- acos(x) ( arcus cosine function )
- atan(x) ( arcus tangens function )
- sinh(x) ( hyperbolic sine function )
- cosh(x) ( hyperbolic cosine function )
- tanh(x) ( hyperbolic tangens function )
- asinh(x) ( hyperbolic arcus sine function )
- acosh(x) ( hyperbolic arcus cosine function )
- atanh(x) ( hyperbolic arcur tangens function )
- log2(x) ( logarithm to the base 2 )
- log10(x) ( logarithm to the base 10 )
- log(x) ( logarithm to the base 10 )
- ln(x) ( logarithm to the base e (2.71828...)
- exp(x) ( e raised to the power of x )
- sqrt(x) ( square root of a value )
- sign(x) ( sign function ) -1=(if x<0), 1=(if x>0 )
- rint(x) ( round to nearest integer )
- abs(x) ( absolute value )
- min(a,b,c,d,e,...) ( min of all arguments ie - min(-2,1,5,-6) )
- max(a,b,c,d,e,...) ( max of all arguments ie - max(-2,1,5,-6) )
- sum(a,b,c,d,e,...) ( sum of all arguments ie - sum(-2,1,5,-6) )
- avg(a,b,c,d,e,...) ( mean value of all arguments ie - avg(-2,1,5,-6) )
- ite(x,y,z) ( if ... then ... else ... : ie - ite(a<b, 5.0, -3.0) )
Predefined operators :
- + ( addition )
- - ( subtraction )
- * ( multiplication )
- / ( division )
- ^ ( raise x to the power of y )
Predefined operators that can be used within the first parameter of the ite() or iff() function :
- and ( logical and )
- or ( logical or )
- <= ( less or equal )
- >= ( greater or equal )
- != ( not equal )
- == ( equal to )
- > ( greater than )
- < ( less than )
- Brackets, '(' and ')', can also be used to simplify expressions.
- CapeTools Exercise
General Description
Functions to price option products under a pricing engine framework.
To price a single product under this framework, you require 5 objects to be constructed. These are :
- A pricing engine object
- An exercise object
- A payoff object
- One or more process objects
- A pricer object
The pricing engine object specifies the method of calculation (Tree, MC, direct, integration etc...).
The exercise object specifies the date(s) that exercise can take place.
The payoff object specifies the payoff function.
The process object(s) specifies the characteristics of the underlyer(s) whether Equity, FX or Commodity.
The pricer object takes in the Engine, Exercise, Payoff and Process objects and compute a price.
This category of contains the Exercise objects that are to be passed to option pricing functions (see the 'CapeTools EngineOptions' category of functions). The following Exercise types can be constructed.
- EuropeanExercise()
- BermudanExercise()
- AmericanExercise()
You can also create Bermudan exercise objects from interest rate leg, Schedule, Swap and Bond objects via the following functions.
- ExerciseFromLeg()
- ExerciseFromSche()
- ExerciseFromSW()
- ExerciseFromFIXBND()
To display the dates stored within an Exercise object, you can execute the following function :
- DisplayExerciseDates() ( For the American Exercise object, only the starting and ending dates will be shown)
- CapeTools One-Dimensional Solvers
General Description
Functions to construct One-Dimensional Optimization objects needed by the 'CapeTools Option Solver' category of functions.
The following One-Dimensional Optimization objects can be created :
- Bisection()
- Brent()
- FalsePosition()
- Newton()
- Ridder()
- Secant()
The Newton() solver requires that the first derivative function of the function being solved upon to be implemented. Fortunatly, we have already done this for all the functions present within the 'CapeTools Option Solver' category of functions. Within these objects, you can set minimum and maximum starting values as well as a tolerance level.
- CapeTools Calibration Tools
General Description
Functions to construct Multi-Dimensional Optimization objects needed by all the calibration functions.
The following Optimization objects can be created :
- Simplex() (Multi-dimensional simplex object)
- LevenbergMarquardt() (Multi-dimensional LevenbergMarquardt object (based on MINPACK))
- ConjugateGradient() (Multi-dimensional Conjugate Gradient object)
- SteepestDescent() (Multi-dimensional Steepest Descent object)
We would recommend using the LevenbergMarquardt() followed by the Simplex() functions as these are very stable multi-dimensional solvers.
- CapeTools Calibration Instruments
General Description
Functions to help construct calibration instruments.
The following calibration utility functions can be used to help generate swaption calibration dates.
- GenStartDiagOSDates()
- GenEndDiagOSDates()
The following interest rate calibration functions create arrays of calibration instruments.
- CFCalibInst() (for an array of Caplet/Floorlet instruments)
- CFCalibInst2() (for an array of Caplet/Floorlet instruments)
- CFCalibInst3() (for an array of Caplet/Floorlet instruments)
- CapFloorCalibInst() (for an array of CapFloor instruments)
- OSCalibInst1() (for an array of Swaption instruments)
- OSCalibInst2() (for an array of Swaption instruments)
- OSCalibInst3() (for an array of Swaption instruments)
- MixedCalibInst() (for an array of both Swaption and Caplet/Floorlet instruments)
- MixedCalibInst2() (for an array of both Swaption and Caplet/Floorlet instruments)
- CapeTools SABR Calibration
General Description
Functions to calibrate the parameters of the SABR volatility model (ATMVol, Alpha, Beta and Rho).
The following SABR calibration functions create arrays of calibration instruments.
- SABRCalibInst()
- SABRCalibInst2()
- SABRCalibInst3()
The actual SABR calibration is conducted via the CalibrateSABR() or CalibrateSABR2() functions and used to populate the following SABR functions.
- SABRVolCurve() (requires matrices of calibrated SABR parameters for interest rate instruments).
- EquitySABRVolCurve()
Within the CalibrateSABR() function, you can actually fix any of the four parameters and solve for the others.
Note: This SABR model is identical to that of the same model developed by Hagan, Kumar, Lesniewski and Woodward (2002) except that we denote the ALPHA parameter as the 'volatility of volatility' (or WING) parameter and 'ATMVol' (alpha in the case of their model) as our 'volatility-like' parameter.
Note: We treat the 'ATMVol' parameter within our functions as the At-The-Money market volatility. However the SABR model actually treats this as some 'Beta' or 'SABR' volatility. In practice one can set this value to the ATMVol and solve for the other parameters. However if you are fixing some of the parameters of the SABR model except the 'ATMVol' parameter before calibrating, you may find that the ATMVol parameter that is implied out is not the At-The-Money market volatility. You may also find this to be the case when using the ConjugateGradient() or SteepestDescent() multi-dimensional optimization objects. In these cases the interpretation of the ATMVol is no longer the At-The-Money market volatility but some 'Beta' or 'SABR' volatility to correspond with the SABR model.
- CapeTools Heston Calibration
General Description
Functions for calibrating the parameters of the following Heston, Bates models :
- Heston model
- Bates model
- Bates Double-Exponential Jump Diffusion with Deterministic Jump Intensity model
- Bates Log-Normal Jump Diffusion with Deterministic Jump Intensity model
- Bates Double-Exponential Jump Diffusion model
You can selectively fix the values of some of the parameters and calibrate the others.
- CapeTools LMM Calibration
General Description
Functions to calibrate the parameters of the Libor Market Model objects.
- CalibrateModelLFM() (Calibrates the linear exponential volatility parameters of a Forward Libor Market Model given a list of calibration instruments)
- CalibrateModelLFM_2() (Calibrates the linear exponential volatility parameters of a Forward Libor Market Model given a list of calibration instruments)
Parameters calibrated from the CalibrateModelLFM() and CalibrateModelLFM_2() functions can be passed to the LiborMarketModel() or LiborMarketModel2() functions.
- CapeTools IR Calibration
General Description
Functions to calibrate the parameters of the interest rate model objects.
The interest rate calibrations are conducted via the following functions.
- CalibrateModelG2() (Calibrates the parameters of a G2 interest rate ShortRateModel via a G2 2 Factor Swaption Engine)
- CalibrateModelG2_2() (Calibrates the parameters of a G2 interest rate ShortRateModel via a G2 2 Factor Swaption Engine)
- CalibrateModelJAM() (Calibrates the parameters of an interest rate ShortRateModel (ie HullWhite, Vasicek) via a Jamshidian Swaption Engine)
- CalibrateModelJAM_2() (Calibrates the parameters of an interest rate ShortRateModel (ie HullWhite, Vasicek) via a Jamshidian Swaption Engine)
- CalibrateModelOSTree() (Calibrates the parameters of an interest rate ShortRateModel (ie BlackKarasinski, HullWhite, Vasicek, G2) via a Tree Swaption Engine)
- CalibrateModelOSTree_2() (Calibrates the parameters of an interest rate ShortRateModel (ie BlackKarasinski, HullWhite, Vasicek, G2) via a Tree Swaption Engine)
- CalibrateModelCFTree() (Calibrates the parameters of an interest rate ShortRateModel (ie BlackKarasinski, HullWhite, Vasicek, G2) via a Tree CapFloor Engine)
- CalibrateModelCFTree_2() (Calibrates the parameters of an interest rate ShortRateModel (ie BlackKarasinski, HullWhite, Vasicek, G2) via a Tree CapFloor Engine)
- CalibrateModelCFAnalytic() (Calibrates the parameters of an interest rate ShortRateModel (ie HullWhite, Vasicek, G2) via a Analytical CapFloor Engine)
- CalibrateModelCFAnalytic_2() (Calibrates the parameters of an interest rate ShortRateModel (ie HullWhite, Vasicek, G2) via a Analytical CapFloor Engine)
- CalibrateModelCFOS() (Calibrates the parameters of an interest rate ShortRateModel (ie BlackKarasinski, HullWhite, Vasicek, G2) via various user defined pricing engines)
- CalibrateModelCFOS_2() (Calibrates the parameters of an interest rate ShortRateModel (ie BlackKarasinski, HullWhite, Vasicek, G2) via various user defined pricing engines)
- CapeTools IR Engine
General Description
Functions to create several interest engines for the pricing of interest rate products (Caps, Floors, Swaptions and BondOptions). The following pricing engines can be constructed :
- G2 two-factor Swaption Engine (European and Bermudan options)
- Tree Swaption Engine (European and Bermudan options)
- Tree CapFloor Engine
- Black CapFloor Engine (European option only)
- Forward Libor Market Model Swaption Engine (used for calibration only)
- Jamshidian Swaption Engine (used for calibration only)
- CapeTools Vanilla Engine
General Description
Functions to create several engines for the pricing of vanilla options. You can price Vanilla options via the VanillaOption() function using one of the following engines :
- Integral European Engine (Integrates the payoff)
- Analytic European Engine (classic Black-Scholes formula)
- Analytic European Dividend Digital Engine
- Pseudo European Monte-Carlo Engine
- Pseudo European Monte-Carlo Digital Engine
- Quasi European Monte-Carlo Engine
- Quasi European Monte-Carlo Digital Engine
- Jump Diffusion Engine
- CapeTools Vanilla Tree Engine
General Description
Functions to create several Binomial Tree engines for the pricing of vanilla options. You can price Vanilla options via the VanillaOption() function using one of the following engines :
- Jarrow Rudd Binomial Tree Engine
- Cox Ross Rubinstein Binomial Tree Engine
- Additive equal probability Binomial Tree Engine
- Trigeorgis Binomial Tree Engine
- Tian Binomial Tree Engine
- Leisen Reimer Binomial Tree Engine
- CapeTools ConvertibleBond Engine
General Description
Functions to create several Tsiveriotis-Fernandes engines for the pricing of convertible bonds. You can price Convertible Bonds via the ConvertibleBond() function using one of the following engines :
- Jarrow Rudd Tsiveriotis-Fernandes Engine
- Cox Ross Rubinstein Tsiveriotis-Fernandes Engine
- Additive equal probability Tsiveriotis-Fernandes Engine
- Trigeorgis Tsiveriotis-Fernandes Engine
- Tian Tsiveriotis-Fernandes Engine
- Leisen Reimer Tsiveriotis-Fernandes Engine
- CapeTools FD Engine
General Description
Functions to create several Finite Difference engines for the pricing of vanilla options. You can price Vanilla options via the VanillaOption() function using one of the following engines :
- European Finite Difference Engine
- American Finite Difference Engine
- Bermudan Finite Difference Engine
- Shout Finite Difference Engine
- Dividend European Finite Difference Engine
- Dividend American Finite Difference Engine
- Dividend Shout Finite Difference Engine
- CapeTools Asian Engine
General Description
Functions to create several Asian engines for the pricing of Asian options. You can price Asian options by executing the ContinuousAsianOption() or DiscreteAsianOption() functions using one of the following engines :
- Analytic Continuous Geometric Average Price Asian Engine
- Analytic Discrete Geometric Average Price Asian Engine
- Pseudo MonteCarlo Discrete Arithmetic Average Price Engine
- Pseudo MonteCarlo Discrete Geometric Average Price Engine
- Quasi MonteCarlo Discrete Arithmetic Average Price Engine
- Quasi MonteCarlo Discrete Geometric Average Price Engine
- CapeTools American Engine
General Description
Functions to create several American engines for the pricing of American vanilla options. You can price American options via the VanillaOption() function using one of the following engines :
- Analytic Digital American Engine
- Barone Adesi Whaley Approximation Engine
- Bjerksund Stensland Approximation Engine
- Ju Quadratic Approximation Engine
- CapeTools Cliquet Engine
General Description
Functions to create several Cliquet engines for the pricing of Cliquet options. You can price Cliquet options via the CliquetOption() function using one of the following engines :
- Analytic Cliquet Engine
- Analytic Performance Engine
- CapeTools Barrier Engine
General Description
Functions to create several Barrier engines for the pricing of Barrier options. You can price Barrier options via the BarrierOption() function using one of the following engines :
- Analytic Barrier Engine
- Pseudo MonteCarlo Barrier Engine
- Quasi MonteCarlo Barrier Engine
- CapeTools Basket Engine
General Description
Functions to create several Basket engines for the pricing of Basket options. You can price Basket options via the BasketOption() function using one of the following engines :
- Stulz Engine for pricing 2D European basket options (Only 2 assets)
- Pseudo MonteCarlo Basket Engine (American and European)
- Quasi MonteCarlo Basket Engine (American and European)
- CapeTools Generic Engine
General Description
No functions present as yet.
- CapeTools EngineOptions
General Description
Functions to price option products under a pricing engine framework.
To price a single product under this framework, you require 5 objects to be constructed. These are :
- A pricing engine object
- An exercise object
- A payoff object
- One or more process objects
- A pricer object
The pricing engine object specifies the method of calculation (Tree, MC, direct, integration etc...).
The exercise object specifies the date(s) that exercise can take place.
The payoff object specifies the payoff function.
The process object(s) specifies the characteristics of the underlyer(s) whether Equity, FX or Commodity.
The pricer object takes in the Engine, Exercise, Payoff and Process objects and compute a price.
This category of functions contain the type of Equity, FX or Commodity type pricer objects that can be created and priced.
- European Options
- Bermudan Options
- American Options
- Digital Options
- Asian Options
- Basket Options
- Barrier Options
- Convertible Bond
- Cliquet Options.
Some of the pricer objects can utilise more than one type of pricing engine. There are pricing engines can utilise the following methods of calculation :
- Analytical
- Montecarlo
- Finite-difference
- Integration
- Binomial Tree engines
The Equity, FX or Commodity type pricing engines can be created from one of the following categories of functions :
The combinations of the 5 object types that are needed to price a single product can be confusing.
The confusion comes because there are many pricing engines, Exercise and Pricer objects that can be chosen.
As a guide for product pricing, we have identified the following combinations :
American Options
- Pricing Engines - BAWApproxEngine(), BSApproxEngine(), JQApproxEngine(), FDAmericanEngine(), FDShoutEngine()
- Exercise object - AmericanExercise()
- Payoff object - PlainVanilla(), GenericPayOff()
- Pricer object - VanillaOption()
Discrete Asian Options
- Pricing Engines - DiscreteAsianEngine(), PMCArithmeticAsianEngine(), PMCGeometricAsianEngine(), QMCArithmeticAsianEngine(), QMCGeometricAsianEngine()
- Exercise object - EuropeanExercise()
- Payoff object - PlainVanilla()
- Pricer object - DiscreteAsianOption()
Continuous Asian Options
- Pricing Engines - ContinuousAsianEngine()
- Exercise object - EuropeanExercise()
- Payoff object - PlainVanilla()
- Pricer object - ContinuousAsianOption()
Barrier Options
- Pricing Engines - AnalyticBarrierEngine(), PMCBarrierEngine(), QMCBarrierEngine()
- Exercise object - EuropeanExercise()
- Payoff object - PlainVanilla()
- Pricer object - BarrierOption()
Basket Options
- Pricing Engines - StulzEngine(), PMCBasketEngine(), QMCBasketEngine()
- Exercise object - EuropeanExercise()
- Payoff object - PlainVanilla()
- Pricer object - BasketOption()
Cliquet Options
- Pricing Engines - AnaCliquetEngine(), AnaPerformanceEngine()
- Payoff object - PercentageStrike()
- Exercise object - EuropeanExercise()
- Pricer object - CliquetOption()
Cash-Or-Nothing Options
- Pricing Engines - AnalyticEuropeanEngine(), PMCDigitalEngine(), QMCDigitalEngine()
- Payoff object - CashOrNothingPayoff()
- Exercise object - EuropeanExercise()
- Pricer object - VanillaOption()
Asset-Or-Nothing Options
- Pricing Engines - AnalyticEuropeanEngine(), PMCDigitalEngine(), QMCDigitalEngine()
- Payoff object - AssetOrNothingPayoff()
- Exercise object - EuropeanExercise()
- Pricer object - VanillaOption()
Gap Options
- Pricing Engines - AnalyticEuropeanEngine()
- Payoff object - GapPayoff()
- Exercise object - EuropeanExercise()
- Pricer object - VanillaOption()
Cash-At-Hit-Or-Nothing American Options
- Pricing Engines - AnaDigitalAmEngine()
- Payoff object - CashOrNothingPayoff()
- Exercise object - AmericanExercise(payoffAtExpiry=false)
- Pricer object - VanillaOption()
Asset-At-Hit-Or-Nothing American Options
- Pricing Engines - AnaDigitalAmEngine()
- Payoff object - AssetOrNothingPayoff()
- Exercise object - AmericanExercise(payoffAtExpiry=false)
- Pricer object - VanillaOption()
Cash-At-Expiry-Or-Nothing American Options
- Pricing Engines - AnaDigitalAmEngine()
- Payoff object - CashOrNothingPayoff()
- Exercise object - AmericanExercise(payoffAtExpiry=true),
- Pricer object - VanillaOption()
Asset-At-Expiry-Or-Nothing American Options
- Pricing Engines - AnaDigitalAmEngine()
- Payoff object - AssetOrNothingPayoff()
- Exercise object - AmericanExercise(payoffAtExpiry=true),
- Pricer object - VanillaOption()
Various (depending on the Payoff object) Dividend Options
- Pricing Engines - AnaDivEuroEngine(), FDDividendEuropeanEngine()
- Exercise object - EuropeanExercise(),
- Payoff object - CashOrNothingPayoff(), AssetOrNothingPayoff(), GapPayoff(), PlainVanilla(), GenericPayOff()
- Pricer object - DivVanillaOption()
Various (depending on the Payoff object) American Dividend Options
- Pricing Engines - FDDividendAmericanEngine()
- Exercise object - AmericanExercise(),
- Payoff object - CashOrNothingPayoff(), AssetOrNothingPayoff(), GapPayoff(), PlainVanilla(), GenericPayOff()
- Pricer object - DivVanillaOption()
Various (depending on the Payoff object) Non-Dividend European Options
- Tree Pricing Engines - AdditiveEQPEngine(), CoxRossRubinsteinEngine(), JarrowRuddEngine(), LeisenReimerEngine(), TianEngine(), TrigeorgisEngine()
- Analytical Pricing Engines - AnalyticEuropeanEngine()
- Finite Difference Pricing Engines - FDEuropeanEngine()
- Integral Pricing Engines - IntegralEngine()
- Monte-Carlo Pricing Engines - PseudoMonteCarloEngine(), QuasiMonteCarloEngine()
- Exercise object - EuropeanExercise(),
- Payoff object - CashOrNothingPayoff(), AssetOrNothingPayoff(), GapPayoff(), PlainVanilla(), GenericPayOff()
- Pricer object - VanillaOption()
Merton (1976) European Options
- Pricing Engines - JumpDiffusionEngine()
- Process object - Merton76Process( AnalyticEuropeanEngine() )
- Exercise object - EuropeanExercise(),
- Payoff object - CashOrNothingPayoff(), AssetOrNothingPayoff(), GapPayoff(), PlainVanilla(), GenericPayOff()
- Pricer object - VanillaOption()
The GenericPayOff() payoff object generally applies to the Integral, PDE and Tree engines. Here are some of the most common engines that you are likely to use with the GenericPayOff() payoff engine.
- AdditiveEQPEngine()
- CoxRossRubinsteinEngine()
- JarrowRuddEngine()
- LeisenReimerEngine()
- TianEngine()
- TrigeorgisEngine()
- IntegralEngine()
- FDEuropeanEngine()
You must ensure however that your payoff does not violate the rules of the Black-Scholes SDE.
If you do not see a pricing function here which matches your particular payoff, you can use the generic pricing functions present within the following categories of functions :
These categories of functions allow you to provide your own pricing functions within a pricing grid.
- CapeTools IREngineOptions
General Description
Functions to price a range of interest rate derivatives.
- Caps,
- Floors,
- Collars,
- European Callable Bonds
- Bermudan Callable Bonds
- European Swaptions
- Bermudan Swaptions
These functions require the correct pricing engine to be constructed and these can be supplied via the functions present within the CapeTools IR Engine category of functions.
Convertible Bond pricing is present within the CapeTools EngineOptions category of functions.
The European and Bermudan Callable Bond functions presented here overcome some disadvantages that the functions within the CapeTools Bond Options category contain.
These functions can handle correctly Bond Objects with the following features :
- Amortised Notional
- Step Up/Down Coupon rates.
If you do not see a function here which matches your particular payoff, you can use the generic pricing functions present within the following categories of functions :
These categories of functions allow you to provide your own pricing functions within a pricing grid.
- CapeTools Statistical Distributions
General Description
Functions to create Statistical Distribution objects (both Discrete and Continuous). You can either create classical distribution objects or create distribution objects given raw data. The latter distribution objects can then be subject to a variety of hypotheses tests.
The types of classical distributions that can be created are :
- Bernoulli
- Binomial
- Chi-square
- Continuous Constant
- Continuous Uniform
- Discrete Constant
- Discrete Uniform
- Exponential
- Hypergeometric
- Normal
- Lognormal
- Poisson
- Rayleigh
- F
- Student's T
- Weibull
Once these distribution objects have been created you can create Random Process objects from them and thus generate random numbers. You can additionally query the distribution objects for its properties.
- CapeTools Query Statistical Distributions
General Description
Functions to query the properties of a Continuous Statistical Distribution object (ie - mean, variance and standard deviation,).
Functions to generate statistical values of a Continuous Statistical Distribution object (ie - execute the probability density function, cumulative distribution function, inverse cumulative distribution and the hazard function)
Functions to query the properties of a Discrete Statistical Distribution object (ie - mean, variance and standard deviation,).
Functions to generate statistical values of a Discrete Statistical Distribution object (ie - execute the probability function and the cumulative function)
- CapeTools Statistical Hypothesis Objects
General Description
Functions to create Hypothesis testing objects given a Generic Continuous Distribution object. A Generic Continuous Distribution object is an object created via the GenericContinuousDist() function and populated with user data. The user now wishes to compare the properties of this generic distribution against the normal distribution.
The types of Hypothesis testing objects that can be created are.
- Hypothesis objects for the mean of normal distribution with known sigma.
- Hypothesis objects for the mean of normal distribution with unknown sigma.
- Hypothesis objects for the difference between means of two normal distributions with known sigmas (not paired).
- Hypothesis objects for the difference between means of two normal distributions with unknown sigmas (not paired).
- Hypothesis objects for the variance of normal distribution.
- Hypothesis objects for the ratio of two variances (F-Test).
- CapeTools Query Statistical Hypothesis Objects
General Description
Functions to execute a hypothesis test given a Hypothesis testing object.
The types of Hypothesis testing that can be conducted are.
- Test for the mean of normal distribution with known sigma.
- Test for the mean of normal distribution with unknown sigma.
- Test for the difference between means of two normal distributions with known sigmas (not paired).
- Test for the difference between means of two normal distributions with unknown sigmas (not paired).
- Test for the variance of normal distribution.
- Test for the ratio of two variances (F-Test).
Given these testing objects, the functions present here can apply one-sided or two-sided tests. You can retrieve the probability of getting the observed test statistic value as well as the result of the test.
- CapeTools Statistical Random Process Objects
General Description
Functions to create Statistical Random Process Object given a Statistical Distribution object. A Statistical Random Process Object generates random numbers. It is important to note that once the object has been created, you set the Reload flag parameter to zero (0). This will prevent the object from being re-created.
- CapeTools Statistical Random Generators
General Description
Functions to generate random numbers given a Statistical Random Process Object.
- CapeTools Technical Analysis
General Description
Functions to create a technical analysis object based on historical data (created via the MakeHistoricalDB().
The algorithms used were taken from the TA-SDK library (www.ta-lib.org). Please view this site for a complete description of the methodologies and pricing equations.
- CapeTools Technical Analysis - Math Operators
General Description
Functions to apply technical analysis on historical data objects (created via the MakeHistoricalDB() function) using Math Operator techniques.
The algorithms used were taken from the TA-SDK library (www.ta-lib.org). Please view this site for a complete description of the methodologies and pricing equations.
- CapeTools Technical Analysis - Overlap Studies
General Description
Functions to apply technical analysis on historical data objects (created via the MakeHistoricalDB() function) using Overlap Study techniques.
The algorithms used were taken from the TA-SDK library (www.ta-lib.org). Please view this site for a complete description of the methodologies and pricing equations.
- CapeTools Technical Analysis - Volatility Indicators
General Description
Functions to apply technical analysis on historical data objects (created via the MakeHistoricalDB() function) using Volatility Indicator techniques.
The algorithms used were taken from the TA-SDK library (www.ta-lib.org). Please view this site for a complete description of the methodologies and pricing equations.
- CapeTools Technical Analysis - Momentum Indicators
General Description
Functions to apply technical analysis on historical data objects (created via the MakeHistoricalDB() function) using Momentum Indicator techniques.
The algorithms used were taken from the TA-SDK library (www.ta-lib.org). Please view this site for a complete description of the methodologies and pricing equations.
- CapeTools Technical Analysis - Cycle Indicators
General Description
Functions to apply technical analysis on historical data objects (created via the MakeHistoricalDB() function) using Cycle Indicator techniques.
The algorithms used were taken from the TA-SDK library (www.ta-lib.org). Please view this site for a complete description of the methodologies and pricing equations.
- CapeTools Technical Analysis - Volume Indicators
General Description
Functions to apply technical analysis on historical data objects (created via the MakeHistoricalDB() function) using Volume Indicator techniques.
The algorithms used were taken from the TA-SDK library (www.ta-lib.org). Please view this site for a complete description of the methodologies and pricing equations.
- CapeTools Technical Analysis - Pattern Recognition
General Description
Functions to apply technical analysis on historical data objects (created via the MakeHistoricalDB() function) using Pattern Recognition techniques.
The algorithms used were taken from the TA-SDK library (www.ta-lib.org). Please view this site for a complete description of the methodologies and pricing equations.
The candlestick techniques we use today originated in the style of technical charting used by the Japanese for over 100 years before the West developed the bar and point-and-figure analysis systems. In the 1700s a Japanese man named Homma, a trader in the futures market, discovered that, although there was a link between price and the supply and demand of rice, the markets were strongly influenced by the emotions of the traders. He understood that when emotions played into the equation a vast difference between the value and the price of rice occurred. This difference between the value and the price is as applicable to stocks today as it was to rice in Japan centuries ago. The principles established by Homma are the basis for the candlestick chart analysis, which is used to measure market emotions towards a stock.
This charting technique has become very popular among traders. One reason is that the charts reflect only short-term outlooks--sometimes lasting less than eight to 10 trading sessions. Candlestick charting is a very complex and sometimes difficult system to understand
When first looking at a candlestick chart, the student of the more common bar charts may be confused; however, just like a bar chart, the daily candlestick line contains the market's open, high, low and close of a specific day. Now this is where the system takes on a whole new look: the candlestick has a wide part, which is called the 'real body'. This real body represents the range between the open and close of that day's trading. When the real body is filled in or black, it means the close was lower than the open. If the real body is empty, it means the opposite: the close was higher than the open.
Just above and below the real body are the "shadows". Chartists have always thought of these as the wicks of the candle, and it is the shadows that show the high and low prices of that day's trading. If the upper shadow on the filled-in body is short, it indicates that the open that day was closer to the high of the day. And a short upper shadow on a white or unfilled body dictates that the close was near the high. The relationship between the day's open, high, low, and close determine the look of the daily candlestick. Real bodies can be either long or short and either black or white. Shadows can also be either long or short.
Within a chart you will typically see 'long black body', or 'long black line' bars. The long black line represents a bearish period in the marketplace. During the trading session, the price of a stock can be up and down in a wide range and can open near the high and close near the low of the day.
By representing a bullish period, the 'long white body', or 'long white line' is the exact opposite of the long black line. Prices can be all over the map during the day, but the stock can open near the low of the day and close near the high.
'Spinning tops' are very small bodies and can be either black or white. This pattern shows a very tight trading range between the open and the close, and it is considered somewhat neutral.
'Doji lines' illustrate periods in which the opening and closing prices for the period are very close or exactly the same. You will also notice that, when you start to look deep into candlestick patterns, the length of the shadows can vary.
White candlestick: If the close is higher than the open, the real body is white. A white (Yang) candlestick indicates buying dominance after the open.
Black candlestick: If the close is lower than the open, the real body is filled in black. A black (Yin) candlestick indicates selling dominance after the open.
The real body is the most important part of each candlestick. The shade (white or black) and length of the real body reveals whether the bulls or bears are dominant during the main period of trading. A long white real body implies that the bulls are in charge. A long black real body implies that the bears are in charge. Candlesticks with very small real bodies, where the difference between the open and close are relatively tiny compared to normal trading ranges, imply that neither side is currently in charge and, furthermore, that the previous trend may be worn out.
Shadows are the part of the price range that lies outside the real body's open-to-close price range. Shadows are represented as thin lines extending from the real body to the extreme high and low prices for the period, above and below the real body. The peak of the "upper shadow" is the high of the period, while the bottom of the "lower shadow" is the low of the period.
Marubozu lines lack shadows at one or both extremes: The open and/or the close is the extreme high or low price of the period. Major Yang Marubozu lines have the close equal to the extreme high and indicate extreme buying, which is bullish. Major Yin Marubozu lines have the close equal to the extreme low and indicate extreme selling, which is bearish. When the opening is the low, there is buying dominance during the period, which is bullish. When the opening is the high, there is selling dominance during the period, which is bearish.
The length and position of the shadows are meaningful. A tall upper shadow implies that the market rejected higher prices and is heading lower. A long lower shadow implies that the market rejected lower prices and is heading higher. Very long shadows, both upper and lower, are known as high-wave lines, and these indicate that the market has lost its sense of direction. Multiple high-wave lines indicate trend reversal.
- CapeTools Technical Analysis - Statistic Functions
General Description
Functions to apply technical analysis on historical data objects (created via the MakeHistoricalDB() function) using Statistic Function techniques.
The algorithms used were taken from the TA-SDK library (www.ta-lib.org). Please view this site for a complete description of the methodologies and pricing equations.
- CapeTools Technical Analysis - Price Transform
General Description
Functions to apply technical analysis on historical data objects (created via the MakeHistoricalDB() function) using Price Transform techniques.
The algorithms used were taken from the TA-SDK library (www.ta-lib.org). Please view this site for a complete description of the methodologies and pricing equations.
- CapeTools Utils
General Description
Functions to read in XML documents (currently we do not support the usage of namespaces within the documents and the documents cannot be validated against a Schema) and to apply generic XPath query to retrieve XML nodes.
Functions to interpolate one-dimensional and two-dimensional ranges using a variety of interpolation methods.
Most barrier options pricing formulas assumes continuous monitoring of the barrier. We provide a function to convert continuous barriers to discrete barriers.
Functions to integrate (Segment, Trapezoid, Mid Point Trapezoid, Simpson and Kronrod integration methodologies) generic user defined functions of one variable.
Functions to manipulate interest rates from one frequency or compounding to another and to compute discount factors (compound factors) given these rates.
Functions to generate amortised schedules based on straight-line depreciation, sum-of-years digits depreciation, general-declining balance depreciation and fixed-declining balance depreciation methods.
- CapeTools Grid Computing Tools
General Description
These functions are used to save an object graph to memory, XML string or XML file in order to ease GRID programming.
What is GRID programming?
A server processing database requests from multiple clients is a common example of a distributed system. Using a single server machine in such a scenario often results in unwanted delays to its clients due to the processing load on the server. A supercomputer or any other multiprocessor computer can solve this problem, but these computers are not freely available and are often too expensive.
The power of a supercomputer can be simulated by applying Grid technology to the under-utilized resources of available computers.
Grid computing is an emerging computing model that provides the ability to perform higher throughput computing by taking advantage of many networked computers to model a virtual computer architecture that is able to distribute process execution across a parallel infrastructure. Grids use the resources of many separate computers connected by a network (usually the Internet) to solve large-scale computation problems. Grids provide the ability to perform computations on large data sets, by breaking them down into many smaller ones, or provide the ability to perform many more computations at once than would be possible on a single computer, by modeling a parallel division of labour between processes.
Grid computing offers a model for solving massive computational problems by making use of the unused resources (CPU cycles and/or disk storage) of large numbers of disparate computers, often desktop computers, treated as a virtual cluster embedded in a distributed telecommunications infrastructure. Grid computing's focus on the ability to support computation across administrative domains sets it apart from traditional computer clusters or traditional distributed computing.
Grids offer a way to solve Grand Challenge problems like protein folding, financial modelling, earthquake simulation, and climate/weather modelling. Grids offer a way of using the information technology resources optimally inside an organization. They also provide a means for offering information technology as a utility bureau for commercial and non-commercial clients, with those clients paying only for what they use, as with electricity or water.
Grid computing has the design goal of solving problems too big for any single supercomputer, whilst retaining the flexibility to work on multiple smaller problems. Thus Grid computing provides a multi-user environment. Its secondary aims are better exploitation of available computing power and catering for the intermittent demands of large computational exercises.
This approach implies the use of secure authorization techniques to allow remote users to control computing resources.
Grid computing involves sharing heterogeneous resources (based on different platforms, hardware/software architectures, and computer languages), located in different places belonging to different administrative domains over a network using open standards. In short, it involves virtualizing computing resources.
Grid computing is often confused with cluster computing. The key difference is that a cluster is a single set of nodes sitting in one location, while a Grid is composed of many clusters and other kinds of resources (e.g. networks, storage facilities).
Thus a grid is a type of parallel and distributed system that enables the sharing, selection, and aggregation of geographically distributed "autonomous" resources dynamically at runtime depending on their availability, capability, performance, cost, and users' quality-of-service requirements.
Thus, at the most basic level, a grid can be viewed as an aggregation of multiple machines (each with one or more CPUs) abstracted to behave as one "virtual" machine with multiple CPUs.
Various commercial and open source software toolkits are available to build such a Grid environment. Among them, the Globus Toolkit has been widely used in research all over the world for longer than a decade, while Alchemi is the latest addition to Grid software.
Alchemi and the Globus Toolkit are two open source software toolkits implementing a Grid environment. Alchemi runs on the Windows operating system in the .NET Framework while the Globus Toolkit has its origins in Linux. The complete Globus Toolkit is only available in Linux, but recent versions include some of its functionality also for Windows. The Globus Toolkit supports Java, C++, and Perl (among others) for the development of services. But the Windows .NET framework is not supported for Globus. Alchemi provides an API for DotNet and C++, and operates in the Windows .NET framework.
Most financial API toolkits provide functions which are fire and forget functions.
You pass the parameters, execute the function and the results are returned. Any state or objects created during the calculation of this function are cleaned up on exiting.
This is perfect for GRID computing.
The problem that our library face is that we use objects. As a result, many functions can be composed from objects with complicated inputs. A kind of LEGO approach to pricing. Because of this, you may have an object which has been created from 30 other objects.
In order to ease GRID computing via our library, the functions within this category of functions enable you to serialise an object graph to memory, file or XML string.
An object graph is simply all the parameters and objects needed to re-create the object. Any object that may have served as inputs to this object when it was created is part of the object graph.
For instance, the example for the XCcySwapPortfolio() function requires the construction of over 20 objects. You could code this logic within a GRID computing class, or you can save the object graph to a XML file or XML string and instead write code that simpy de-serialises the object graph. Further function calls would then interrogate any of the 20 re-created objects.
In a non-GRID environment, an excellent use for this also, would be to create objects (ie - yieldcurve), save this object to memory, and then further manipulate the orginal object (ie - change rates). Later, you can apply (re-create) the object graph saved earlier into memory, and you will have a new instances of all the objects saved (a new instance of all the objects needed to re-create the yieldcurve all with new key-names).
These new objects are basically a copy of the data taken at the time of serialisation. In fact this can be regarded as taking a static snapshot. A snapsht that can be saved to disk and re-read days, weeks later, used within the Excel or API functions, passed to associates etc... It also represents a way of saving data outside of Excel and inserting the object data into a database.
These functions, however, were coded in order to make GRID programming easier. Every object that is created from an object generating function (a function that returns a key-string) can be saved to memory (not really useful for GRID computing), XML file or a XML string.
The file is simply an XML file stored on disk and thus if using a Java or DotNET GRID framework, these languages provide objects to read in XML files.
Because of the complex nature of this library, you could proto-type your objects within Excel, seralise the objects to file, or XML, then within a GRID programming model, distribute the XML or file (via the GRID framework) to the client nodes where they would reload the objects. Your own individual GRID code would then act upon these objects.
In the case of constructing a XCcySwapPortfolio() object one would not need to write code to construct the initial 20 objects. If the portfolio is large, you could price the portfolio remotely. while your application works on another task until the results are returned.
Another great example of this would be to create a Monte-Carlo object and then using the GRID framework to instruct each node (machine) to simulate 100 paths and price a certain structure.
We like the Alchemi.NET Grid Computing Framework because it provides, in our minds, a programming model not so difference from OOP.
Probably also because we prefer .NET!!
Alchemi .NET Grid Computing Framework - http://www.alchemi.net
GLOBUS - http://www.globus.org
- CapeTools Query Market
General Description
Functions to query some market objects (ie - Index, Libor type, objects and Calendar objects). You can retrieve detailed information given an Index objects as well as test for business days, test for holidays, retrieve a list of holidays or business days and apply date adjustments.
- CapeTools Enums
General Description
Functions to retrieve string versions of general enumeration types.
These functions are mainly for the benefit of Excel users as enumeration objects has no as yet been exposed out to this platform. One can type these enumeration values directly into function parameters but using these functions ensure that a typo has not occurred.
All enumeration string types are case-insensitive.
- CapeTools Currency Enums
General Description
Functions to retrieve string versions of Currency code enumeration types.
These functions are mainly for the benefit of Excel users as enumeration objects has no as yet been exposed out to this platform. One can type these enumeration values directly into function parameters but using these functions ensure that a typo has not occurred.
All enumeration string types are case-insensitive.
- CapeTools Compounding Enums
General Description
Functions to retrieve string versions of Compounding enumeration types.
These functions are mainly for the benefit of Excel users as enumeration objects has no as yet been exposed out to this platform. One can type these enumeration values directly into function parameters but using these functions ensure that a typo has not occurred.
All enumeration string types are case-insensitive.
- CapeTools Frequency Enums
General Description
Functions to retrieve string versions of Frequency enumeration types.
These functions are mainly for the benefit of Excel users as enumeration objects has no as yet been exposed out to this platform. One can type these enumeration values directly into function parameters but using these functions ensure that a typo has not occurred.
All enumeration string types are case-insensitive.
- CapeTools BusinessDayConvention Enums
General Description
Functions to retrieve string versions of Business-Day-Convention enumeration types.
These functions are mainly for the benefit of Excel users as enumeration objects has no as yet been exposed out to this platform. One can type these enumeration values directly into function parameters but using these functions ensure that a typo has not occurred.
All enumeration string types are case-insensitive.
- CapeTools DayCount Enums
General Description
Functions to retrieve string versions of DayCount enumeration types.
These functions are mainly for the benefit of Excel users as enumeration objects has no as yet been exposed out to this platform. One can type these enumeration values directly into function parameters but using these functions ensure that a typo has not occurred.
All enumeration string types are case-insensitive.
- CapeTools QueryDB
General Description
Functions to write a range or ranges of data (Excel range or the API version of a range) to an XML file and to read these back in again.
Functions to write a range or ranges of data (Excel range or the API version of a range) to memory and to read these back in again.
Given ANY object generated string-key generated via a CapeTools function, you can query for a parameter value or the list of parameter names and types that were used when the function was called.
Functions to list or delete created objects via the object generated string-keys.
- CapeTools Matrix Math Operations
General Description
Functions to apply mathematical functions against numeric ranges (excel ranges also) objects (ie - log, exp, abs, sqrt etc...)
- CapeTools Range Utils
General Description
Functions to apply basic mathematical functions against numeric ranges (excel ranges also) objects (ie - max, min etc...)
Functions create a range given a matrix formatted string (Used heavily within the example for ease of display) and to create a string given a string (great for debugging purposes).
Functions to manipulate ranges (excel ranges also) objects (ie - transpose, rotate, flip, concatenate, reshape, add, subtract, multiply, sum, sum rows, sum columns etc...)
Functions to select portions of ranges (excel ranges also) objects (ie - select column(s), select row(s) and select a sub range.)
- CapeTools FpML
General Description
Functions to read in FpML documents (the documents are not validated against a Schema) and to apply generic XPath query to retrieve XML nodes. You can also execute the ReadXML() and XMLGenericQuery() functions (present within the 'CapeTools Utils' category of function) in order to read in and query any XML document (does not support namespaces within the documents).
- CapeTools FpML Swaps
General Description
XPath queries that support the retrieval of Swap nodes within the FpML document.
If you cannot find a function that retrieves the nodes that you require you can always execute the FpMLGenericQuery() function. This function supports most of the XPath query language.
- CapeTools FpML SwapsExt
General Description
XPath queries that support the retrieval of more Swap nodes within the FpML document.
If you cannot find a function that retrieves the nodes that you require you can always execute the FpMLGenericQuery() function. This function supports most of the XPath query language.
- CapeTools FpML Swaption
General Description
XPath queries that support the retrieval of Swaption nodes within the FpML document.
If you cannot find a function that retrieves the nodes that you require you can always execute the FpMLGenericQuery() function. This function supports most of the XPath query language.
- CapeTools FpML FRA
General Description
XPath queries that support the retrieval of FRA nodes within the FpML document.
If you cannot find a function that retrieves the nodes that you require you can always execute the FpMLGenericQuery() function. This function supports most of the XPath query language.
- CapeTools FpML CapFloor
General Description
XPath queries that support the retrieval of CapFloor nodes within the FpML document.
If you cannot find a function that retrieves the nodes that you require you can always execute the FpMLGenericQuery() function. This function supports most of the XPath query language.
- CapeTools FpML EquityOption
General Description
XPath queries that support the retrieval of EquityOption nodes within the FpML document.
If you cannot find a function that retrieves the nodes that you require you can always execute the FpMLGenericQuery() function. This function supports most of the XPath query language.
- CapeTools Currency
General Description
Functions to create Exchange Rate Manager objects and Money objects. Money objects can be created in any currency. You can apply addition, subtraction, multiplication and division of money objects and then view the results in any currency. You can also create Exchange Rate objects as well as Exchange Rate Chain objects. These objects can be queried for their conversion rates.
You can also make comparisons of the Money objects (LessThan, EqualTo, GreaterThan etc...) as well as extract information regarding a currency code (see CapeTools Currency Enums for a list of currency codes).
Copyright (c) 2003-2007 CapeTools - All Rights Reserved.
