wilmott.com

(double)

QuoteOriginally posted by: outrunAre you using an European control variate? That removes a lot of grid placement error.Where are control variates used? This is typically MC trick!(?)You have to ensure a point of discontinuity is a grid point.

QuoteOriginally posted by: Alan Re consensus. OK -- the consensus is that the last digit is a 6 or a 7.What's the question?

OutrunThe 2006 paper is not worth chasing - last time I heard the "quasi-closed form" took at least a day to runIf you want to read something, the Joshi paper on truncation and acceleration is much more valuableMike

QuoteOriginally posted by: spursfanOutrunThe 2006 paper is not worth chasing - last time I heard the "quasi-closed form" took at least a day to runIf you want to read something, the Joshi paper on truncation and acceleration is much more valuableMikeWhat I did was run the code on the night shift.BTW how long does NT = 2 000 000 take using Joshi's method?Quote An exact and explicit solution for the valuation of American put options"Nonsense. No such thing as exact solution for nonlinear problems, IMO. To misquote J v N"Any one who considers exact solutions to solving problems, of course, in a state of sin."

I ran my code all the way up to 16,000,000 steps in less than 20 minutes using ExcelDna and VB.NET code - the truncation is brilliant and you can set the tolerance to minimise the truncation error

QuoteOriginally posted by: spursfanI ran my code all the way up to 16,000,000 steps in less than 20 minutes using ExcelDna and VB.NET code - the truncation is brilliant and you can set the tolerance to minimise the truncation errorThat's very good. But how do we know that 6.299597 is correct?

Here are my Tian valuesnStep Tian tree Tol (=0.25/nStep) Tian + extrapolation =2*T(2*nStep)-T(nStep) 64 6.29099554 0.00390625 6.30023828128 6.29561691 0.00195313 6.29922581256 6.29742136 0.00097656 6.29979572512 6.29860854 0.00048828 6.299674231024 6.29914139 0.00024414 6.299539262048 6.29934033 0.00012207 6.299601794096 6.29947106 0.00006104 6.299599888192 6.29953547 0.00003052 6.2995876916384 6.29956158 0.00001526 6.2995912932768 6.29957644 0.00000763 6.2995928065536 6.29958462 0.00000381 6.29959418131072 6.29958940 0.00000191 6.29959515262144 6.29959227 0.00000095 6.29959565524288 6.29959396 0.00000048 6.299596131048576 6.29959504 0.00000024 6.299596402097152 6.29959572 0.00000012 6.299596624194304 6.29959617 0.00000006 6.299596818388608 6.29959649 0.00000003 6.2995967616777216 6.29959663 0.00000001

For me, the most important feature of the truncated tree is the consistent halving of the differences in values as you continue doubling the number of steps - and I surmise that this pattern would be true of any untruncated trees (but forgive me for not volunteering to run the code up to 16m steps!)Joshi shows how the error due to truncation will be less than the prescribed toleranceThe Tian trinomial tree for barriers involves nodes either side of the strike but these here are a separate set of parameters for the binomial tree - and getting the truncation nodes correct at each time step is not that straightforward

QuoteOriginally posted by: outrunI think there are an awful lot of floats operations involved.. Maybe we need multiprecision to get more digits? Tian is very easy to implement, no? There are a couple of versions if I remember correctly? And placement of a node on the strike (or in between?)I bet Cuch can do it in a single hour!Yeah, I have most of them in the framework.To test the validity of 6.299ETC we need to do it in Boost multiprecision: Two outcomes:1. Same answer?2. Different answer?Has round off reared its ugly head? If 2 is the outcome then we have a big problem.// And placement of a node on the strike (or in between?)For lattice, on K. Quote true of any untruncated trees (but forgive me for not volunteering to run the code up to 16m steps!)~ 8 days=====@outunedit:Took NT = 200 000 and run lattice code under Boost multiprecision. Values look same as beforedouble: 6.2995931786multi: 6.29959317857878So, it seems rounding error is not an issue, at least for this example. BTW the multiprecision code takes forever