For anyone wondering what K is, I'll repost this old email exchange between an ML person and a K person (it's already online, so no privacy violation): On

For anyone wondering what K is, I'll repost this old email exchange between an ML person and a K person (it's already online, so no privacy violation): On Wed, 12 Oct 2005, Fermin Reig wrote: > Dear Rico, > > I have read Mark Joshi's book on C++ design patterns (as well as your > review) and I'd like to share my opinion of the book with you. (By the > way, I find the information in your website very useful.) > > My interest in the book was to try to learn how theory is put into > practise. The best way to do that is by actually implementing things, so > I did: I reimplemented his C++ code in OCaml, a functional, OO language > that I like using. However, instead of a direct translation of C++ > classes to OCaml classes, I chose a non-OO design. The result is quite > interesting from the point of view of code complexity and programming > productivity (and hence cost). Here's a summary: > > Monte Carlo (datatypes only) > C++: 264 lines of code (LOC), (7 classes, 20 methods), 12 files > ML : 33 LOC, (3 datatypes, 1 function), 2 files > LOC ML/C++: 33/264 = 13% > Binomial trees (datatypes only) > C++: 264 + 138 = 402 LOC, (10 classes, 30 methods), 18 files > ML : 33 + 12 = 45 LOC, (3 datatypes, 3 functions), 2 files > LOC ML/C++: 45/402 = 11% > Binomial trees (datatypes + main algorithm) > LOC ML/C++: 165/522 = 32% > > I'm not claiming that Mark's C++ code is bad (actually, it's quite > good). However, using a better tool results in obtaining a better final > product. (Performance of Ocaml's code is competitive with C++ as well.) > > I have written slides with more details about this, which I have shown > to a few friends. If you would like to see them, I can email them to > you. (I have also told Mark Joshi about my evaluation.) > > Regards, > Fermin Hi Fermin, Not bad. But my K implementation only uses 2 lines of code though... EuroOpt:{[S;K;r;v;T;n;po] / spot, strike, rate, vol, expir, steps, payoff / initialize constants p:(%2*m)*(1%D)-d:a-m:_sqrt -1+a*a:.5*(_exp dt*r+v*v)+D:_exp -r*dt:T%n; / apply n binomial steps :*n{-1_ D*(p*1!x)+x*1-p}/K po' S*(1%d)^(2*!n+1)-n } ...and here are some test cases... po:{0|x-y}; / arbitrary payoff function: max(0, K-S) for put / compare results for n = 16, 32, 64, 128, and 256 \t EuroOpt[5;10;.06;.3;.5;;po]' _16*2^!5 / pass in payoff functions for put, call, and digital \t EuroOpt[8;10;.06;.3;.5;500;]' {0|x-y},{0|y-x},{y>x} / investigating convergence for a digital option with 1-300 steps... EuroOpt[8;10;.06;.3;.5;;{y>x}]' 1+!300 So yes, I agree with you. Functional languages are cool and C++ is verbose & restrictive. Unfortunately, in the real world people don't care about any of this... :-) Cheers, - Rico And that was the previous version of K, before Q/kdb+. Things are probably even more concise now, but I've stopped following this about 10 years ago. Good times.