*From the first chapter of Modelling Financial Derivatives with Mathematica, by William Shaw*

## Chapter 1.

Advanced Tools for Rocket Science

*Mathematica* and Mathematical Finance

*Mathematica*and Mathematical Finance

### 1.1 Why You Should Use *Mathematica* for Derivatives
Modelling

When expressed in mathematical terms, the modelling of a derivative
security amounts to understanding the behaviour of a function of several
variables in considerable detail. We need to know not just how to work out
the function (the value of an option), but also how to secure an
appreciation of the sensitivity of the value to changes in any of the
parameters of the function. Such an appreciation is most reliable when we
have both a view of the local sensitivities, expressed through partial
derivatives, and a global view, expressed by graphical means. The partial
derivatives, expressed in financial terms, are the "Greeks" of
the option value, and may be passive sensitivity variables, or may be
active hedging parameters. Such option valuations may, in simpler cases, be
based on analytical closed forms involving special functions, or, failing
that, may require intensive numerical computation requiring some extensive
programming.

If one was asked afresh what sort of a system would
combine together the ability to:

i) deal with a myriad of special
functions, and do symbolic calculus with them;

ii) manage advanced
numerical computation;

iii) allow complex structures to be
programmed;

iv) visualize functions in two, three or more
dimensions;

and to do so on a range of computer platforms, one would
come up with a very short list of modelling systems. Neither spreadsheets
nor C/C++ would feature on the list, due to their fundamental failure to
cope with point (i)--symbolic algebra and calculus.

One of the very
few complete solutions to this list of requirements is the
*Mathematica* system. Originally subtitled "A System for Doing
Mathematics by Computer", it is uniquely able as a derivatives
modelling tool. In particular, version 3.0 and later includes substantial
new numerical functionality, and it is capable of efficient compiled
numerical modelling on large structures. *Mathematica* can manage not
just scalar, vector and matrix data, but also tensors of arbitrary rank;
and its performance scales well to large and realistic problems. This book
is, in part, an exploration of these capabilities. It is also an
exploration of valuation algorithms and what can go wrong with
them.

### Exploring the Fundamentals with *Mathematica*

This book is not just an exploration of a few well-known models. We shall
also explore the matter of solving the Black-Scholes differential equation
in a *Mathematica*-assisted fashion. We can explore:

i)
Separation of Variables;

ii) Similarity Methods;

iii) Green's
Functions and Images;

iv) Finite-Difference Numerics;

v) Tree
Numerics;

vi) Monte Carlo Simulation

as solution techniques, all
within the *Mathematica* environment. A comparison of these approaches
and their outcomes is more than just an interesting academic exercise, as
we shall consider next.

### 1.2 The Concept of Model Risk and the Need for Verification

### Informal Definitions of Model and Algorithm Risk

Model Risk can arise in a variety of ways. Given a financial instrument,
we generally formulate a three-stage valuation process:

a)
Conceptual description;

b) Mathematical formulation of the conceptual
description;

c) Solution of the mathematical model through an analytical
and/or numerical process.

It is possible to make mistakes, or
perhaps unreasonable simplifying assumptions, at any one of these three
stages. Each of these gives rise to a form of model risk--the risk that the
process from reading a contract to responding with a set of answers (fair
value, delta, gamma, ..., implied volatility) has led to the wrong answer
being supplied.

This book uses *Mathematica* to look
intelligently at the third point, which we might call *algorithm
risk*. One might think that this can be eliminated just by being
careful--the real story is that derivative securities are capable of
exhibiting some diverse forms of mathematical pathology that confound our
intuition and play havoc with standard or even state-of-the-art algorithms.
This book will present some familiar and rather less familiar examples of
trouble.

