Skip to main content

2002 | OriginalPaper | Buchkapitel

The Class Hierarchy of MtgLib—External

verfasst von : Robert Buff

Erschienen in: Uncertain Volatility Models — Theory and Application

Verlag: Springer Berlin Heidelberg

Aktivieren Sie unsere intelligente Suche, um passende Fachinhalte oder Patente zu finden.

search-config
loading …

MtgLib classes that correspond directly to input parameters and have some intuitive “meaning” to the user are called external. Instances of these classes are defined in MtgLib’s scripting language MtgScript, as defined in Appendix B. The following categories of external classes exist: Instruments: Maturity, payoff policy, knock-out policy and early-exercise policy are the dominant orthogonal features of instruments. American/European options with or without knock-out boundaries and with linear of digit al payoff are standardized in MtgLib.Portfolios: Instruments are combined into portfolios which generalize some of their properties (the longest maturity, for instance).Models: Models consist of specifications of factors and model coefficients, possibly uncertain. A one-factor Black-Scholes model is used in most of this book.Model coefficients: They may have their own classes to allow term structure. At this time, piecewise constant volatility and drift coefficients are supported. The volatility coefficient may be uncertain.Scenarios: Models and their (uncertain) coefficient s are interpreted according to a prescribed scenario. We have discussed worst- case volatility and volatility scenarios. Some consistency between the model and the scenario is required: if the model incorporates uncertain model coefficients, the scenario must be able to resolve the uncertainty.Numerical methods: MtgLib supports explicit or mixed implicit/ explicit finite difference schemes as well as Monte-Carlo simulation. The requirements diverge: while finite difference schemes are based on a collection of lattice instances, Monte Carlo methods require path instances which are treat ed differently. In MtgLib, lattices and path spaces are indeed separate objects.Evaluators: At first objects are passively stored in a repository. Concrete pricing operations are only triggered by specifying an evaluator object which lives only while the particular portfolio/model/scenario combination is evaluated. Evalu ators format and output the result.

Metadaten
Titel
The Class Hierarchy of MtgLib—External
verfasst von
Robert Buff
Copyright-Jahr
2002
Verlag
Springer Berlin Heidelberg
DOI
https://doi.org/10.1007/978-3-642-56323-2_11