Just saw the abstracts listed for the Commercial Users of Functional Programming (CUFP) workshop at ICFP this year. Interesting to see two finance related talks, one from Jane St on Ocaml and the other from CSFB on Haskell. Having used both since the mid 90s I'm happy they are seeing wider use - and commercial use at that.http://www.galois.com/cufp/

QuoteOriginally posted by: stuntprogrammer Just saw the abstracts listed for the Commercial Users of Functional Programming (CUFP) workshop at ICFP this year. Interesting to see two finance related talks, one from Jane St on Ocaml and the other from CSFB on Haskell. Having used both since the mid 90s I'm happy they are seeing wider use - and commercial use at that.http://www.galois.com/cufp/A few months ago I took some simple options pricing code in C++ and translated it to Ocaml. I was interested in measuring productivity. The C++ code is from an introductory book on pricing derivatives in C++. Here's a brief summary of the result, in terms of lines of code, datatypes, number of files: Monte Carlo (datatypes only) C++: 264 LOC, 7 classes, 20 methods, 12 files Ocaml: 33 LOC, 3 datatypes, 1 function, 2 files Ocaml/C++: 33/264 = 13% Binomial trees (datatypes only) C++: 264 + 138 = 402 LOC, 10 classes, 30 methods, 18 files Ocaml: 33 + 12 = 45 LOC, 3 datatypes, 3 functions, 2 files Ocaml/C++: 45/402 = 11% Binomial trees (datatypes + main algorithm) Ocaml/C++: 165/522 = 32%The code in Ocaml was not only shorter, but simpler and easier to follow (ie: less expensive to produce, debug, etc). And performance was pretty much the same. Of course, I'm not claiming such reductions can be expected for every C++ project. For instance, the binomial tree algorithm was pretty much the same size and complexity in C++ and Ocaml. The bulk of the savings here come in datatype definitions.Let me know if you are interested in more details.

This is a somewhat bizarre metric of productivity. I once wrote a two line/one long integer variable C program that printed out a Mandelbrot set in ASCII. I wouldn't have claimed 'productivity' as one of its chief virtues.

QuoteOriginally posted by: zarnywhoop This is a somewhat bizarre metric of productivity. I once wrote a two line/one long integer variable C program that printed out a Mandelbrot set in ASCII. I wouldn't have claimed 'productivity' as one of its chief virtues.I'm afraid I've been a bit unclear. I'm not saying that the code itself is 'productive'. I'm talking about programmer productivity (which translates into cost of developing software). Of course, I did not conduct a study where two different but equally competent programmers implemented their solutions and productivity and cost were measured. My test was much more informal than that. Notice that I'm not claiming that for every C++ project, you can achieve similar improvements if you use Ocaml. Apologies for the empty reply below.

Is there a mature toolchain for Ocaml? With nice GUI, preferably?

QuoteOriginally posted by: ZmeiGorynychIs there a mature toolchain for Ocaml? With nice GUI, preferably?The Ocaml distribution in my experience is mature and stable on the preferred platforms. Its a typical unix style toolchain with excellent debugger, native code compiler, interactive and batch bytecode interpreter, profiler, and well documented. Win32 is supported, win64 not just yet (in terms of generating 64 bit programs). Fast and expressive language.http://caml.inria.fr/ocaml/index.en.htmlI use it on Linux mainly and its a great toolchain; if one is suited to that mode of development. I don't know of any great GUI oriented tool - I don't know how good cameleon is for instance: http://pauillac.inria.fr/~guesdon/Tools ... on.htmlThe main weakness in my eyes, going forward, is lack of a concurrent garbage collector. You can use threads (mod the lack of concurrent gc) or MPI..The main downside? No different from other technologies, the main annoyance can be overly rabid users who think the language is a cure-all. Then again I can't name a language that doesn't have such users who rush in to promulgate its use without really being able to articulate its advantages in the domain under discussion.. The main things I wouldn't use it for include graphical user interface development and bog standard business reporting type apps. No doubt people do and would defend it. Its particularly well suited to problems involving tricky data structures or algorithms (be they symbolic or numerical) where time to develop and time to execute are both important.

QuoteOriginally posted by: zarnywhoopThis is a somewhat bizarre metric of productivity. I once wrote a two line/one long integer variable C program that printed out a Mandelbrot set in ASCII. I wouldn't have claimed 'productivity' as one of its chief virtues.Although it's true that anyone can crunch a bit of code down into a small number of inscrutable lines, that is not what's happening here. Some languages, such as Ocaml, enable a programmer to rapidly create code for a given class of problems that is much more compact and more readable than the code needed by some other languages. That makes the programmer more productive, the code easier to verify, and the software less likely to contain errors.Disclaimer: I'm no Ocaml fanboy. In fact, I've never used Ocaml -- I did check out a few resources on it today and can see why it might be good for FE/quant work. I have used other languages that I thought had this property for other types of problems (e.g., APL for numerical array data processing). I've also seen academic research comparing different languages that came to similar conclusions -- some languages lend themselves to especially easy-to-create code for some types of problems.

