> Thanks for your inputs.
> I observed a pattern in some exotic options. Correct me if I am wrong.
> Similar to himalayan option, in variance swap engine also we have the
> following code
> MCVarianceSwapEngine(
> const boost::shared_ptr<GeneralizedBlackScholesProcess>& process
>
> Since most of the engines are specifically using
> GeneralizedBlackScholesProcess it's impossible to value the option using any
> other process. Practically a person would like to value the instrument using
> any possible process. After struggling with Merton76Process for valuing
> Himalayan option I tried to get my head around with HestonProcess. It wasn't
> even remotely possible. Yes I could do the same in excel, but again excel
> can't do 9Million simulations which Quantlib can do in seconds :). That's
> why I am trying to replace my excel side of modeling with C++ QuantLib!
>
> So what I want to try is "make the above dependency more generic". It should
> be possible in some way. Any inputs from you guys will help a lot.
>
> Thanks again,
> Animesh Saxena
>
> (
http://quantanalysis.wordpress.com)
> Ph: (+91)9920098221