I wish to emphasize that this is not just a matter of
worrying about a level of accuracy that is below the "noise
level" of traders. It is possible to get horribly wrong answers even
when one thinks that one is being rather careful. I also tend to think that
it is the job of a Quants Team to supply as accurate an answer as possible
to trading and sales teams. If they want to subtract or add 50 basis points
to your answer, for whatever reasons, that is their responsibility!

### Verification and Resolving Disagreement Amongst Experts

A good rule of thumb is that in general you can give what you think is
the same problem to six different groups and obtain at least three
materially different answers. In derivatives modelling you can usually get
four different answers, especially if you include:

a) One Analytics
fanatic;

b) One Tree-Model fanatic;

c) One Monte-Carlo fanatic;

d)
One Finite-Difference fanatic

among the group of people you choose.
I use the term "fanatic" quite deliberately. I once had a party
where I was told categorically that "you absolutely had to use
Martingales--these PDE people have got it all wrong", and I know of at
least one PDE book that makes almost no reference to simulation, and one
excellent simulation book that went so far as to describe the PDE approach
as "notorious". In fact, all these methods should give the same
answer when applied carefully to a problem to which they can all be
applied. You can get small but irritating non-material differences out of
models because of differences of view over things like calendar management,
units, continuously compounded versus annual stuff, and so on. That sort of
thing can and should generally be resolved by getting the Risk Management
team to bash heads together. The issues arising from genuine differences
between models of a different type, and more worringly still, between
models of a similar type, require a much more disciplined approach.

The only way to sort out material differences in answers is to
perform some form of *verification study*. This can be done in various
ways, of which the two most important ones are:

a) Comparison of
modelling systems with some form of absolutely accurate benchmark
(typically only available for simpler models, but we must check that
complex algorithms do work correctly when specialized to simple
cases);

b) Intercomparison of models and codes when applied to
complex instruments.

The basic idea is to define a comprehensive set
of test problems, and run off a benchmark model and operational systems
against as many others as are available.

In other fields of study
this is actually a common process. I hope this text encourages similar
efforts within the derivatives modelling community.

### Resource Management

The essential requirements of such an approach include *duplication of
effort*. My view is that no number should be believed unless it can be
justified as the result of at least two different modelling efforts (or at
least that the same system has been through such an intercomparison or
benchmarking study in the past, and that it has been documented). This is
generally not what management involved in resource allocation want to hear!
The point is that quality is only achieved through careful and critical
testing and appraisal.

### 1.3 The Power of Symbolic Computer Calculus

In recent years a number of tools have emerged that extend the utility of
computers from "number crunching" to the domain of carrying out
algebra and calculus. More mature systems combine such symbolic capability
with advanced numerical algorithms, 2D, 3D, and animated graphics, and a
programming environment. Such tools are particularly relevant to the
derivatives modelling and testing area due to

a) the fact that they
have built-in routines for most basic common operations;

b) the ability
to do calculus with simple and complex functions can eliminate many of the
headaches of computing Greeks;

c) the ability to compare analytical
symbolic models directly with the results from a numerical algorithm;

d)
the ability to visualize the results, and literally see the errors if there
are any.

### Time to Wean Your Team from Spreadsheets and C/C++?

It is my firm belief that in the long term such hybrid
symbolic-numeric-graphical systems will replace the spreadsheet and
languages such as C or C++ for derivatives modelling. Their primary
advantage lies in the provision of advanced symbolic capabilities. In a
numerically based system the only two ways to differentiate to get a Greek
such as delta, are a) to work out the derivative on paper and code it up,
b) work out the value of an option for one or two neighbouring values of
the parameter, and take differences. Both of these have drawbacks, and the
potential for human error at the pen-and-paper stage, and numerical errors
arising from numerical differentiation problems. Instead we can now ask the
computer to do the differentiation for us. Such symbolic environments, rich
as they are in special-function libraries, can dramatically reduce
development time below that for spreadsheet or C/C++ systems. Furthermore,
in the testing and verification context, they offer a simple integrated
environment where a numerical model can be compared directly with its exact
form. And I mean exact--current systems can do arbitrary-precision
arithmetic with ease, and can do so with complicated "special
functions". The latest versions of these systems, as is the case with
*Mathematica* 3.0 or later, can also produce mathematical typeset
material, so you can write your code, write a mathematical model, test
them, plot the results, and produce a report for risk
management/trading/regulatory bodies--all within one environment.

