Coding skills?

[bigbadwolf]

Things pertaining to computing keep getting discussed here but to my knowledge no-one has ever asked precisely what coding skills and computing knowledge an MFE student or quant needs. I'm not talking in terms of a specific language (such as C++ or Python). I'm talking rather of coding skill and understanding in general. What should ideally be known in terms of algorithms and data structures, financial algorithms, knowledge of different programming paradigms (OO, functional, imperative, logic), numerical analysis (and its concomitant coding), and so on? In related vein, what skill set is required of a good coder (and I'm keenly aware that there may no answer, or no consensus)?

 

[AlexandreH]

Is "All of the above" an ideal answer, but not a practical one?

 

[bigbadwolf]

It's ideal but perhaps not practical. It requires the algorithms and data structure courses CS students take, along with some exposure to scientific coding (based on a foundation of numerical analysis, for example in the book Numerical Recipes). Reason I'm bringing it up is the many times the importance of coding proficiency has been mentioned on this forum -- without anyone quite specifying what it means. It looks like there is a niche for a book like "Programming for Financial Engineers." It could introduce a language like C or Python and move rapidly to the kind of coding an FE would be interested in -- solutions of differential equations, for example. Or the algorithm for the Monte Carlo valuation of a European Call. Or the binomial valuation of an American option. The algorithms are not obvious and they can be elegant.

 

[Steven]

The book "Implementing Derivatives Models" by Clewlow and Strickland might be a good source

 

[Lyosha]

MFE requires the basics really (obviously more is recommended)... understand how to solve problems using C++ and don't be afraid to explore the nether regions of the language every so often when given the opportunity.

Professionally... what kind of quant? The needs of a quant developer are different than a risk manager and different than algo trader and different than a desk quant, etc.

 

[Tsotne]

I have Daniel Duffy book Modeling financial instruments in C++ which is really great book. Explains topics mathematically and implements in C++. Realy a good read

 

[bigbadwolf]

The book "Implementing Derivatives Models" by Clewlow and Strickland might be a good source

It's a fine book: the pseudocode for binomial models, Monte Carlo simulation and interest rate models is all given. Interesting that this book appeared thirteen years ago and (as far as I know) hasn't been bettered since. Other books that integrate theory with code (or pseudocode) are Back's A Course in Derivative Securities (code is in VBA), Lyuu's Financial Engineering and Computation (pseudocode), and Levy's Computational Finance Using C and C#.

MFE requires the basics really (obviously more is recommended)... understand how to solve problems using C++ and don't be afraid to explore the nether regions of the language every so often when given the opportunity.

Sure. But can the "basics" be clearly and explicitly specified? First of all, do the basics have to formulated in terms of C++? And secondly, regardless of whether we're talking of C++, some other language, or a formulation independent of language, what are the basics? Control structures, functions, arrays, pointers, data structures? What is expected in terms of problem solving ability? And where would that come from? There are courses teaching languages (C++, Java, etc.), but they sometimes don't teach problem-solving ability, or not adequately.

As I see it, there's not any book that can be called "Programming for Financial Engineering" in quite the same manner as there is Dan Stefanica's "A Primer for the Mathematics of Financial Engineering." Such a book would rapidly go over what should be familiar ground in programming, indicate further reading, and give coding and algorithm design problems that would be relevant to financial engineering.

 

[tobias elbert]

@BBW: Erik Schloegl's new book, once it's finally published, will be along the lines of what you are suggesting with a strong focus on theory and/ integrated with code (C++). Watch out for that one - it'll be good!

 

[bigbadwolf]

@BBW: Erik Schloegl's new book, once it's finally published, will be along the lines of what you are suggesting with a strong focus on theory and/ integrated with code (C++). Watch out for that one - it'll be good!

Any idea of title and publisher?

Postscript: Found it: "Quantitative Finance: An Object-Oriented Approach in C++", Eric Schlogl, Chapman and Hall, and due at the end of this year.

 

[KaiRu]

Few points from me:

1. Be able to overcome "leaky abstactions" http://www.joelonsoftware.com/articles/LeakyAbstractions.html
You have to understand what's going on under the cover - Java, C++ or whatever. Garbage collection or shared pointers are great, but you have to undertand what malloc() does and how it can be improved - 95% of time you don't realy need but 5% of time you have some tricky problem in your app's memory heap or networking IO or something. If you don't understand it you are screwed.

2. Know your tools. You can write incredible code but if you can't analyse the state of existing system with profilers, debugger, sys tools in untrivial situation then again you will have problems or just waist your time in the best case.

 

[Yike Lu]

It depends heavily on what you want to do. For what I'm doing, I don't write much C++, although I'm sure my employers feel more comfortable knowing that I could if I wanted to.

 

[Tsotne]

Few points from me:

1. Be able to overcome "leaky abstactions" http://www.joelonsoftware.com/articles/LeakyAbstractions.html
You have to understand what's going on under the cover - Java, C++ or whatever. Garbage collection or shared pointers are great, but you have to undertand what malloc() does and how it can be improved - 95% of time you don't realy need but 5% of time you have some tricky problem in your app's memory heap or networking IO or something. If you don't understand it you are screwed.

2. Know your tools. You can write incredible code but if you can't analyse the state of existing system with profilers, debugger, sys tools in untrivial situation then again you will have problems or just waist your time in the best case.

Many modern languages don't prevent you from knowing the garbage collection architecture and memory management. Simply the heavy weight of those tools being used every moment has been lifted from your shoulders and been placed on those of CLR. In C# for example, you can interact with garbage collection process directly but there's no need. I agree - it gives you better knowledge when you (are obliged to) manually delete the unnecessary objects from memory. But still, things can be simplified and also depends on whether your opportunity cost of development time is higher or the one of processing time. (when we talk about simplification)

 

[chjatlanta]

I have the same question in my mind too. Let's not discuss specific language. Is the programming tasks for quants closer to scientific computation or closer to the work in a software company? I did algorithm implementation and simulation for academic research which is much easier. But working for a software company requires much more deep understanding and debugging skills.

 

[The_Moroccan.]

I am not a quant yet ( Taking classes now) But I am a software engineer, and I remember one of my teacher told us, if you want to be a good progammer, program every day for 5 years or program for 1 year and understand the introduction to algorithms book. And here is the link for the course in MIT for that book, it is really worth it to understand how your program will behave, how long will it take to compute using a specific algorithm, is there an optimal solution for a given problem, is it P or NP problem ...etc:
http://academicearth.org/courses/introduction-to-algorithms

 

[alain]

read this link

http://norvig.com/21-days.html

 

[KaiRu]

There is comics at xkcd.com on the same topic as P. Norvig's article that alain has posted above.

 

[D C]

xkcd is great