Note: This page has been translated by MathWorks. Please click here

To view all translated materals including this page, select Japan from the country navigator on the bottom of this page.

To view all translated materals including this page, select Japan from the country navigator on the bottom of this page.

Most models and utilities available with Monte Carlo Simulation
of SDEs are represented as MATLAB^{®} objects. Therefore, this documentation
often uses the terms *model* and *object* interchangeably.

However, although all models are represented as objects, not
all objects represent models. In particular, `drift`

and `diffusion`

objects
are used in model specification, but neither of these types of objects
in and of themselves makes up a complete model. In most cases, you
do not need to create `drift`

and `diffusion`

objects
directly, so you do not need to differentiate between objects and
models. It is important, however, to understand the distinction between
these terms.

In many of the following examples, most model parameters are
evaluated or invoked like any MATLAB function. Although it is
helpful to examine and access model parameters as you would data structures,
think of these parameters as *functions* that perform *actions*.

You use *constructors* to create SDE objects.

For examples and more information, see:

Objects display like traditional MATLAB data structures.

Displayed object parameters appear as nouns that begin with capital letters. In contrast, parameters such as

`simulate`

and`interpolate`

appear as verbs that begin with lowercase letters, which indicate tasks to perform.

Objects support referencing similar to data structures. For example, statements like the following are generally valid:

A = obj.A

Objects support complete parameter assignment similar to data structures. For example, statements like the following are generally valid:

obj.A = 3

Objects do not support partial parameter assignment as data structures do. Therefore, statements like the following are generally

**invalid**:obj.A(i,j) = 0.3

You can construct objects of any model class only if enough information is available to determine unambiguously the dimensionality of the model. Because various class constructors offer unique input interfaces, some models require additional information to resolve model dimensionality.

You need only enter required input parameters in placeholder format, where a given input argument is associated with a specific position in an argument list. You can enter optional inputs in any order as parameter name-value pairs, where the name of a given parameter appears in single quotation marks and precedes its corresponding value.

Association of dynamic (time-variable) behavior with function evaluation, where

*time*and*state (t,X*are passed to a common, published interface, is pervasive throughout the SDE class system. You can use this function evaluation approach to model or construct powerful analytics. For a simple example, see Example: Univariate GBM Models._{t})

The SDE engine allows the simulation of generalized multivariate stochastic processes, and provides a flexible and powerful simulation architecture. The framework also provides you with utilities and model classes that offer various parametric specifications and interfaces. The architecture is fully multidimensional in both the state vector and the Brownian motion, and offers both linear and mean-reverting drift-rate specifications.

You can specify most parameters as MATLAB arrays or as functions accessible by a common interface, that supports general dynamic/nonlinear relationships common in SDE simulation. Specifically, you can simulate correlated paths of any number of state variables driven by a vector-valued Brownian motion of arbitrary dimensionality. This simulation approximates the underlying multivariate continuous-time process using a vector-valued stochastic difference equation.

Consider the following general stochastic differential equation:

$$d{X}_{t}=F(t,{X}_{t})dt+G(t,{X}_{t})d{W}_{t}$$ | (17-1) |

where:

*X*is an*NVARS*-by-`1`

state vector of process variables (for example, short rates or equity prices) to simulate.*W*is an*NBROWNS*-by-`1`

Brownian motion vector.*F*is an*NVARS*-by-`1`

vector-valued drift-rate function.*G*is an*NVARS*-by-*NBROWNS*matrix-valued diffusion-rate function.

The drift and diffusion rates, *F* and *G*,
respectively, are general functions of a real-valued scalar sample
time *t* and state vector *X _{t}*.
Also, static (non-time-variable) coefficients are simply a special
case of the more general dynamic (time-variable) situation, just as
a function can be a trivial constant; for example,

**Specifying User-Defined Functions as Model Parameters. **Several examples in this documentation emphasize the evaluation
of object parameters as functions accessible by a common interface.
In fact, you can evaluate object parameters by passing to them time
and state, regardless of whether the underlying user-specified parameter
is a function. However, it is helpful to compare the behavior of object
parameters that are specified as functions to that of user-specified
noise and end-of-period processing functions.

Model parameters that are specified as functions are evaluated
in the same way as user-specified random number (noise) generation
functions. (For more information, see Evaluating Different Types of Functions.) Model parameters
that are specified as functions are inputs to remove object constructors.
User-specified noise and processing functions are *optional* inputs
to simulation methods.

Because class constructors offer unique interfaces, and simulation methods of any given model have different implementation details, models often call parameter functions for validation purposes a different number of times, or in a different order, during object creation, simulation, and interpolation.

Therefore, although parameter functions, user-specified noise
generation functions, and end-of-period processing functions all share
the same interface and are validated at the same initial time and
state (`obj.StartTime `

and `obj.StartState`

),
parameter functions are not guaranteed to be invoked only once before
simulation as noise generation and end-of-period processing functions
are. In fact, parameter functions might not even be invoked the same
number of times during a given Monte Carlo simulation process.

In most applications in which you specify parameters as functions, they are simple, deterministic functions of time and/or state. There is no need to count periods, count trials, or otherwise accumulate information or synchronize time.

However, if parameter functions require more sophisticated bookkeeping,
the correct way to determine when a simulation has begun (or equivalently,
to determine when model validation is complete) is to determine when
the input time and/or state differs from the initial time and state
(`obj.StartTime `

and `obj.StartState`

,
respectively). Because the input time is a known scalar, detecting
a change from the initial time is likely the best choice in most situations.
This is a general mechanism that you can apply to any type of user-defined
function.

**Evaluating Different Types of Functions. **It is useful to compare the evaluation rules of user-specified
noise generation functions to those of end-of-period processing functions.
These functions have the following in common:

They both share the same general interface, returning a column vector of appropriate length when evaluated at the current time and state:

$${X}_{t}=f(t,{X}_{t})$$

$${z}_{t}=Z(t,{X}_{t})$$

Before simulation, the simulation method itself calls each function once to validate the size of the output at the initial time and state,

`obj.StartTime`

, and`obj.StartState`

, respectively.During simulation, the simulation method calls each function the same number of times:

`NPERIODS`

*`NSTEPS`

.

However, there is an important distinction regarding
the timing between these two types of functions. It is most clearly
drawn directly from the generic `SDE`

model:

$$d{X}_{t}=F(t,{X}_{t})dt+G(t,{X}_{t})d{W}_{t}$$

$${X}_{t+\Delta t}={X}_{t}+F(t,{X}_{t})\Delta t+G(t,{X}_{t})\sqrt{\Delta t}Z(t,{X}_{t})$$

where Δ*t* > 0 is a small (and not necessarily equal) period or time
increment into the future. This equation is often referred to as a
*Euler approximation*. All functions on the rightmost
side are evaluated at the current time and state (*t*,
*X _{t}*).

In other words, over the next small time increment, the simulation evolves the state vector based only on information available at the current time and state. In this sense, you can think of the noise function as a beginning-of-period function, or as a function evaluated from the left. This is also true for any user-supplied drift or diffusion function.

In contrast, user-specified end-of-period processing functions are applied only at the end of each simulation period or time increment. For more information about processing functions, see Pricing Equity Options.

Therefore, all simulation methods evaluate noise generation functions as:

$${z}_{t}=Z(t,{X}_{t})$$

Yet simulation methods evaluate end-of-period processing functions as:

$${X}_{t}=f(t,{X}_{t})$$

where *t*_{0} and *T* are
the initial time (taken from the object) and the terminal time (derived
from inputs to the simulation method), respectively. These evaluations
occur on all sample paths. Therefore, during simulation, noise functions
are never evaluated at the final (terminal) time, and end-of-period
processing functions are never evaluated at the initial (starting)
time.

For example, an SDE with a linear drift rate has the form:

$$F(t,{X}_{t})=A(t)+B(t){X}_{t}$$ | (17-2) |

where *A* is an *NVARS*-by-`1`

vector-valued
function and *B* is an *NVARS*-by-*NVARS* matrix-valued
function.

As an alternative, consider a drift-rate specification expressed in mean-reverting form:

$$F(t,{X}_{t})=S(t)[L(t)-{X}_{t}]$$ | (17-3) |

where *S* is an *NVARS*-by-*NVARS* matrix-valued
function of mean reversion speeds (that is, rates of mean reversion),
and *L* is an *NVARS*-by-`1`

vector-valued
function of mean reversion levels (that is, long run average level).

Similarly, consider the following diffusion-rate specification:

$$G(t,{X}_{t})=D(t,{X}_{t}^{\alpha (t)})V(t)$$ | (17-4) |

where *D* is an *NVARS*-by-*NVARS* diagonal
matrix-valued function. Each diagonal element of *D* is
the corresponding element of the state vector raised to the corresponding
element of an exponent *Alpha*, which is also an *NVARS*-by-`1`

vector-valued
function. *V* is an *NVARS*-by-*NBROWNS* matrix-valued
function of instantaneous volatility rates. Each row of *V* corresponds
to a particular state variable, and each column corresponds to a particular
Brownian source of uncertainty. *V* associates the
exposure of state variables with sources of risk.

The parametric specifications for the drift and diffusion-rate functions associate parametric restrictions with familiar models derived from the general SDE class, and provide coverage for many models.

The class system and hierarchy of the SDE engine use industry-standard terminology to provide simplified interfaces for many models by placing user-transparent restrictions on drift and diffusion specifications. This design allows you to mix and match existing models, and customize drift-rate or diffusion-rate functions.

For example, the following models are special cases of the general SDE model.

**SDE Models**

Model Name | Specification |
---|---|

Brownian Motion (BM) | $$d{X}_{t}=A(t)dt+V(t)d{W}_{t}$$ |

Geometric Brownian Motion (GBM) | $$d{X}_{t}=B(t){X}_{t}dt+V(t){X}_{t}d{W}_{t}$$ |

Constant Elasticity of Variance (CEV) | $$d{X}_{t}=B(t){X}_{t}dt+V(t){X}_{t}^{\alpha (t)}d{W}_{t}$$ |

Cox-Ingersoll-Ross (CIR) | $$d{X}_{t}=S(t)(L(t)-{X}_{t})dt+V(t){X}_{t}^{\frac{1}{2}}d{W}_{t}$$ |

Hull-White/Vasicek (HWV) | $$d{X}_{t}=S(t)(L(t)-{X}_{t})dt+V(t)d{W}_{t}$$ |

Heston | $$d{X}_{1t}=B(t){X}_{1t}dt+\sqrt{{X}_{2t}}{X}_{1t}d{W}_{1t}$$ $$d{X}_{2t}=S(t)[L(t)-{X}_{2t}]dt+V(t)\sqrt{{X}_{2t}}d{W}_{2t}$$ |

The `sde`

class provides
default simulation and interpolation methods for all derived classes:

`simulate`

: High-level wrapper around the user-specified simulation method stored in the`Simulation`

property`simByEuler`

: Default Euler approximation simulation method`interpolate`

: Stochastic interpolation method (that is, Brownian bridge)

The `gbm`

and `hwv`

classes feature an additional
method, `simBySolution`

for
a `gbm`

object and `simBySolution`

for an `hwv`

object,
that simulates approximate solutions of diagonal-drift processes.

`bm`

| `cev`

| `cir`

| `diffusion`

| `drift`

| `gbm`

| `heston`

| `hwv`

| `interpolate`

| `sde`

| `sdeddo`

| `sdeld`

| `sdemrd`

| `simByEuler`

| `simBySolution`

| `simBySolution`

| `simulate`

| `ts2func`

Was this topic helpful?