Posted by
animesh on
URL: http://quantlib.414.s1.nabble.com/Himalayan-Option-Worries-tp6914p6917.html
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
>
>
--
Regards,
Animesh Saxena
(
http://quantanalysis.wordpress.com)
Ph: (+91)9920098221
------------------------------------------------------------------------------
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