I have a long history of option prices and I've been using QuantLib to back out the implied volatility and then produce the major greeks. This works fine, but I'm finding my code is pretty slow (I know that's subjective). I end up instantiating a new BlackScholesMertonProcess, DividendVanillaOption, etc for every option each day, which I think is part of the problem. I thought it might be faster to price the same option over time (e.g. loop over days then strikes, instead of looping over strikes then days). Looking over the documentation, I don't think I'm leveraging the full Observer/Observable functionality.
To try and put this into a simple example, what would be an efficient way to calculate an option price over a vector of evaluationDates? I would think something like this would be the right approach, but it doesn't seem to have an effect on the option value (get same value for all days)
... UnitedStates calendar(UnitedStates::NYSE); americanOption->registerWith(Settings::instance().evaluationDate()) ; while(todaysDate <= expiryDate)
{ Settings::instance().evaluationDate() = todaysDate; cout << todaysDate << " : " << americanOption->NPV() << endl ; todaysDate = calendar.advance(todaysDate, 1 * Days) ;
} Even if the above code did have the desired effect, I would still need to adjust the IV, rates, etc. Are there examples available for adjusting the inputs for an option price? I can post the full code, but I suspect my understanding of the library is the problem here.
Thanks, George ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
This blog post may help http://implementingquantlib.blogspot.com/2014/05/chapter-6-part-3-of-8-black-scholes.html As mentioned “Using
apply, the
evolve method performs an exponentiation at each step; but above
all, the drift and
diffusion methods repeatedly ask term structures for values. If you
remember
this post, this means going through at least a couple of levels of virtual method calls, sometimes (if we're particularly unlucky) retrieving a rate from discount factors that were obtained from the same rate to begin with.” Updating the various term structures and dividend class does involve observer, particularly if everyone properly registers themselves to receive updates. Perhaps
sending the right updates will dirty the NPV calculation and result in a recalculation upon the next call (lazy evaluation). That’s what I would expect. I suspect what you want to do is already possible in QuantLib. Dale Smith, Ph.D. Senior Financial Quantitative Analyst Financial & Risk Management Solutions Fiserv Office: 678-375-5315 From: George Cowie [mailto:[hidden email]]
I have a long history of option prices and I've been using QuantLib to back out the implied volatility and then produce the major greeks. This works fine, but I'm finding my code is pretty slow (I know that's subjective). I end up instantiating
a new BlackScholesMertonProcess, DividendVanillaOption, etc for every option each day, which I think is part of the problem. I thought it might be faster to price the same option over time (e.g. loop over days then strikes, instead of looping over strikes
then days). Looking over the documentation, I don't think I'm leveraging the full Observer/Observable functionality. To try and put this into a simple example, what would be an efficient way to calculate an option price over a vector of evaluationDates? I would think something like this would be the right approach, but it doesn't seem to have an effect
on the option value (get same value for all days) ... UnitedStates calendar(UnitedStates::NYSE); americanOption->registerWith(Settings::instance().evaluationDate()) ; while(todaysDate <= expiryDate) { Settings::instance().evaluationDate() = todaysDate; cout << todaysDate << " : " << americanOption->NPV() << endl ; todaysDate = calendar.advance(todaysDate, 1 * Days) ; } Even if the above code did have the desired effect, I would still need to adjust the IV, rates, etc. Are there examples available for adjusting the inputs for an option price? I can post the full code, but I suspect my understanding
of the library is the problem here. Thanks, George ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
In reply to this post by George Cowie
I do what you're after (i.e., changing the evaluation date and seeing
a different value) in the middle of this screencast: <http://vimeo.com/92785062>. The fact that it doesn't work for you might have to do with the way you setup your term structures. I (still) don't have a screencast for that :) But in short, if you create your term structures by passing an explicit reference date, they will remain fixed; if you create them with an offset in days (possibly null) they will move with the evaluation date. Depending on the particular term-structure class you're using, there might be constructors for either case. Also, you don't need to do the registering yourself. If you set up the term structures correctly, they are already registered with the evaluation date and will forward notifications to the pricing engine and the instrument. Again, the screencast should help. Luigi On Fri, Jun 20, 2014 at 2:11 PM, George Cowie <[hidden email]> wrote: > > I have a long history of option prices and I've been using QuantLib to > back out the implied volatility and then produce the major greeks. This > works fine, but I'm finding my code is pretty slow (I know that's > subjective). I end up instantiating a new BlackScholesMertonProcess, > DividendVanillaOption, etc for every option each day, which I think is part > of the problem. I thought it might be faster to price the same option over > time (e.g. loop over days then strikes, instead of looping over strikes then > days). Looking over the documentation, I don't think I'm leveraging the > full Observer/Observable functionality. > > To try and put this into a simple example, what would be an efficient way > to calculate an option price over a vector of evaluationDates? I would > think something like this would be the right approach, but it doesn't seem > to have an effect on the option value (get same value for all days) > > ... > > UnitedStates calendar(UnitedStates::NYSE); > americanOption->registerWith(Settings::instance().evaluationDate()) ; > > while(todaysDate <= expiryDate) > { > Settings::instance().evaluationDate() = todaysDate; > cout << todaysDate << " : " << americanOption->NPV() << endl ; > todaysDate = calendar.advance(todaysDate, 1 * Days) ; > > } > > Even if the above code did have the desired effect, I would still need to > adjust the IV, rates, etc. Are there examples available for adjusting the > inputs for an option price? I can post the full code, but I suspect my > understanding of the library is the problem here. > > Thanks, > George > > ------------------------------------------------------------------------------ > HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions > Find What Matters Most in Your Big Data with HPCC Systems > Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. > Leverages Graph Analysis for Fast Processing & Easy Data Exploration > http://p.sf.net/sfu/hpccsystems > _______________________________________________ > QuantLib-users mailing list > [hidden email] > https://lists.sourceforge.net/lists/listinfo/quantlib-users > -- <https://implementingquantlib.blogspot.com> <https://twitter.com/lballabio> ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Thanks for pointing out the screencast, very helpful. And yes, you were correct, I was passing explicit reference dates to my term structures... Passing in an offset cleared up the behavior I was seeing.
On Fri, Jun 20, 2014 at 8:17 AM, Luigi Ballabio <[hidden email]> wrote: I do what you're after (i.e., changing the evaluation date and seeing ------------------------------------------------------------------------------ HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions Find What Matters Most in Your Big Data with HPCC Systems Open Source. Fast. Scalable. Simple. Ideal for Dirty Data. Leverages Graph Analysis for Fast Processing & Easy Data Exploration http://p.sf.net/sfu/hpccsystems _______________________________________________ QuantLib-users mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-users |
Free forum by Nabble | Edit this page |