Posted by
Joseph Wang on
Jan 03, 2005; 8:08pm
URL: http://quantlib.414.s1.nabble.com/FdDividendAmericanOption-tp3453p3456.html
Yes, you are correct. The patch that I gave seems stable, but it solves
the wrong problem :-(
It took me a bit of algebra to convince myself of this.
There are two possibilities that I see:
1) that there is a really simple error (signs maybe) - I'm starting to
doubt this more and more, because I don't think that a simple error
would have escaped all of the eyes that are staring at this. The other
issue is that isn't not obvious how a sign error would cause the
equation to be stable at low grid sizes.
2) a much nastier problem is the possibility that there is some subtle
PDE interaction going on. Diffusion equations generally don't have
these problems, but the discretization adds in an advection term, and
this may be causing things to break. If this is the problem then one
would expect the differencing to become unstable at delta t > nu * delta
x. Let me try messing with the difference equations to see what I can do.
Luigi Ballabio wrote:
> On 12/31/04 08:16:31, Joseph Wang wrote:
>
>> I think the basic problem is that when you turn x = log(S) into an
>> operator, dx = dS / S and you start getting extra terms in the
>> difference equation that aren't being put into BSMOperator. One
>> could go and work out what the operator should be with a logarithmic
>> grid, but I suspect that the second derivative is going to add a lot
>> of nasty terms.
>
>
> Joseph,
> no, the BSM operator is already the correct discretization for
> the logarithm of S. It discretizes in space the equation
>
> df/dt = - sigma^2/2 * d^2f/dx^2 - nu * df/dx + r*f
>
> that one gets from changing the variable from S to x = log S in the
> BS equation. At the point of discretization, it is only incidental
> that x comes from a logarithm; it is simply the variable being
> discretized, and building a "logarithmic" grid is just a way (albeit
> a roundabout one) to build an equally spaced grid for x. In fact, the
> name "grid_" in the code is a misnomer; it is not the grid { x_1,
> ..., x_N } used for the operator,
> but rather the set { S_1, ..., S_N } of prices corresponding to the
> grid points. The actual grid is { log(S) for S in grid_ }, and if you
> print it out, you'll see that it is correctly spaced. In short, it
> is beyond me how your patch provides results that look sensible :)
>
> I had naively hoped to give the problem some time during the weekend,
> but I found that having a wife and a couple of kids seriously cuts
> into one's debugging time :)
> All I was able to put together was the small patch below, which does
> not completely remove the instability, but at least triggers it only
> above 250 asset steps for the example code given.
>
> diff -r1.28 fddividendoption.cpp
> 74c74
> < setGridLimits(center_ + dividends_[step], dates_[step]);
> ---
>
>> setGridLimits(center_ + dividends_[step], residualTime_);
>
>
> Basically, the code tried to be smart (probably too much for its own
> good) and resize the grid based on the time to the dividend payment.
> Now it resizes it based on the time to maturity, so that it doesn't
> end up with a grid too different from the one it started with.
>
> But the sad truth is, the whole thing should be rewritten. I had a
> look at the code in the past few days (I had'n written it myself) and
> it's a tangle of methods, each one trying to outsmart the user and
> correct the number of grid points, the grid limits and whatever else
> based on what was thought to be a "safe" choice of parameters. Not
> that it can't be useful, but the user should at least have the choice
> to say "heck no, just do as I said."
>
> Needless to say, at this time I wouldn't use the FD dividend options
> where actual money is involved---at least, not without cross-checking
> the results with some other pricer or some other source.
>
> Later,
> Luigi
>