• C++ Programming for Financial Engineering
    Highly recommended by thousands of MFE students. Covers essential C++ topics with applications to financial engineering. Learn more Join!
    Python for Finance with Intro to Data Science
    Gain practical understanding of Python to read, understand, and write professional Python code for your first day on the job. Learn more Join!
    An Intuition-Based Options Primer for FE
    Ideal for entry level positions interviews and graduate studies, specializing in options trading arbitrage and options valuation models. Learn more Join!

Blueprints/ UML diagrams for a Monte Carlo engine?

tobias elbert

Joined
10/16/08
Messages
97
Points
18
Hi guys,

was wondering whether anyone can recommend or has come across a good blueprint for a Monte Carlo engine?

I have looked around and had a look at Joshi's in C++ Design Patterns and Derivatives Pricing. Whilst it's great for educational purposes, it seems quite tedious. For instances, for multiple stochastic processes [for assets] you'd have to implement multiple derived classes of the base engine.

IMHO, the engine itself (or any derived classes) shouldn't have to care about the actual process that is to be modelled. At most, it should care whether it's a single-factor or a multi-factor one, I reckon.

Any hints would be appreciated. Thanks.
 
Hi,
Joerg Kienitz and myself have recently published a book on Monte Carlo Frameworks in C++ (Wiley) where we address this issue in your post , among others; UML design of 1 and n factor MC applications using OO and template programming using Design Patterns and architectural patterns. Chapter 11 (sample) is also relevanat.

Chapter 0 (sample) below is a taste for the book, and look at fiigure 0.1 which is an extendible UML/pattern framework.

http://www.datasimfinancial.com/forum/viewtopic.php?t=206

hth
 
Thanks, Daniel. Chapter 0 already answers quite a few of my questions. In fact, I quite like your approach. I'll get your book from the library tomorrow.
 
You're welcome, Tobias.

Can you say what kind of MC application you work on? For larger frameworks, figure 0.1 may need to be extended. The chapters in Part II might be useful.

regards

Daniel

//
An interesting discussion having practical consequences is whether to model functionality as a class or an instance (object). The danger is modelling objects as classes (which we have all been guilty of at one time or another). For example, I would now create *one* class for a 2-factor SDE and then instantiate it for Heston, CIR and other example. I did make a class for Heston but when then the code will be copy-and-replace when I want another 2 factor model. So, I get code duplication..
 
Not working on anything major. Thus far it's just for a uni assignment and I am probably overdoing it. Something similar to Joshi's treatment of the subject would probably already suffice. However, as I am already at it, I'd like to build an MC engine that's more easily scalable and makes me learn something new along the way. For instances, I wasn't familiar with the visitor pattern before and find its use quite an elegant solution.

I think it's important to treat the engine, stochastic processes and instruments as separate entities. For instances, the engine shouldn't care (in the sense that the processes are not being hard-coded into the engine or the instruments) whether an instrument is valued against an OU process or a GBM. Nor should the instrument itself.

I haven't found a reference yet that treats this subject apart from your new book. I think also in your older books the processes are either integrated into the engine (or some derived class) or the assets (the former is how Joshi does it). Obviously, I understand that the educational objectives of these books are entirely different ones.
 
tobias elbert said:
I think it's important to treat the engine, stochastic processes and instruments as separate entities. For instances, the engine shouldn't care (in the sense that the processes are not being hard-coded into the engine or the instruments) whether an instrument is valued against an OU process or a GBM. Nor should the instrument itself.

I haven't found a reference yet that treats this subject apart from your new book. I think also in your older books the processes are either integrated into the engine(or some derived class) or the assets .
Click to expand...

In general I recommend single/orthogonal responsibility for each class. With classic OO inheritance we tend to get monoliths having multiple roles. Early models of mine had classes with multiple roles indeed.

The Visitor is really very very useful because it recognises that classes are context-sensitive and using them allows us to define extra behaviour for (data) classes. And maintainability is much easier.
 
Back
Top