Menu
▾
▴
[Quantlib-dev] 答复: 答复: Grids shift trick to improve the convergence speed PDE method
|
From: cheng l. <scr...@gm...> - 2014-11-16 05:30:25
|
Hi Peter, Thanks for your comment. It is really helpful. 1. Using std stuff will shorten the codes and make the codesclearer. I'll take that advice and change my implementation accordingly. 2. Smoothed payoff As diving into the codes deeper, I find that for FdBlackScholesVanillaEngine the smoothing technical has already been taken in. Please see the class FdmInnerValueCalculator. It is responsible for calculating average payoff value through its methd avgInnerValue. So it seems that the actual comparison I have done is that : 'Grids Shift + Payoff Smoothing + Damping' v.s. 'Payoff Smoothing + Damping '. I apologized for the missing point. Anyway as the experiment shows Payoff Smooting seems is less effective than Grids Shift ( or it may say that Payoff Smoothing and Grids Shift should work together. I haven't done an experiment with Grids shift only) 3. To move Grids shift stuff from pricing engine to payoff. Yes, I agree. This will locate the trick to where it really matters. Grids shift is working for payoff functions who have some discontinuity. So it is a payoff specific treatment. To make it engine specifc has 2 shortcome: a. it will apply to some other options who is not related to discountinuity(although it seems not hurt currently) b. it miss the chance to apply this trick to other pricing engine who also deal with payoff with discontinuity, e.g. FdBlackScholesBarrierEngine, FDEuropeanEngine) I'll think about how to adjust my implementation. Any advice is welcome. Regards, Cheng -----邮件原件----- 发件人: Peter Caspers [mailto:pca...@gm...] 发送时间: 2014年11月15日 3:34 收件人: cheng li 抄送: Klaus Spanderen; QuantLib Mailing Lists 主题: Re: [Quantlib-dev] 答复: Grids shift trick to improve the convergence speed PDE method This looks great. Some mundane comments: - requireCPoint and shiftLocation are somewhat contracting requirements, so we should forbid both being true by a QL_REQUIRE - the loop in L92 could easily be replaced by a simple lower_bound(...) - call to get (i+1), which does not help much in terms of performance, but is nicer code - cPoint is already ensured to be in [start, end], so i can not be = locations_size(), the check is not required I think. cPoint may be = start however, in which case i+1 = 0, in this case we should increase i by 1, the remaining code then works as desired. Also I think that this kind of adjustment - another example would possibly be the smoothed payoff function described just in the section just before the one you refer to (does that improve the vanilla case btw ?) - should maybe be triggered from the Payoff, i.e. via optionally implemented functions in classes derived from Payoff like void adaptGrid( ... ) // given a fd grid, return a modification (with same start, end, #points) adapted to the payoff Real fdValue( ... , Real) // return a payoff value smoothed w.r.t. a given fd grid Just a spontaneous idea, I don't know. Peter On 14 November 2014 14:17, cheng li <scr...@gm...> wrote: > Hi Spanderen, > > The numerical result says there is no much difference between these 2 > methods for vanilla option: > > The parameters are same as my previous example > > Grids Shift Grids + Damping Damping > 10 4.049015807 4.023573966 > 20 3.888731876 3.883259801 > 30 3.859347301 3.860949207 > 40 3.853164351 3.853494439 > 50 3.850117743 3.850127399 > 60 3.848403455 3.848320323 > 70 3.847346072 3.847233176 > 80 3.846453732 3.846532679 > 90 3.846028584 3.84605574 > 100 3.845716741 3.845717576 > 110 3.845481428 3.845467956 > 120 3.845299598 3.845277305 > 130 3.845111453 3.845129343 > 140 3.845005422 3.845012225 > 150 3.844918509 3.84491863 > 160 3.844846402 3.844841907 > 170 3.844785935 3.844778105 > 180 3.844717978 3.844724605 > 190 3.844676773 3.844679439 > 200 3.844641179 3.844641171 > 210 3.844307792 3.844307792 > > Regards, > Cheng > > -----邮件原件----- > 发件人: Cheng Li [mailto:scr...@gm...] > 发送时间: 2014年11月14日 20:09 > 收件人: 'Klaus Spanderen'; qua...@li... > 主题: 答复: [Quantlib-dev] Grids shift trick to improve the convergence > speed PDE method > > Hi Spanderen, > > Let me do one for us. I'll come back to you when it is finished. IMO I > think the convergence speed won't improve as much as the case for > digital since there is no discontinuity in plain vanilla payoff. > > BTW, I agree with you that this will change the default behavior if > using my implementation. That is the reason I sent this all the > developers to see other's opinion before raise a pull request in github. > > Regards, > Cheng > > -----邮件原件----- > 发件人: Klaus Spanderen [mailto:kl...@sp...] > 发送时间: 2014年11月14日 14:42 > 收件人: qua...@li... > 主题: Re: [Quantlib-dev] Grids shift trick to improve the convergence > speed PDE method > > Hi > > cool! > > The results are looking promising. Do you get a similar improvement if > you apply the shift trick to plain vanilla option. > > The only thing we might consider is that we change behavior if the > shift becomes the default. > > regards > Klaus > > On Wednesday, November 12, 2014 12:01:52 PM cheng li wrote: >> Hi Team, >> >> >> >> Current I am in an effort to improve the convergence speed of >> FdBlackScholesVanillaEngine to digital option. The background is as > follows: >> >> >> >> For digital option there is some discontinuity in the initial condition. >> Such discontinuity will cause the straight Crank-Nicolson method to >> show severe odd-even effect. In current implementation, the pricing >> engine will use several damping steps to suppress some effect. >> However as claimed in Interest Rate Modeling. Section 2.5 p60 in V1 >> by Anderson and Piterbarg, Damping steps is not adequate for such task. >> Referencing to Tavella and Randall's book, they suggest to shift the >> grids to let the discontinuity lies exactly half way between 2 grids. >> They claimed that this will greatly improve the convergence. >> >> >> >> I have completed such experimental implementation in QuantLib. >> Besides I do a comparison between "Grids Shift + Damping" and "Damping" >> methods. The result is promising. The convergence speed is greatly >> improved and is consistent with what Anderson and Piterbarg claimed. >> The result can be referred from the attached Shift_experiment.xlsx file. >> >> >> >> To replicate my result, you can replacing the original files in >> ql\methods\finitedifferences\meshers with the files I attached >> (concentrating1dmesher.hpp, concentrating1dmesher.cpp). And run the >> test program testPDEScheme.cpp >> >> >> >> The results is based on "Grids shift + 2 damping steps". Also you can >> run the test program without replacing the mesher file to see what is >> result of >> "2 damping steps". Besides I also run through the QuantLIb test suite. >> This change won't break any existing test case. >> >> >> >> Is anyone have some interest to have a look at this? I'd like to >> create a pull request for this change if no one is against it. >> >> >> >> Regards, >> >> Cheng > > > ---------------------------------------------------------------------- > ------ > -- > Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg. > clktrk _______________________________________________ > QuantLib-dev mailing list > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-dev > > > > ---------------------------------------------------------------------- > -------- Comprehensive Server Monitoring with Site24x7. > Monitor 10 servers for $9/Month. > Get alerted through email, SMS, voice calls or mobile push notifications. > Take corrective actions from your mobile device. > http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg. > clktrk _______________________________________________ > QuantLib-dev mailing list > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
