compiling with Dev-C++

[Fierli Francesco]

Good morning,

I am a PhD student and I am trying to use QuantLib. The development
environment is Dev-C++ in a windows XP machine. Bloodshed Dev-C++ uses
Mingw (or Cygwin) port of GNU compiler collection as it's compiler
(GCC-based compiler).
I installed the file QuantLib-0.3.1-full-inst.exe and modified some
compilers options in order to make the new folder readable.
I started with European option example, but my compiler is not able to
compile. From the errors it seems that the complier is not supported.

How can I work out the problem?

Thanks a lot,

francesco

[Luigi Ballabio-2]

At 10:51 AM 5/21/03 +0200, Francesco Fierli wrote:

>I am a PhD student and I am trying to use QuantLib. The development
>environment is Dev-C++ in a windows XP machine. Bloodshed Dev-C++ uses
>Mingw (or Cygwin) port of GNU compiler collection as it's compiler
>(GCC-based compiler).
>I installed the file QuantLib-0.3.1-full-inst.exe and modified some
>compilers options in order to make the new folder readable.
>I started with European option example, but my compiler is not able to
>compile. From the errors it seems that the complier is not supported.
>
>How can I work out the problem?

Francesco,
         first of all, I think you'll have to recompile the whole library
as well---the binaries included in the full installer are compiled for
Visual C++. I think your best bet is to open a cygwin shell, go into the
base QuantLib directory, and run ./configure. After that, you should be
able to compile if you add -DHAVE_CONFIG_H to the compiler options.

Good luck, and do come back if there's other problems.

Ciao,
         Luigi

[Toyin Akin-4]

Hi guys,

Long time...

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

Another question, any plans to implement the calculate() function of the
FDVanillaEngine?

Best Regards,
Toyin Akin.

[Luigi Ballabio-2]

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

[Toyin Akin-4]

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

[Toyin Akin-4]

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
>

[Toyin Akin-4]

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