Introduction to C++ for Financial Engineers

An Object-Oriented Approach

Daniel J. Duffy

• Publisher: Wiley
• Year: 2013
• Print ISBN: 9780470015384
• eBook ISBN: 9781118856468
• Edition: 1
• Topic: Business
• Subtopic: Finance
• Index: Business

This book introduces the reader to the C++ programming language and how to use it to write applications in quantitative finance (QF) and related areas. No previous knowledge of C or C++ is required -- experience with VBA, Matlab or other programming language is sufficient. The book adopts an incremental approach; starting from basic principles then moving on to advanced complex techniques and then to real-life applications in financial engineering. There are five major parts in the book:

• C++ fundamentals and object-oriented thinking in QF
• Advanced object-oriented features such as inheritance and polymorphism
• Template programming and the Standard Template Library (STL)
• An introduction to GOF design patterns and their applications in QF Applications

The kinds of applications include binomial and trinomial methods, Monte Carlo simulation, advanced trees, partial differential equations and finite difference methods.

This book includes a companion website with all source code and many useful C++ classes that you can use in your own applications. Examples, test cases and applications are directly relevant to QF.

This book is the perfect companion to Daniel J. Duffy's book Financial Instrument Pricing using C++ (Wiley 2004, 0470855096 / 9780470021620)

Part I

C++ Essential Skills

Chapter 1

Introduction to C++ and Quantitative Finance

1.1 INTRODUCTION AND OBJECTIVES

In this chapter we give an overview of the C++ programming language, its relationship with Quantitative Finance (QF) and why C++ is suitable for complex applications in this domain. In particular, we discuss the various programming paradigms and how each paradigm is suited to software projects in QF. Furthermore, we shall describe how these paradigms can be dovetailed to help us build efficient and robust code. Last, but not least, our objective is to create software that is also easy to understand and to maintain. This is an extremely important requirement because a large C++ application consisting of a network of tightly coupled objects can be difficult to maintain at best, and a nightmare at worst. In this day and age the focus is on developing flexible frameworks that can be easily and quickly customised to changing requirements in the market place. To this end, we are convinced that C++ can realise these requirements if and only if we design our software systems in a correct and proper way.

You can skip this chapter if you wish to start as soon as possible on this C++ journey. Then you should go immediately to chapter two. Before doing so, however, we would strongly advise you to read section 1.3 (Programming Paradigms). This book complements my book on C++ for financial instrument pricing (Duffy, 2004) because the latter book assumes previous C++ knowledge and the current book takes a more leisurely pace by discussing each topic in detail.

If we compare this book to an opera, then this chapter would correspond to the overture. It sets the tone by providing some background information on C++ and its relevance and applicability to Quantitative Finance.

1.2 A SHORT HISTORY OF C++

The object-oriented way of thinking and programming (we call this a paradigm) is almost fifty years old and it has its origins in the programming language Simula that was developed in Norway. Simula was the first language to support the concept of a class as we know it in its current form.

C++ has its origins in the early 1980’s when its inventor, Dr Bjarne Stroustrup (Stroustrup, 1997) was working at AT&T. The original name for the language was ‘C with classes’ because the language was developed as an object-oriented extension to the programming language C while still remaining compatible with it. This very fact may be a reason why C++ has weathered the storm: the legacy C code that organisations maintained could be upgraded to C++. C++ is compatible with C and was called a ‘better C’ in those early days.

The late 1980’s can be seen as the period when C++ came out of the laboratories and began to manifest itself in mainstream applications. The first C++ compiler (actually, precompiler because C++ code was compiled to C code) was from a company called Glockenspiel in Dublin in 1988 and it was in this period that the current author started to work with C++.

The early 1990’s saw a remarkable growth in interest in the object-oriented (OO) paradigm in general and in C++ in particular. As with many new technologies promises were made that were not met. For example, it was believed in some circles that OO would solve all software ails and that a new industry would emerge in which application builders would purchase reusable class libraries from companies that could be described as ‘class library builders’. The most important applications in this period were in the following domains: simulation (Computer Aided Design (CAD), Computer Graphics), telecommunications and real-time applications (for example, medical devices and process control). It was during this period that the current author worked on an early version of a pricing and risk management system in C++.

At the moment of writing we can conclude that the object-oriented paradigm is (justifiably) accepted as a necessary precondition for success in software development. However, it is not sufficient in the sense that blind adherence to it will not automatically lead to good results. First, there are other software paradigms that complement and even compete with the object-oriented paradigm and second the paradigm can be taken to extremes, as we have seen in the past. We discuss these problems and risks in this chapter and we provide some guidelines on how to turn our object-oriented projects into success stories.

1.3 C++, A MULTI-PARADIGM LANGUAGE