IMO the killer app for functional programming and languages like Ocaml and Haskell is the following :Composing contracts: an adventure in financial engineering

hmm, i wonder what C++ book you have in mindWorth bearing in mind that that code is written as much for paedogogical purposes as anything. It's also written largely to facilitate extensibility.A better measure might be how much time does it take to add a new pay-off type?

QuoteOriginally posted by: mjhmm, i wonder what C++ book you have in mindWorth bearing in mind that that code is written as much for paedogogical purposes as anything. It's also written largely to facilitate extensibility.A better measure might be how much time does it take to add a new pay-off type?Actually, for the examples in mj's book, adding a new payoff in Ocaml is very simple. Adding a new instrument is a one line change. Say you have this datatype definition:type instrument = | Forward of float (* strike *) | ... ( plus cases for american option, european option, etc)This is an instance of "is-a", which you encode with inheritance in OO. In functional languages, you use disjoint sums to encode it. You add another case (say digitals) by extending the type definition like this |... | Double_digital of float * float (* lower, upper *)This definition is concise, and I claim that is readable. Now you need to define functions on that data, or extend exisiting ones. For instance, the payoff function: let payoff (instrument, spot) = match instrument with | Forward strike -> spot - strike | ...Here 'match' is doing pattern matching on the instrument type. You add antoher case, by adding a new pattern: | Double digital (lower, uppper) -> if (lower <= spot & spot >= upper) then 1.0 else 0.0It's seldom the case that you can replace a whole C++ class (.h and .c++ files) by such little Ocaml code, of course. However, I have looked at the C++ code in Quantlib, and I claim that it would be possible to write a better version in Ocaml. Reducing code lenght is not the goal, of course. Reducing the time and money it costs to develop the code is what is important. Ocaml is a general-purpose language; if your problem can be solved with a domain-specific language (say Mathematica, Matlab, ...), and it meets your performance goals, then it'll be cheaper to use that.

QuoteOriginally posted by: fermin | Double_digital of float * float (* lower, upper *)I'd just butt in to clarify for people who've not seen the notation before.(* lower, upper *) is just a comment| Double_digital of float * floatmeans that we're defining a case to be matched, called Double_digital, that consists of a pair of floats.Quotelet payoff (instrument, spot) = match instrument with | Forward strike -> spot - strike | ...Here 'match' is doing pattern matching on the instrument type. You add antoher case, by adding a new pattern: | Double_digital (lower, upper) -> if (lower <= spot & spot >= upper) then 1.0 else 0.0And note that the patter we're matching here has the same name as we gave it in the type definition. When we're matching the name "Double_digital" fermin has matched the numbers that would be contained in the pair (2.71,3.14) with the names "lower" and "upper" in order to refer to them on the right hand side of the "->". The "->" by the way, says what the result value should be in this case - its nothing to do with member access. Something else that is not obvious is that this code is statically and strongly typed. payoff is inferred by the compiler or interpreter to be a function with the type instrument * float -> floatThat is, it takes a pair that's an instrument and a float and returns a float.

can we specify all of pay-off type, european vs american, and random number generator at run time easily?

QuoteOriginally posted by: mjcan we specify all of pay-off type, european vs american, and random number generator at run time easily?In my implementation, I decided to encode all that as a single choice in the disjoint uniontype instrument = | Option of [`Call | `Put] * [`European | `American] * float (* strike *) ...Here I have used anonymous disjoint sums for call vs put and european vs american. But you can create a dataype with a name for them as well. You construct a value of this type like this:let my_option = Option (`Call, `European, 123.45) in ...and you pass this value to a function, which can do pattern matching on this value. let my_result = payoff (my_option, spot) in ...The function 'payoff' does pattern matching like this:let payoff (instrument, spot) = match instrument with | Option (`Call,_, strike) -> max (spot -. strike) 0.0 | Option (`Put ,_, strike) -> max (strike -. spot) 0.0 | ...Here, underscore means 'I don't care what the value is'. And '-.' is substraction for FP numbers (the operator '-' is not overloaded). And, since you can pass functions around, you can write a function whose first parameter is a randon number generator function. (Functional objects in C++). Code is simpler since you just pass the function: no need to create a separate class, wrap the function in an object, etc.

QuoteOriginally posted by: ferminAnd, since you can pass functions around, you can write a function whose first parameter is a randon number generator function. (Functional objects in C++). Code is simpler since you just pass the function: no need to create a separate class, wrap the function in an object, etc.By the way, for those coming from a c++ and thinking about function objects, I think this proposal to add proper lambda expressions to the c++ language (to fix various problems with doing it via libraries) is instructive:http://www.open-std.org/jtc1/sc22/wg21/ ... n1958.pdfI think people that have tried functional concepts in real systems are convinced of the merits. And, as we'd not accept people hacking together substandard support for structured control or function/method/procedure invocations, then we should refuse substandard nasty hacks of other proven techniques. For functions/methods for example, enshrining them in language specifications themselves lets compiler writers optimize specifically for them. Same goes for other things.I'm also impressed at the C# and Visual Basic designers for drawing on this subtantial body of work in future versions (3.0 and 9.0 respectively I believe) of their languages.