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
Enthalten in: Professional Book Archive
Aktivieren Sie unsere intelligente Suche, um passende Fachinhalte oder Patente zu finden.
Wählen Sie Textabschnitte aus um mit Künstlicher Intelligenz passenden Patente zu finden. powered by
Markieren Sie Textabschnitte, um KI-gestützt weitere passende Inhalte zu finden. powered by
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.