Posted by
Toyin Akin-4 on
URL: http://quantlib.414.s1.nabble.com/compiling-with-Dev-C-tp2557p2561.html
Hi guys,
I noticed that the binomial tree pricers all have constructors defined with
a (end, step) pair.
However it is possible to define an array of dates when pricing bermudan
deals (VanillaOption constructor)
and because of the way the binomial tree constructors define the steps
internally (dt = end/steps), there is no guarantee that
the bermudan dates (or stopping times ) will fall on the points defined by
the tree, hence causing errors within the
pricing of such deals. The TimeGrid->FindIndex() function then fails.
Perhaps an extra binomial constructor passing in the stoppingtimes along
with the number of points required is needed.
Or the FindIndex() finds the nearest point to it.
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
>