MathGroup Archive 2010

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Fast pricer for American options

  • To: mathgroup at smc.vnet.net
  • Subject: [mg110989] Re: Fast pricer for American options
  • From: Andrzej Kozlowski <akoz at mimuw.edu.pl>
  • Date: Fri, 16 Jul 2010 05:16:19 -0400 (EDT)

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.

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.

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. 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.

Andrzej Kozlowski

On 13 Jul 2010, at 18:28, Jon Harrop wrote:

> "smangano" <smangano at into-technology.com> wrote in message
> news:i1e7qe$96p$1 at smc.vnet.net...
>> On Jul 10, 4:01 am, "Jon Harrop" <use... at ffconsultancy.com> wrote:
>>> Interesting comparison of a finance-related function originally written
>>> i==
>> n
>>> Mathematica (taken from Sal Mangano's new book) rewritten in another
>>> language:
>>>
>>> http://fsharpnews.blogspot.com/2010/07/f-vs-mathematica-fast-pricer-f.. .
>>>
>>> --
>>> Dr Jon Harrop, Flying Frog Consultancy Ltd.http://www.ffconsultancy.com
>>
>> Some people on the group probably remember that Harrop is the guy who
>> shows up now and then to boast how much better F# is than Mathematica
>
> Given that you previously expressed disbelief about my statement that
> Mathematica is often orders of magnitude slower than compiled languages,
> what do you now make of the fact that the "performance critical" Mathematica
> code from your own book is 960x slower than F#? Do you not think that is a
> significant performance discrepancy in the context of a "performance
> critical" problem? One that might warrant the use of MathLink, for example?
>
>> There are numerous and very compelling reason to use Mathematica that have
>> nothing to do with speed.
>
> Not in the context of this example from your book.
>
> Cheers,
> Jon.
>
>


  • Prev by Date: Re: Primitive Disk Gradient Fills in Graphics
  • Next by Date: Re: Primitive Disk Gradient Fills in Graphics
  • Previous by thread: Re: Fast pricer for American options
  • Next by thread: Re: Fast pricer for American options