### Spreadsheet Woes

There are many problems with spreadsheet environments. An extensive
discussion of the issues is given by R. Miller (1990) in Chapter 1 of his
text, *Computer-Aided Financial Analysis*, where he outlines several
principles to which financial modelling environments should conform, and
explains why spreadsheets fail to meet them. My own simplistic
interpretation of Miller's views (i.e., my own prejudice) is that
spreadsheets are the best way yet invented of muddling up input data,
models, and output data. More seriously, their fabled capability for doing
"what if" calculations is at once both erroneous and misleading.
In the particular context of derivatives modelling, the modelling of Greeks
within spreadsheets by revaluing for neighbouring values of the parameters
is an abomination. The point is that you should use exact calculus wherever
possible to extract partial derivatives. As Miller points out, the
"what-if" concept is also limited to numerical variations. We
want a system where we can also vary structural properties ("what if
American rather than European"). This leads rather naturally to the
desire for an object-oriented approach.

There is one virtue of the
spreadsheet environment, and that is the tabular user interface. There is
no doubt that for instruments requiring a small number of input and output
parameters, such a table of data for several such instruments is extremely
useful. However, even the interface virtues of spreadsheets are strained by
the complexities of instruments such as convertible bonds. The information
relevant to one such bond can easily require several interlinked
sheets.

### Flushing POO Away?

Not for nothing, in my view, is the Spanish acronym for object-oriented
programming POO, rather than OOP. C++ has become entrenched as a modelling
system in many finance houses. In the view of the author, the job of a
"Quant" is to analyse, test, and price financial instruments as
quickly and reliably as possible to respond to trading needs. There can be
no greater waste of a Quant's time than having to write and debug
algorithms in C++, let alone, God forbid, waste further energy embedding
them in a spreadsheet. If one needs to do a highly numerically intensive
model for which a system such as *Mathematica* may, at least for the
present, be inadequate, the solution, at least for now, is to use a system
designed for the task, such as highly optimized FORTRAN 90. Objections to
*Mathematica* based on speed of execution are now essentially
irrelevant due to improvements in low-price high-speed CPUs, and the
increased efficiency of the internal compiled numerical environment in
*Mathematica*. C++ systems are much slower to write, slow to compile,
and their execution time advantage is now marginal. The great dream of
system managers is that once the headaches of building a library of core
C++ library routines is complete, modellers can build new algorithms
quickly. Sadly, this is only a dream. OOP projects mysteriously seem to
require massive increases in headcounts and budgets, yet are nevertheless
the beloved of system managers.

This is NOT to say that an
object-oriented approach is a bad idea--the problem is getting the dream
back on track. My view is that the base-line system for object-oriented
derivatives development should be at the level of a system such as
*Mathematica*, where there is a symbolic capability, and already a
huge collection of basic objects already in place with their mathematics
sorted out. A good question to ask an OOP-based derivative team is how much
time they have wasted coding up interpolation, Normal distributions,
Greeks, and all kinds of special functions and capabilities that already
exist in *Mathematica*. In this text I have not attempted a complete
object-oriented approach. My focus has been on making sure that the answers
are correct. I leave it to others to adopt some of these methods and
algorithms into a more structured environment.

### The Use of *Mathematica*

The power of *Mathematica* as an investigate tool becomes clear in
this context. We can define a series of test problems and use the special
function capabilities of *Mathematica* to characterize the solution
exactly, using *Mathematica*'s infinite-precision arithmetic to get
the results with as much accuracy as we desire. Next we use
*Mathematica*'s symbolic calculus capabilities to define the Greeks by
differentiation. Then, for more complex models, we build tree, Monte-Carlo
and Finite-Difference models within *Mathematica*. Then we make a
comparison, within *Mathematica*, between these analytical forms and
the numerical solutions, and the solutions from other company systems. The
results are compared, and the reasons for any differences or other problems
are explored and resolved.

### A Challenge!

To those who find my comments on traditional modelling systems extreme or
ill-informed, I issue this challenge. There is now available an exact
solution for the continuously averaged arithmetic Asian option. This is the
Geman-Yor model described in Chapter 10. I got this up and running in
*Mathematica*, and tested it, in a total of six hours. To anyone who
can implement this in C++, and get answers accurate to 4dp, I offer a
bottle of quality vintage champagne. If they can do it in less than 40
hours of coding time, two bottles. To anyone who can get it working as
accurately in a spreadsheet alone, I offer a case of good red wine, however
long it takes.

### 1.4 A Case Study in Chaos--Does Implied Volatility Make Any Sense?

As an illustration of something that is easy to explore in a system such
as *Mathematica*, we give an example of how one can investigate a
topic within a system combining symbolic models and graphics. The topic
chosen is "Implied Volatility", and the point is to make it clear
just how infrequently this concept makes any sense. This is important from
both a mathematical point of view, as we need to note when a function
cannot be inverted as it is "many to one", and from a trading
point of view--implied volatility is often used as a key
parameter.

Traders are persistent in asking for implied
volatilities. You can give them a number, but it might not make any sense
at all. Or rather, you can feed a market price for an instrument to a
system which does all sorts of fancy things to find the volatility
consistent with the market price given all the other data, and this
volatility can make no sense at all. It is a good idea to list the nice
situation and all the horrors that can arise. I emphasize that these are
not issues linked to a particular solution method, such as Newton-Raphson
or bisection, where particular problems linked to the solution method may
arise. These are matters of principle that will cause trouble whatever
solution technique is employed.

### Things Are OK

When the valuation is a monotonic function of volatility (strictly
increasing or decreasing), there is usually no problem. The simple case of
a vanilla European call option, as developed by Black and Scholes (1973)
falls into this category. Let's build a symbolic model of this option and
plot the value as a function of volatility--we take this opportunity to
show how easy it is to write down a model in a symbolic system such as
*Mathematica.*

We plot the option value as a function of the volatility, for an option where the strike is at 10, the underlying at 11, for a vanilla Euro-call with one year to expiry, 5% risk-free rate (continuously compounded) and zero dividends.

We can also build an implied volatility calculator in a moment
(**FindRoot **is a combination Newton-Raphson/Secant solver).

BlackScholesCallImpVol[s_,k_,r_,q_,t_,price_] :3Dsd /. FindRoot[BlackScholesCall[s,k, sd, r, q, t]3D3Dprice,{sd,0.2}];

Because the function is strictly increasing, we get a one-one mapping between prices and volatilities.

The results are stable--a small change in the market price causes a small shift in the implied volatilities.

### Things Are Sometimes OK, Sometimes Highly Unstable

It does not take much to mess up the calculation of implied volatility. Let's add a dilution effect to the Black-Scholes model, providing a simple model for a warrant. This is one of the simpler warrant-pricing models discussed by Lauterbach and Schultz (1990).

When we plot the result for price against volatility, we see that there is a nice monotonic region for larger volatilities, but that the curve becomes very flat as the volatility dips below 20%. The corresponding inversion for the implied volatility then becomes either unstable or impossible.

### Things Are Definitely not OK--There Are Two or Even Three Implied Volatilities

You do not have to make the option that much more complicated to really
get in a mess. A simple barrier option will exhibit the phenomenon of there
being two volatilities consistent with a given valuation. Suppose we
consider an up and out call where the underlying is at 45, the strike at
50, and the knockout barrier at 60. As we first increase the volatility
from a very low value, the option value increases. Then, as the volatility
increases further, the probability of knockout increases, lowering the
value of the option. By tweaking in a rebate we can arrange for there to be
three solutions for a small range of market option prices. The model of
barriers we use is the analytical model developed by Rubenstein and Reiner,
1991--this has again been built in *Mathematica*, but we suppress the
details of the symbolic model here--it is given in Chapter 8. The two
graphs following show cases where there are two and three implied
volatilities, respectively.

In other words, vega is positive apart from an interval in which it is negative.

In Chapter 8 you will see how vega is defined by elementary
differentiation using *Mathematica*'s "D" operator.

### Things Are Impossible--There Are Infinitely Many Answers

If you want to see just how bad it can get, a barrier option can do still
more interesting things. If we consider an Up and Out Put, where the strike
coincides with the barrier, and arrange for the risk-free rate and the
dividend yield to coincide, we can get a dead zero vega (and zero gamma
too). So if the market price happens to coincide with the computed value,
*you can have any implied volatility you want*. Otherwise there is no
implied volatility.

Plot3D[UpAndOutPut[0, S, 50, 50, vol,0.1, 0.1, 1],

{S, 30, 50},
{vol, 0.05, 0.4 }, PlotRange -> {-0.01, 0.01}, PlotPoints ->
40];

You should be grateful that this is all that goes wrong. Fortunately derivatives modellers tend to use real numbers. In complex function theory, Newton-Raphson and other iterative solution techniques are famous for their generation of fractals and chaotic behaviour. But it is a good idea to avoid quoting implied volatilities unless you have a firm grasp on the characteristics of an instrument. Only the very simplest options behave well, in this respect. More generally, you should not report implied volatility results unless you have first checked that the absolute value of vega is bounded away from zero. Otherwise the implied volatility is at best unstable and possibly undefined--in such cases it should not be reported.

### Remarks

This little study has illustrated several points about the use of
*Mathematica*:

a) You can build symbolic models very
quickly;