One of the features of C++ is that it supports many kinds of programming paradigms, unlike some languages that are ‘pure’ object-oriented languages (in the sense that every piece of software must be an object or a class). Instead, we can write applications that are a mixture of different programming styles. Whether this is a wise thing to do is debatable but that is not the issue at the moment. In general, the author does not believe that a single paradigm is flexible enough to encompass every possible kind of application and in general some parts of an application can be written in an object-oriented fashion while other parts can and should be written using a modular approach, reminiscent of Fortran, C and Cobol.

1.3.1 Object-oriented paradigm

This paradigm is based on the concept of a class. Classes have their origins in philosophy, logic and cognitive psychology (Eysenck and Keane, 2000). In particular, the theory of concepts has been an important influence on the development of the object paradigm. There are a number of theories, one of which is the defining attribute view. This view was developed and elaborated by the German logician Frege (Frege, 1952). Frege maintained that a concept can be characterised by a set of defining attributes or semantic features. He distinguishes between a concept’s intension and extension. The intension of a concept consists of the set of attributes that determine what it is to be a member of the concept. This idea is similar to a class in class-based object-oriented languages. The extension of a concept is the set of entities that are members of the concept. This idea corresponds to class instances or objects. Some features of the defining attribute view are:

• The meaning of a concept is captured by its defining attributes
• Attributes are atomic building blocks for concepts
• Attributes are necessary and sufficient for defining members of a concept
• There is no doubt about whether an entity is in the concept; there are clear-cut boundaries between members and non-members of the concept
• All members of the concept are equally representative of the concept; we cannot say that one member is more typical of the concept than another member
• When concepts are organised in a hierarchy the defining attributes of the more specific concept (for example, a sparrow) include all the attributes of the superordinate concept (in this case, bird).

These features are implemented in many class-based object-oriented languages such as C++, Java and C#. In this case we first define a class consisting of data and functions and we then create objects or so-called instances of the class by initialising the data in the class. Looking back in hindsight (which is always easy), the author concludes that these assumptions are too restrictive for certain types of applications. There are other object-oriented languages where there is no class concept. Instead, if we wish to create an object we must clone or copy it from an existing prototypical object. The Self language is one example of a so-called classless object-oriented language.

Let us take a simple example. In this case we wish to model one-factor plain options (in other words we can only exercise at the maturity date T). An option can be a call option or a put option. When we model this as a class we must discover its attributes and the messages to which instances (objects) of the class respond to. The attributes are:

• The risk-free interest rate: r
• The volatility of the relative price change: σ
• The strike price: K
• The time to expiration (in years): T
• The cost-of-carry: b

These attributes are just names and when we create instances of the class we must assign values to them, for example (Haug, 1998):

• Volatility σ = 0.15
• Strike Price K = 490
• Time to expiry T = 0.25 (3 months)
• Risk-free interest rate r = 0.08
• Cost-of-carry b = 0.03

We thus see that the object is concrete while its corresponding class is abstract. Having defined the object’s data we may speculate on the kinds of information we wish to extract from the object. Since this is a context-sensitive question we would expect different answers from various stakeholder groups such as:

• Traders
• Quantitative analysts
• Risk managers
• IT personnel

Each group has its own requirements and features that they would like to have. For example, a common set of requirements might be:

• Calculate the option price
• Calculate an option’s sensitivities (for hedging applications)
• The ability to support constant, time-dependent and stochastic volatility models
• Export option-related information to a spreadsheet, for example Excel

These features will be implemented by one or more so-called member functions. In order to reduce the scope we concentrate on the pricing and hedging functionality. For example, the price for a one-factor plain call or put option is known analytically:

 double CallPrice() { double tmp = sig * sqrt(T); double d1 = (log(U/K) + (b+ (sig*sig)*0.5) * T)/ tmp; double d2 = d1 - tmp; return (U * exp((b-r)*T) * N(d1)) - (K * exp(−r * T)* N(d2)); } and double PutPrice() { double tmp = sig * sqrt(T); double d1 = (log(U/K) + (b+ (sig*sig)*0.5) * T )/ tmp; double d2 = d1 - tmp; return (K * exp(−r * T)* N(−d2)) - (U * exp((b-r)*T) * N(−d1)); } 

In this code we use the variable U to denote the underlying variable.

1.3.2 Generic programming

This is a paradigm that can be a competitor of the object-oriented paradigm and it can also be used in conjunction with the latter paradigm.

When we design a software entity using the generic paradigm we try to stop thinking about hard-wired d...

Table of contents

• Cover
• Half Title page
• Title page
• Copyright page
• Chapter 0: Goals of this Book and Global Overview
• Part I: C++ Essential Skills
• Part II: Data Structures, Templates and Patterns
• Part III: QF Applications
• Part IV: Background Information