Posted by
animesh on
URL: http://quantlib.414.s1.nabble.com/Himalayan-Option-Worries-tp6914p6922.html
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
On 9/1/10 5:09 PM, Kakhkhor Abdijalilov wrote:
> static_pointer_cast on smart pointer will perform static_cast on the
> contained pointer. static_cast will never fail at compiler time
> (unless you try to cast away qualifiers such as const or volatile).
> But if the conversion is illegal, the code will fail at runtime.
> dynamic_cast will check at compile time if the pointer is being
> downcast. If target is not inherited from the source, dynamic_cast
> will refuse to compile.
>
> static_cast cast is faster then dynamic_cast, but inherently unsafe.
> In the above example it is used not in performance critical place.
>
> Hope it help.
>
> ------------------------------------------------------------------------------
> This SF.net Dev2Dev email is sponsored by:
>
> Show off your parallel programming skills.
> Enter the Intel(R) Threading Challenge 2010.
>
http://p.sf.net/sfu/intel-thread-sfd> _______________________________________________
> QuantLib-users mailing list
>
[hidden email]
>
https://lists.sourceforge.net/lists/listinfo/quantlib-users>
------------------------------------------------------------------------------
This SF.net Dev2Dev email is sponsored by:
Show off your parallel programming skills.
Enter the Intel(R) Threading Challenge 2010.
http://p.sf.net/sfu/intel-thread-sfd_______________________________________________
QuantLib-users mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-users