Posted by
Toyin Akin-4 on
URL: http://quantlib.414.s1.nabble.com/compiling-with-Dev-C-tp2557p2562.html
Hi all,
Actually this problem is true for the QuantLib.NET version and not the C++
and it does seem that
thanks to STL, you do indeed find the nearest point.
Toyin Akin.
----- Original Message -----
From: "Toyin Akin" <
[hidden email]>
To: <
[hidden email]>; "Luigi Ballabio"
<
[hidden email]>
Sent: Saturday, June 14, 2003 3:45 PM
Subject: Binomial constructors...
>
> 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
> >
>