Re: Fast pricer for American options
- To: mathgroup at smc.vnet.net
- Subject: [mg111017] Re: Fast pricer for American options
- From: "Jon Harrop" <usenet at ffconsultancy.com>
- Date: Sat, 17 Jul 2010 08:15:19 -0400 (EDT)
- References: <i1p82e$pjt$1@smc.vnet.net>
"Andrzej Kozlowski" <akoz at mimuw.edu.pl> wrote in message news:i1p82e$pjt$1 at smc.vnet.net... >I do not have The Mathematica Cookbook and have not seen the code for the >"pricer of American options". But as someone who has spent quite a lot of >time working on option pricing with Mathematica it seems to me that the >posts that have appeared on this subject involve several important >misconceptions. > > First of all, the code in question does not price "American options". What > it does is price "American options" in the single factor Black-Scholes > model, a special case of rather limited utility. I assume that this is > done using the binomial tree model of Cox-Ross-Rubinstein. I have > implemented this for the Wolfram Demonstrations project. The example in > the demonstration actually draws a tree and is therefore rather slow, but > the code used to compute the "accurate value" is much faster and, in my > opinion, close to the optimum that can be implemented with Mathematica. I > have no idea how it compares with the code in the Mathematica Cookbook or > with the code implemented in F#, but in my opinion this hardly matters. > My code is fast enough for the Mathematica Demonstrations project and > given the speed of present day computer, this means it is fast enough for > most applications where this sort of thing might be useful - e.g. teaching > the Black-Scholes model. For serious applications having a program even > two orders of magnitude faster that gives the same wrong answer is no > great advantage. Very interesting. I was not aware that the ideas presented in the book were "of rather limited utility". I trust this is the Wolfram Demonstration you are referring to: http://demonstrations.wolfram.com/AmericanCallAndPutOption/ FWIW, I would replace Text[stocklabels[[i]], i] with Text[stocklabels[[i]], i, {0, -2}] because the text is illegible when over the graphics. Nice demo though! > There are two reasons for this. First, as the not so distant financial > crisis so convincingly showed, the Black-Scholes model (which implies the > possibility of perfect hedging of options with the underlying and thus > makes options redundant) seriously underestimates market risks and should > not be used (at least) as the "default" pricing tool. (This just one of > many situations where popularity is a poor indication of quality). Much > more realistic incomplete models (which do not permit perfect hedging) > have long been available but they require more sophisticated mathematical > tools, such as Fourier transform, Quadrature and Interpolating functions. > Moreover these methods also work in the multifactor setting, in which the > binomial method (which really is just a spacial case of the finite > difference method for solving PDE's) does not perform well. Essentially > all important real life problems involving options are multi-factor. I see. > Examples of pricing of options in such models can be found on the Wolfram > demonstrations site. A powerful quadrature based method that can be > applied to multi-factor models beyond the Black-Scholes model was > described by Andrew Lyasoff in volume 10 issue 4 of the Mathematica > Journal. The method makes use of NIntegrate and Interpolation. > > If that is something that F# can do orders of magnitude faster than > Mathematica than I admit that would be impressive, but somehow I doubt it. Well, this needs to be tested. I have downloaded the Mathematica source and will have a play with it... > If it can't, the whole issue is a red herring. If one really wants to use > a compiled language for purposes of option pricing, there is already a > great deal of free C-code available and F# has no advantage whatever. Of > course C does not have anything like the flexibility of Mathematica as a > tool for financial mathematics (I don't think anyone would dispute this), > and, of course, when one really wants to run C-code there is always > MathLink. > > Given all that, I can't see any room for something like F# in this area at > all. F# is both high-level (like Mathematica) and fast (like C) but it actually has several important benefits over both of those languages such as its support for parallel programming. For example, ParallelTable in Mathematica is 250x slower than Array.Parallel.init in F#. Cheers, Jon.