Specifics of Himalayan Option

[Andreas Spengler-2]

Hi,

regarding the description of the Himalayan Option,

"The payoff of a Himalaya option is computed in the following way: Given a
basket of N assets, and N time periods, at the end of each period the
option who performed the best is added to the average and then discarded
from the basket. At the end of the N, periods the option pays the max
between the strike and the average of the best performers."

I have some questions regarding that:

- What exactly does "performed the best" mean? Relative to the starting
value? Relative to the value at the end of the preceding period?
- Is the relative performance or the absolute value at the fixing dates
added to the running average?
- In conjunction with the above, would I have to specify an absolute
strike or a relative strike (e.g. 104%)?

Thanks for any help,

Andreas



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Marcin Pawlik]

2009/12/17 Andreas Spengler <[hidden email]>:

> regarding the description of the Himalayan Option,
>
> "The payoff of a Himalaya option is computed in the following way: Given a
> basket of N assets, and N time periods, at the end of each period the
> option who performed the best is added to the average and then discarded
> from the basket. At the end of the N, periods the option pays the max
> between the strike and the average of the best performers."
>
> I have some questions regarding that:
>
> - What exactly does "performed the best" mean? Relative to the starting
> value?
> Relative to the value at the end of the preceding period?

I think that relative to the starting value is a more common solution.


> - Is the relative performance or the absolute value at the fixing dates
> added to the running average?

Performance.


> - In conjunction with the above, would I have to specify an absolute
> strike or a relative strike (e.g. 104%)?

Relative one.

Take a look:
http://www.global-derivatives.com/index.php/pricing-models-topmenu-37/49?task=view
http://www.classiccmp.org/transputer/finengineer/%5BRisk%20Magazine,%20Overhaus%5D%20Himalaya%20Options.pdf

Marcin

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Andreas Spengler-2]

Hi Marcin,

thanks for your quick response; would the below also hold for the
QuantLib implementation?

Rgds,

Andreas

Am 17.12.2009 19:30, schrieb Marcin Pawlik:

> 2009/12/17 Andreas Spengler<[hidden email]>:
>
>> regarding the description of the Himalayan Option,
>>
>> "The payoff of a Himalaya option is computed in the following way: Given a
>> basket of N assets, and N time periods, at the end of each period the
>> option who performed the best is added to the average and then discarded
>> from the basket. At the end of the N, periods the option pays the max
>> between the strike and the average of the best performers."
>>
>> I have some questions regarding that:
>>
>> - What exactly does "performed the best" mean? Relative to the starting
>> value?
>> Relative to the value at the end of the preceding period?
>
> I think that relative to the starting value is a more common solution.
>
>
>> - Is the relative performance or the absolute value at the fixing dates
>> added to the running average?
>
> Performance.
>
>
>> - In conjunction with the above, would I have to specify an absolute
>> strike or a relative strike (e.g. 104%)?
>
> Relative one.
>
> Take a look:
> http://www.global-derivatives.com/index.php/pricing-models-topmenu-37/49?task=view
> http://www.classiccmp.org/transputer/finengineer/%5BRisk%20Magazine,%20Overhaus%5D%20Himalaya%20Options.pdf
>
> Marcin

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Marcin Pawlik]

2009/12/17 Andreas Spengler <[hidden email]>:
> Hi Marcin,
>
> thanks for your quick response; would the below also hold for the
> QuantLib implementation?

Yes. QuantLib defines Himalaya Option as having relative strike and
averaging performances relative to the starting time.
Look at: ql/pricingengines/basket/mchimalayaengine.cpp.

M.

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Thu, 2009-12-17 at 22:07 +0100, Marcin Pawlik wrote:
> 2009/12/17 Andreas Spengler <[hidden email]>:
> > Hi Marcin,
> >
> > thanks for your quick response; would the below also hold for the
> > QuantLib implementation?
>
> Yes. QuantLib defines Himalaya Option as having relative strike and
> averaging performances relative to the starting time.
> Look at: ql/pricingengines/basket/mchimalayaengine.cpp.

Looking at the code, the engine is using performances (relative to the
starting value) to choose the best assets, but then it adds the absolute
price to the running average, so you'd need an absolute strike.  If I'm
not mistaken, though, you can use a relative strike if you setup the
underlying processes so that the starting value is 1.0 for each of them
(since in that case, the price equals the performance.)

Luigi


--

I have yet to see any problem, however complicated, which, when you
looked at it in the right way, did not become still more complicated.
-- Poul Anderson



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Marcin Pawlik]

2009/12/18 Luigi Ballabio <[hidden email]>:

> Looking at the code, the engine is using performances (relative to the
> starting value) to choose the best assets, but then it adds the absolute
> price to the running average, so you'd need an absolute strike.  If I'm
> not mistaken, though, you can use a relative strike if you setup the
> underlying processes so that the starting value is 1.0 for each of them
> (since in that case, the price equals the performance.)

Yes. I was mistaken. I misread lines 48-50 in the mchimalayaengine.cpp.

I think that in the solution you propose one has to normalize not only
the starting value but the strikes in the volatility surface as well.
Of course if the underlying process is built with a surface and not
some other vol structure (atm or constant).

Otherwise one can get rid of lines 40 and 49 and replace "bestPrice"
in line 55 with "bestYield".

I'm not sure if I'm a proper person to suggest it but maybe we (me?
someone else?) could adjust the himalaya engine and the himalaya
option so that both types of payout determination (relative and
absolute strike) are covered? What do you think?

Marcin

------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Luigi Ballabio]

On Fri, 2009-12-18 at 18:37 +0100, Marcin Pawlik wrote:
> 2009/12/18 Luigi Ballabio <[hidden email]>:
> > If I'm not mistaken, though, you can use a relative strike if you setup the
> > underlying processes so that the starting value is 1.0 for each of them
> > (since in that case, the price equals the performance.)
>
> Yes. I was mistaken. I misread lines 48-50 in the mchimalayaengine.cpp.
>
> I think that in the solution you propose one has to normalize not only
> the starting value but the strikes in the volatility surface as well.

Ouch--you're right.

> Otherwise one can get rid of lines 40 and 49 and replace "bestPrice"
> in line 55 with "bestYield".

Yes, at this time that's what I'd suggest Andreas to do.

> I'm not sure if I'm a proper person to suggest it but maybe we (me?
> someone else?) could adjust the himalaya engine and the himalaya
> option so that both types of payout determination (relative and
> absolute strike) are covered? What do you think?

I think we should.  In the meantime, I guess I better put Himalaya
options in the experimental tree before release 1.0.
Are you willing to have a go at the implementation?

Later,
        Luigi


--

Call on God, but row away from the rocks.
-- Indian proverb



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Andreas Spengler-2]

Luigi Ballabio wrote

> In the meantime, I guess I better put Himalaya options in the
> experimental tree before release 1.0.

Not necessary from my point of view... ;-)

> Are you willing to have a go at the implementation?

I am in the middle of adapting the Himalayan (and Rainbow option, btw) to
a project I am currently doing. It would include the ability to include
past observations in the form of a Matrix as well as interim averaging
between fixings.

However, I have yet to arrange with the project sponsor that the changes
can be given back to QL...

Rgds,

Andreas



------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev 
_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users