b) Greeks can be investigated by symbolic
differentiation;

c) We can visualize our models using two- and
three-dimensional graphics;

d) We can expose peculiar situations with
relative ease.

Later in this book we shall see how the exposure of
significant problems can be extended to intensively numerical processes.

For now we return to the fundamentals. In the next three chapters
we lay the foundations of

a) Using *Mathematica*;

b)
Financial mathematics of derivatives pricing;

c) The mathematics for
solving partial differential equations (the Black-Scholes PDE).

### A Final Note

We live in a world where applied quantitative science in general, and
financial modelling in particular, is increasingly dominated by purely
numerical modelling. The view of the author is that the analytical
approach is being inappropriately eclipsed by a rather mindless approach
involving flinging models at a computer and seeing what numbers come out.

This is not the best way to use computers. We are seeking insight
into the behaviour of complex systems, and this is best obtained by first
attempting an analytical treatment. This first focuses our instincts, and
gives us test cases to check against when we finally come to adopt a purely
numerical approach. Symbolic algebra systems such as *Mathematica*
allow us to extend the analytical approach to much more complicated
systems. The numerical approach should always be the method of absolute
last resort, and should then be checked extensively against the analytical
results. This is the guiding principle beyond the approach taken by this
text.

### Chapter 1 Bibliography

Black, F. and Scholes, M., *Journal of Political Economy*, Vol.
81, p. 637, 1973. (Reprinted and widely accessible as Chapter 1 of
"*Vasicek and Beyond*", ed. Hughston, Risk Publications,
1996).

Lauterbach, B. and Schultz, P., *Journal of Finance*,
XLV, 4, p. 1181, September 1990.

Miller, R.M. ,* Computer-Aided
Financial Analysis*, Addison-Wesley, 1990.

Rubenstein, M. and
Reiner, E. Breaking Down the Barriers, RISK Magazine, September 1991.