Hello,
I am looking to get started on some Quantlib development and am looking for a suitable introductory project. I was thinking about porting some of the Finite Difference Pricers to the Pricing Engine framework. However, I have quickly ended up in the depths of FdBsmOption.cpp, and SingleAssetOption. I am planning on using the FiniteDifferences namespace as it is currently used in the Pricers. I am going to start with Single Asset equity style options, then going on to Baskets if things go well. I am not so interested in the IR or stochastic vol models at the moment. Any comments or ideas? If this seems a bit complex for a first project does anyone have a suggestion for a straightforward enhancement that would take 10 hours coding, say. Thanks, Neil --------------------------------------------------- Neil Firth Brasenose College Oxford OX1 4AJ United Kingdom Office: 01865 280616 [hidden email] http://www.maths.ox.ac.uk/~firth --------------------------------------------------- |
Hi Neil,
the finite difference pricers is quite slow if you need an intensive pricing tool. That's why I developped an analytical approximation to american options with discrete and continous dividends. For example, I've added the Roll, Geske, Whaley method to price American Call with discrete dividends like it is discribed in Hull 4th P271. It's quite simple as it changes only few files. I already proposed to Quantlib user group to share the code but it looks like it didn't received a lot of interest. If it's something that's look interesting you could start with my code and improve it with greeks for example, it shouldn't take more than 10 hours. Bye Xavier Neil P Firth <[hidden email]> To: [hidden email] Sent by: cc: [hidden email] Subject: [Quantlib-users] Finite Difference Pricing Engine eforge.net 20/05/2003 13:49 Hello, I am looking to get started on some Quantlib development and am looking for a suitable introductory project. I was thinking about porting some of the Finite Difference Pricers to the Pricing Engine framework. However, I have quickly ended up in the depths of FdBsmOption.cpp, and SingleAssetOption. I am planning on using the FiniteDifferences namespace as it is currently used in the Pricers. I am going to start with Single Asset equity style options, then going on to Baskets if things go well. I am not so interested in the IR or stochastic vol models at the moment. Any comments or ideas? If this seems a bit complex for a first project does anyone have a suggestion for a straightforward enhancement that would take 10 hours coding, say. Thanks, Neil --------------------------------------------------- Neil Firth Brasenose College Oxford OX1 4AJ United Kingdom Office: 01865 280616 [hidden email] http://www.maths.ox.ac.uk/~firth --------------------------------------------------- ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Quantlib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users ************************************************************************* Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La Fimat et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. ******** This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither Fimat nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ************************************************************************* |
At 02:17 PM 5/20/03 +0200, [hidden email] wrote:
>the finite difference pricers is quite slow if you need an intensive >pricing tool. >That's why I developped an analytical approximation to american options >with discrete and continous dividends. >For example, I've added the Roll, Geske, Whaley method to price American >Call with discrete dividends like it is discribed in Hull 4th P271. > >It's quite simple as it changes only few files. >I already proposed to Quantlib user group to share the code but it looks >like it didn't received a lot of interest. Xavier, my fault. I fell into the "better is enemy of good" trap. Namely, I though "Ok, I'll integrate Xavier's pricer in the library when we switch finite differences to the new framework---no need to do it twice." But of course the switch is taking longer than expected, and your code is waiting in limbo. I should have known better... >If it's something that's look interesting you could start with my code and >improve it with greeks for example, it shouldn't take more than 10 hours. Yes, I second that. Switching the existing pricers to the new framework doesn't exactly strike me as an introductory project, or a 10-hours one. At least, I know it would take _me_ more than 10 hours, and I know the library. Bye, Luigi P.S. Oh, and yes, I'll try and add Xavier's code to the library this time... |
In reply to this post by Neil P Firth
Hi Luigi,
Thank you for this answer. I also did the Barone Adesi Whaley approximation for continous dividend. I did all the developpement in my Quantlib 0.3.0. Do not hesitate to ask me the code if it has an interest for Quantlib group once the switch will be completed. When I said 10 hours I was thinking of my old Quantlib 0.3.0 not the new framework, for example to add an approximation for greeks (I don't know if it exists but we can search) or to find what to do with american put with discrete dividend. I wouldn't say that switching to the new framework take less than 10 hours, my proposal is obviously not good if Neil wants to work on this switch, this is more a technical question than a financial one and I don't have any good idea to propose on this subject. Bye Xavier Luigi Ballabio <[hidden email]> To: [hidden email], Neil P Firth <[hidden email]> Sent by: cc: [hidden email] [hidden email] Subject: Re: [Quantlib-users] Finite Difference Pricing Engine eforge.net 20/05/2003 14:49 At 02:17 PM 5/20/03 +0200, [hidden email] wrote: >the finite difference pricers is quite slow if you need an intensive >pricing tool. >That's why I developped an analytical approximation to american options >with discrete and continous dividends. >For example, I've added the Roll, Geske, Whaley method to price American >Call with discrete dividends like it is discribed in Hull 4th P271. > >It's quite simple as it changes only few files. >I already proposed to Quantlib user group to share the code but it looks >like it didn't received a lot of interest. Xavier, my fault. I fell into the "better is enemy of good" trap. Namely, I though "Ok, I'll integrate Xavier's pricer in the library when we switch finite differences to the new framework---no need to do it twice." But of course the switch is taking longer than expected, and your code is waiting in limbo. I should have known better... >If it's something that's look interesting you could start with my code and >improve it with greeks for example, it shouldn't take more than 10 hours. Yes, I second that. Switching the existing pricers to the new framework doesn't exactly strike me as an introductory project, or a 10-hours one. At least, I know it would take _me_ more than 10 hours, and I know the library. Bye, Luigi P.S. Oh, and yes, I'll try and add Xavier's code to the library this time... ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Quantlib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users ************************************************************************* Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La Fimat et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. ******** This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither Fimat nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ************************************************************************* |
Hi,
Are these approximations coded up in the Pricing Engine framework? I could code up another approximation, that shouldn't be too hard. Any suggestions? What is the timetable for checking in the approximations to CVS? For the greeks I guess the simplest solution would be to bump the inputs and do a simple finite difference, it would slow things down though. If someone wants to do the calculus they can check the result against the finite differences ;) Neil --------------------------------------------------- Neil Firth Brasenose College Oxford OX1 4AJ United Kingdom Office: 01865 280616 [hidden email] http://www.maths.ox.ac.uk/~firth --------------------------------------------------- |
In reply to this post by Neil P Firth
Hi Neil,
Taking the finite difference for greeks is the least solution. Maybe a new method to apply "practical greeks" at the portfolio level is a good enhancement for risk managers but there's a close formula to deduce delta and gamma in the case of Geske Johnson approximation (continous dividend). I don't know yet if the same thing has already been given for other approximation but it's certainly not too hard to find. Xavier Neil P Firth <[hidden email]> To: [hidden email] Sent by: cc: [hidden email] Subject: Re: [Quantlib-users] Finite Difference Pricing Engine eforge.net 20/05/2003 15:47 Hi, Are these approximations coded up in the Pricing Engine framework? I could code up another approximation, that shouldn't be too hard. Any suggestions? What is the timetable for checking in the approximations to CVS? For the greeks I guess the simplest solution would be to bump the inputs and do a simple finite difference, it would slow things down though. If someone wants to do the calculus they can check the result against the finite differences ;) Neil --------------------------------------------------- Neil Firth Brasenose College Oxford OX1 4AJ United Kingdom Office: 01865 280616 [hidden email] http://www.maths.ox.ac.uk/~firth --------------------------------------------------- ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Quantlib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users ************************************************************************* Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La Fimat et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. ******** This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither Fimat nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ************************************************************************* |
In reply to this post by Xavier.Abulker
>What is the timetable for checking in the approximations to
>CVS? there is now timetable. CVS is open 24/7. QuantLib releases are different: they should have a timetable, but actually they haven't ------------ ciao -- Nando |
In reply to this post by Xavier.Abulker
At 03:11 PM 5/20/03 +0200, [hidden email] wrote:
>I also did the Barone Adesi Whaley approximation for continous dividend. Xavier and Neil, just a thought: I guess the above doesn't use the finite-differences machinery. In that case, it could already be written as a particular pricing engine that could be used with VanillaOption. This could give Neil a bit of practice with the pricing engine framework, without throwing him in the middle of the FD mess. Cheers, Luigi |
Writing a pricing engine for an approximation method for a Vanilla Option
sounds like a good idea. I've got various papers on approximations. I'll have a look and try some out. Neil --------------------------------------------------- Neil Firth Brasenose College Oxford OX1 4AJ United Kingdom Office: 01865 280616 [hidden email] http://www.maths.ox.ac.uk/~firth --------------------------------------------------- On Wed, 21 May 2003, Luigi Ballabio wrote: > At 03:11 PM 5/20/03 +0200, [hidden email] wrote: > >I also did the Barone Adesi Whaley approximation for continous dividend. > > Xavier and Neil, > just a thought: I guess the above doesn't use the > finite-differences machinery. In that case, it could already be written as > a particular pricing engine that could be used with VanillaOption. This > could give Neil a bit of practice with the pricing engine framework, > without throwing him in the middle of the FD mess. > > Cheers, > Luigi > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Quantlib-users mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/quantlib-users > |
In reply to this post by Neil P Firth
Yes, correct,
This is an analytical approximation and I just needed to change SingleAssetOption and EuropeanOption this is why I thought it could be a good quite start and not long to check. Now the list that Ferdinando proposed yesterday will be certainly more profitable to the Quantlib project. Xavier Luigi Ballabio <[hidden email]> To: [hidden email] Sent by: cc: Neil P Firth <[hidden email]>, [hidden email] [hidden email] eforge.net Subject: Re: [Quantlib-users] Finite Difference Pricing Engine 21/05/2003 10:40 At 03:11 PM 5/20/03 +0200, [hidden email] wrote: >I also did the Barone Adesi Whaley approximation for continous dividend. Xavier and Neil, just a thought: I guess the above doesn't use the finite-differences machinery. In that case, it could already be written as a particular pricing engine that could be used with VanillaOption. This could give Neil a bit of practice with the pricing engine framework, without throwing him in the middle of the FD mess. Cheers, Luigi ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Quantlib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users ************************************************************************* Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La Fimat et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. ******** This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither Fimat nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ************************************************************************* |
In reply to this post by Neil P Firth
Hi Neil,
Bernt Arne Ødegaard gives the Roll-Geske-Whaley and Baron Adesi Whaley call formula and code as well. http://finance.bi.no/~bernt/gcc_prog/algoritms/algoritms/node10.html http://finance.bi.no/~bernt/gcc_prog/algoritms/algoritms/node24.html Xavier Neil P Firth <[hidden email]> To: [hidden email] Sent by: cc: [hidden email] Subject: Re: [Quantlib-users] Finite Difference Pricing Engine eforge.net 21/05/2003 10:47 Writing a pricing engine for an approximation method for a Vanilla Option sounds like a good idea. I've got various papers on approximations. I'll have a look and try some out. Neil --------------------------------------------------- Neil Firth Brasenose College Oxford OX1 4AJ United Kingdom Office: 01865 280616 [hidden email] http://www.maths.ox.ac.uk/~firth --------------------------------------------------- On Wed, 21 May 2003, Luigi Ballabio wrote: > At 03:11 PM 5/20/03 +0200, [hidden email] wrote: > >I also did the Barone Adesi Whaley approximation for continous dividend. > > Xavier and Neil, > just a thought: I guess the above doesn't use the > finite-differences machinery. In that case, it could already be written as > a particular pricing engine that could be used with VanillaOption. This > could give Neil a bit of practice with the pricing engine framework, > without throwing him in the middle of the FD mess. > > Cheers, > Luigi > > > > ------------------------------------------------------- > This SF.net email is sponsored by: ObjectStore. > If flattening out C++ or Java code to make your application fit in a > relational database is painful, don't do it! Check out ObjectStore. > Now part of Progress Software. http://www.objectstore.net/sourceforge > _______________________________________________ > Quantlib-users mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/quantlib-users > ------------------------------------------------------- This SF.net email is sponsored by: ObjectStore. If flattening out C++ or Java code to make your application fit in a relational database is painful, don't do it! Check out ObjectStore. Now part of Progress Software. http://www.objectstore.net/sourceforge _______________________________________________ Quantlib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users ************************************************************************* Ce message et toutes les pieces jointes (ci-apres le "message") sont confidentiels et etablis a l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisee est interdite. Tout message electronique est susceptible d'alteration. La Fimat et ses filiales declinent toute responsabilite au titre de ce message s'il a ete altere, deforme ou falsifie. ******** This message and any attachments (the "message") are confidential and intended solely for the addressees. Any unauthorised use or dissemination is prohibited. E-mails are susceptible to alteration. Neither Fimat nor any of its subsidiaries or affiliates shall be liable for the message if altered, changed or falsified. ************************************************************************* |
Free forum by Nabble | Edit this page |