Re: McSimulation - controlPathPricer and controlPricingEngine

Posted by Toyin Akin-4 on
URL: http://quantlib.414.s1.nabble.com/compiling-with-Dev-C-tp2557p2563.html

Thanks Luigi,

Bravo to you all on the "Engine" architecture.
The calculations seem more centralised rather than a directory full of
pricers.

I do like the MC and Tree code in particular.

Best Regards,
Toyin Akin.

----- Original Message -----
From: "Luigi Ballabio" <[hidden email]>
To: "Toyin Akin" <[hidden email]>;
<[hidden email]>
Sent: Thursday, June 05, 2003 10:18 AM
Subject: Re: [Quantlib-users] McSimulation - controlPathPricer and
controlPricingEngine


>
> Hi Toyin,
>
> At 08:51 AM 6/5/03 +0100, Toyin Akin wrote:
> >I'm currently playing with the McSimulation class and you currently have
2
> >functions defined
> >
> >controlPricingEngine() and controlPathPricer().
> >
> >I understand the need for them, used higher up in the MCEuropeanEngine
> >class, I just don't understand what actually
> >gets returned. Does it always return null, or is it a instance of the
stored

> >"path_pricer_type" in the case of the
> >controlPathPricer() function.
>
> The default behavior is to return null. This can be overridden in derived
> classes. There's still no example of it in the code, though.
>
> >The controlPricingEngine() looks even more baffling as it refers to the
> >abstract base class "PricingEngine" and this
> >function has not been overloaded higher up.
> >
> >I guess the question I am really asking is what does : return
> >Handle<PricingEngine>() actually do!!
> >
> >Forgive me if this is a stupid question. You guys sure know how to use
> >advanced features of templates!!
>
> No, templates are only here to confuse you :) Actually,
>
> Handle<PricingEngine> controlPricingEngine() {
>      return Handle<PricingEngine>();
> }
>
> is only a safe translation of:
>
> PricingEngine* controlPricingEngine() {
>      return 0;
> }
>
> That is, the default behavior is to return no engine. Derived classes can
> override this and return whatever engine they want, upcast to
> PricingEngine; for instance,
>
> Handle<PricingEngine> derivedClass::controlPricingEngine() {
>      return Handle<PricingEngine>(new SuperDuperEngine(foo,bar));
> }
>
> which is the safe equivalent of:
>
> PricingEngine* derivedClass::controlPricingEngine() {
>      return new SuperDuperEngine(foo,bar);
> }
>
> (safe in the sense that you needn't worry who and when is going to
> deallocate the pointer)
>
>
> >Another question, any plans to implement the calculate() function of the
> >FDVanillaEngine?
>
> Yes, but there's no timeframe for that.
>
> Bye,
>          Luigi
>
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by:  Etnus, makers of TotalView, The best
> thread debugger on the planet. Designed with thread debugging features
> you've never dreamed of, try TotalView 6 free at www.etnus.com.
> _______________________________________________
> Quantlib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users