Posted by
andrea-110 on
URL: http://quantlib.414.s1.nabble.com/Help-on-Multi-Asset-Options-tp11751p11753.html
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