Help on Multi Asset Options
Locked
 
|
Hi,
I'm writing here after attempts on the other mailing list which seems a bit dead. I hope it is a better place for my problem. I have to confess that I am a new user of QuantLib and I would like to write a "generic" MC engine to price "generic" product depending on many fixings of many assets. I've found in QuantLib something that is almost what I want, and it is the "mcbasketengine". It lack only the ability to price path dependent options. But I don't think it is complicated to add it. My issue is on the instrument side. I would like to reuse as much as possible what is already there, but I am not able to use of the classes inheriting from "Option" and "Payoff". I should inherit from "Instrument", but this is the very base class and I would end up rewriting something similar to "Option" and "Payoff". The problem with "Option" and "Payoff" is that the don't seem to handle the case of Multi Assets. 1)Basically Payoff has this method virtual Real Payoff::operator()(Real price) const = 0; That does not adapt easily to the MultiAsset case. BasketPayoff sligthly improves things with virtual Real operator()(const Array &a) const { return (*basePayoff_)(accumulate(a)); } but it still relies on the concept of Basket = sum of components. 2) MultiAssetOption has the following methods Real delta() const; Real gamma() const; Real vega() const; Real dividendRho() const; which in my opinion should return Arrays or Matrices Am I approaching the problem from the wrong point of view? Let me know what if the best place to address similar questions. Andrea ------------------------------------------------------------------------- SF.Net email is sponsored by: Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
Re: Help on Multi Asset Options
|
|
Hi Andrea,
here we are. Apologies for the delay. On Sun, 2007-12-09 at 20:14 +0000, Andrea wrote: > I have to confess that I am a new user of QuantLib and I would like to > write a "generic" MC engine to price "generic" product depending on > many fixings of many assets. > > I've found in QuantLib something that is almost what I want, and it is > the "mcbasketengine". > It lack only the ability to price path dependent options. But I don't > think it is complicated to add it. No, it's not. The problem is that at this time, the engine is not a generic MC basket engine---it's a European one. The pathPricer() and timeGrid() methods should be made abstract and their implementations moved to a McEuropeanBasketEngine class. Then you could inherit your engine from the (now truly generic) base engine, defining timeGrid() to return the relevant times for your pricing and pathPricer() to return a path-dependent pricer. Unfortunately, much of the BasketOption class seems to be based on the same assumptions (an European exercise, and a payoff depending on a single number, be it the average, the min, or the max of the underlying values) hence the problems you're having in fitting a generic payoff over it. We'll have to review it and try to generalize a bit. In the meantime, you can work your way around it. My suggestion is to generalize the McBasket class as I sketched above, write the formulas you need in your PathPricer, and disregard the payoff classes entirely. To keep it cleaner, you might want to inherit your class(es) from BasketOption so that their constructor don't take a payoff. > 2) MultiAssetOption has the following methods > > Real delta() const; > Real gamma() const; > Real vega() const; > Real dividendRho() const; > > which in my opinion should return Arrays or Matrices I think so too. Hmm, it's a long time since I looked at this class... whoever added these methods might have though of the greeks with respect to the total basket value---whatever sense this may make. I'll have to see if any engine provides these results. If not, they should probably be redefined. Later, Luigi -- These are my principles, and if you don't like them... Well, I have others. -- Groucho Marx ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Luigi Ballabio wrote:
> In the meantime, you can work your way around it. My suggestion is to > generalize the McBasket class as I sketched above, write the formulas > you need in your PathPricer, and disregard the payoff classes entirely. > To keep it cleaner, you might want to inherit your class(es) from > BasketOption so that their constructor don't take a payoff. Thank you for your answer. I have started working on the MCBasketEngine. I will create a new Payoff implementing the methods I needs and we'll see if it is any good. I think a product should 1) tell the engine on which dates it needs the values of how many underlyings. 2) the mc engine should generate a matrix of that many underlyings on those dates (removing the extra timesteps simulated only for a discretization schemes) and pass it to the product. 3) the product should then return how much it pays on some final date. alternatively one could add 1a) the product tells the engine on which dates it is going to make a payment 2a) add those dates to the dates of step 1) in order to remember a numeraire for each of the dates at step 1a) (those values will be used at step 3a). 3a) return a vector of payments, one for each date announced at step 1a). the engine will then discount those values using the numeraire at step 2a) One should ensure that a "dodgy" payoff is not allowed to see in the future, since it is given the whole path. Maybe it should only be given (for each of the payment dates) the path till there. So that it cannot see into the future. In an equity model where the numeraire is deterministic, maybe step 2a can be postponed at the end, only for non zero payments. As far as I understand, the Payoff is just the mathematical formula to compute the value paid, while the Option has a wider knowledge of dates and other financial matters. > > >> 2) MultiAssetOption has the following methods >> >> Real delta() const; >> Real gamma() const; >> Real vega() const; >> Real dividendRho() const; >> >> which in my opinion should return Arrays or Matrices > > I think so too. Hmm, it's a long time since I looked at this class... > whoever added these methods might have though of the greeks with respect > to the total basket value---whatever sense this may make. I'll have to > see if any engine provides these results. If not, they should probably > be redefined. I was not able to find an example of how those functions are used. I will keep working on it. andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
Re: Help on Multi Asset Options
|
|
On Dec 22, 2007, at 7:28 PM, Andrea wrote: > Thank you for your answer. I have started working on the > MCBasketEngine. > I will create a new Payoff implementing the methods I needs and we'll > see if it is any good. > > I think a product should > > 1) tell the engine on which dates it needs the values of how many > underlyings. True. This can be done in the setupArguments() method of the product by storing the relevant dates in the arguments structure contained in the engine (if you're not yet familiar with how the Instrument and PricingEngine class work together, look at the draft of chapter 2 available at <http://luigi.ballabio.googlepages.com/qlbook> > 2) the mc engine should generate a matrix of that many underlyings on > those dates (removing the extra timesteps simulated only for a > discretization schemes) and pass it to the product. Yes. For this, you can use the MultiPathGenerator class. Given the dates and the dynamics of the underlyings, it will generate a MultiPath instance containing the underlying values. However, you shouldn't pass it to the product, but rather to an instance of a class derived from PathPricer (which the product will instantiate.) > 3) the product should then return how much it pays on some final date. True, with 'product' replaced by 'path pricer'. Let me know how it goes. In the meantime, have a merry Christmas. Luigi ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Luigi Ballabio wrote:
>> 2) the mc engine should generate a matrix of that many underlyings on >> those dates (removing the extra timesteps simulated only for a >> discretization schemes) and pass it to the product. > > Yes. For this, you can use the MultiPathGenerator class. Given the > dates and the dynamics of the underlyings, it will generate a MultiPath > instance containing the underlying values. However, you shouldn't pass > it to the product, but rather to an instance of a class derived from > PathPricer (which the product will instantiate.) > >> 3) the product should then return how much it pays on some final date. > > True, with 'product' replaced by 'path pricer'. Hi, I've just seen only now this email you sent a while ago. I am not sure what you mean. The PathPricer receives the MultiPath, extract the values of the assets on the times requested by the product (the time grind having potentially more dates than the product needs) into some sort of matrix and passes it to the product. The product return (for the time being) one single number, and the PathPricer takes care of discounting it. I want to write only one instance of the PathPricer and many Products/Payoffs. Is it correct? Andrea ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
Re: Help on Multi Asset Options
|
|
On Sun, 2008-03-02 at 20:48 +0000, Andrea wrote:
> The PathPricer receives the MultiPath, extract the values of the > assets on the times requested by the product (the time grind having > potentially more dates than the product needs) into some sort of > matrix and passes it to the product. > The product return (for the time being) one single number, and the > PathPricer takes care of discounting it. > > I want to write only one instance of the PathPricer and many > Products/Payoffs. > > Is it correct? Andrea, just to remove ambiguity, I wouldn't speak of product---that suggests an instance of the Instrument class (and in fact, it got me confused earlier.) Let's use "Payoff" instead. This said: some path pricers happen to use a Payoff instance, but this is not necessarily always the case. True, you could expand the Payoff hierarchy until it becomes some kind of interpreted language (at which point the PathPricer becomes little more than a discounter.) But if you want to express a number of exotic path-dependent payoffs, and if you don't need to specify the formula for your payoff at run-time (in which case you'll have to go for the interpreter, but it's a lot of work) you might be better off if: a) you write a general engine which does the setup, defines an abstract pathPricer() method to instantiate the payoff, and runs the simulation; b) you inherit specific engines which implement pathPricer() by returning a derived PathPricer with the specific formula you need. The path pricer doesn't need to use a Payoff object, mind you: it can just implement the formula itself. Luigi -- Ogden's Law: The sooner you fall behind, the more time you have to catch up. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
«
Return to quantlib-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |