|
From: Peter C. <pca...@gm...> - 2014-11-14 19:33:44
|
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 |