I'm trying to construct a lookup table (for option pricing software) that can price option quicker. The idea is compute a lookup table and place the option prices corresponding to a set of underlying prices (given a fixed time and vol).

I'm considering using the taylor series expansion to approximate option prices corresponding to underlying prices I did not compute. So for each option, I will have n option prices, n deltas and n gammas for n underlying prices. And if the underlying price does not correspond to any of the values computed, I will interpolate/extrapolate according to:C2 ~ C1 + Delta1 * (F2 - F1) + 0.50 * Gamma1 * (F2 - F1) * (F2 - F1)

The question is: what is the maximum dF (the space between 2 precomputed option prices) is?

For near-term options that are close to ATM (high gamma), we would want the points to be closer to each other? Perhaps, the dF should be finer toward ATM.

Is there a rule of thumb (to compute dF) that is expiration-dependent?

Thanks,hilss

p.s. I'm only doing this for exchange-listed options (euro and american only).

You have to remember that the interpolation only fails because your higher-order terms are "big". This is the case for options that are ATMF and close to expiration. A simple solution would be to have a grid spacing constant that is multiplied by and also dependent on it's log moneyness abs(log(F1/K)). (subject to some floor of course so that the step size doesn't become nonsensically small).

Now the other adjustment you need to incorporate your volatility, because if your volatility is really small, then you need to make your step size smaller. I would just take one volatility (regardless of strike) to drive this adjustments.

Yes, something like that. You're obviously going to have to do a few practical restrictions, so that the numbers don't become too small in the last hours before expiration (if you price your T in real time?)

Just to clarify: F would be your interpolation point in dimension S, (what you called F1, F2, etc. which is why I continued with your notation). That way, the further away you are from K (should really be K*exp(rT) I supppse), the wider your spacings.

The thing to keep in mind is: Keep it simple, so that it does not become too difficult to debug during production issues.