Re: [Quantlib-dev] Pointer Casting

Posted by animesh on
URL: http://quantlib.414.s1.nabble.com/Himalayan-Option-Worries-tp6914p6918.html

Also another thing I will point out. Maybe you can understand this better.
There is no evolve() method in merton76process.hpp.
So I think even when casting works perfectly as per the below mentioned changes, it can't price as it's trying to build up the path. Not sure why evolve method is not there. Without evolve the merton76process should not work at all for other things too. Am I missing something here?






On 9/1/10 1:10 AM, animesh saxena wrote:

 You are right, It compiled once and now it just gave out BAD_ACCESS error.
Here's what I am trying to do just to get the simulation work. I added the mchimalayanengine.hpp file to my project and changed it, and in my main code I change the header file path to #include "mchimalayanengine.hpp" (My new file).

In this I just changed....the class

        boost::shared_ptr<Merton76Process> process = boost::dynamic_pointer_cast<Merton76Process>(processes_->process(0));
   //     QL_REQUIRE(process, "Black-Scholes process required");

        return boost::shared_ptr<typename MCHimalayaEngine<RNG,S>::path_pricer_type>(new HimalayaMultiPathPricer(arguments_.payoff,process->riskFreeRate()->discount(arguments_.exercise->lastDate())));

Now if I debug the code executes till after this line even with a dynamic cast. I checked that merton76Process has a riskFreeRate method. Now after all this it gives out a SIGABRT error. Still trying to understand why it is so!


On 8/31/10 7:26 PM, Luigi Ballabio wrote:

On Tue, 2010-08-31 at 17:47 +0530, animesh saxena wrote:

I located the error in the code. I think this is probably due to
design.
Generally people would like to price options using different
processes. For example Himalayan Option is priced using BlackScholes
process in the example. When I change it to another process like
Merton76Process (which also is Stochastic1D - as per the guidelines),
I should be able to price it.

Yes, in principle. But while the path generation does work with a
generic process, the McHimalaya path pricer calls a method from the
BlackScholes interface, namely, riskFreeRate().  The method is not in
the Stochastic1D interface, so we need to cast.

The cast is throwing the error.

It should.

  If I change it to "STATIC CAST", the error is gone!
         boost::shared_ptr<GeneralizedBlackScholesProcess>  process =

boost::static_pointer_cast<GeneralizedBlackScholesProcess>(

processes_->process(0));

Honestly, I have no idea why this works. The process you're passing is
not a GeneralizedBlackScholesProcess, so the cast you're forcing should
not succeed.  It might just so happen that the bits align right, but
that's not guaranteed to be portable.

As for a better solution, I'm not sure I have it.  It could be that
instead of an array of Black-Scholes processes, the Himalaya engine
takes a generic process and a discount curve (so it doesn't have to
retrieve the risk-free curve.)

Luigi

------------------------------------------------------------------------------
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