[ANN] QuantLib 0.3.7 released

[Ferdinando Ametrano-3]

QuantLib is a cross-platform, free/open-source quantitative finance C++
library for modeling, pricing, trading, and risk management in real-life.

Version 0.3.7 has been released. See
http://sourceforge.net/project/shownotes.php?group_id=12740&release_id=252500 
for a summary of the changes since version 0.3.6

QuantLib now depends on the Boost library (www.boost.org). You will need
a working Boost installation in order to compile and use QuantLib.
Instructions for installing Boost from sources are available at
<http://www.boost.org/more/getting_started.html>. Pre-packaged binaries
might be available from other sources. Google is your friend (or Debian,
or Fink...)

Furthermore, Python, Ruby, Guile, and MzScheme bindings are available
for QuantLib 0.3.7 as well as an Excel add-in.

Feedback is welcome.

Ferdinando Ametrano

[Toyin Akin]

Hi All,

As some of you may have noticed, I have pulled my CapeTools QuantLib Web
Site. I am in the process of producing a new version which uses the current
QuantLib C++ library, complete with user documentation.

I've been working with QuantLib the last serveral months looking at the
possibility of producing
a commercial multithreaded .NET engine. Basically another layer on top on
QuantLib C++
itself, rather than a total rewrite like I did before.

The previous approach was fine and educational in terms of how QuantLib is
structured, but it was a pain in the neck to keep it up to date with the
pace of development that the QuantLib guys were generating.

With a C# wrapper on top of the C++ framework in which the wrapper itself is
enabled for multi-threaded use as well as other wrappers I am developing for
.NET web services,  .NET remoting
and a full Excel implementation (1000+ Excel functions thus far...), I can
concentrate on these sexy features without the full re-write of QuantLib in
.NET.

The main problem I have found which would prevent this from working within a
multi-threaded environment (Wrapper on top of the C++ layer), are those of
the 3 Singleton classes.

ExchangeRateManager, IndexManager and Settings.

Now that first 2 are not that difficult to overcome as they are used in a
relatively small portion of the QuantLib codebase. The latter class,
Settings, is the problem.

This is used by almost every pricing, YieldCurve class.

Thus if you have the scenario, even within a multithreaded C++ application,
where User A creates a YieldCurve (ie - the PiecewiseFlatForward class,
using the constructor that takes a reference date) with reference date
2/MAR/2005 and User B creates a similar curve with reference date 2/JUN/2006
and both submit the request to a server, the server may strip the curves
correctly, but when the 2 users want to calculate a swap price/rate, you now
have a problem.

The Settings::instance.evaluationDate() function is called to retrieve the
calculation date. But User A wants his at 2/MAR/2005  and UserB at
2/JUN/2006.

You could override the evaluationDate() within the global Settings class in
each case, but then you open up a can of worms because while UserA has set
the Settings::instance.evalutionDate() (either externally, which is not a
good idea, because he is manipulating a global variable) or the programmer
in code within the wrapper swap() function, UserB may come in a split second
later into the same function and change the value again, thus invalidating
the results that UserA will generate.

You could add some sort of mutex within the Wrapper Swap() function to block
the call until UserA has finished (The Swap function will manipulate the
evaluationDate() function), but the locations within the QuantLib library
where Settings::instance.evalutionDate()
are called are too numerous. Thus you would have to write some sort of
critical section, mutex for the whole library or make the quantlib library
single-threaded in use.

This problem is actually not only tied to YieldCurves, almost every pricing
function is affected by this too. Thus anyone who wants to manipulate the
evaluationDate() function within a multithreaded application is asking for
trouble.

However, maybe you guys have a solution for this, or someone has encounted
this and has a solution.

I had the chance on working on a similar library within a commercial bank
for 6 years implementing everything from YieldCurves to the pricing and risk
management of portfolios of CapFloors, Swaps and Swaptions. Also the pricing
of exotic structured deals and I can tell you, the quantLib infrastructure,
apart from CMS Swaps and portfolio and risk management features, contains
nearly everything else that this library had. In addition, you have all the
exotic option calculation as well.

By the way, apart from this singleton issue, I believe that this is the best
library that all financial engineers should look at, if they want to get
their C++ financial skills to up speed in a relatively short space of time.


Best Regards,
Toyin Akin.
CapeTools.

[Gianni Piolanti]

IMHO If you haven't already done it I think you should customize the
singleton class
to support multithreading. Usually a Double-Checked Locking pattern is the
right choice but you have to pay attention to the hardware architecture
also.
As far as Settings::instance.evalutionDate() is concerned a simple idea is
to use the
thread id as the key of an associative map and than overloading the
evaluationDate appropriately
(using the key as a function argument and returning/set the right date).
I hope it helps.

ciao Gianni.

----- Original Message -----
From: "Toyin Akin" <[hidden email]>
To: <[hidden email]>; <[hidden email]>;
<[hidden email]>;
<[hidden email]>
Sent: Tuesday, August 02, 2005 6:02 AM
Subject: [Quantlib-users] Quantlib within a multithreaded architecture.

>
> Hi All,
>
> As some of you may have noticed, I have pulled my CapeTools QuantLib Web
> Site. I am in the process of producing a new version which uses the
> current QuantLib C++ library, complete with user documentation.
>
> I've been working with QuantLib the last serveral months looking at the
> possibility of producing
> a commercial multithreaded .NET engine. Basically another layer on top on
> QuantLib C++
> itself, rather than a total rewrite like I did before.
>
> The previous approach was fine and educational in terms of how QuantLib is
> structured, but it was a pain in the neck to keep it up to date with the
> pace of development that the QuantLib guys were generating.
>
> With a C# wrapper on top of the C++ framework in which the wrapper itself
> is enabled for multi-threaded use as well as other wrappers I am
> developing for .NET web services,  .NET remoting
> and a full Excel implementation (1000+ Excel functions thus far...), I can
> concentrate on these sexy features without the full re-write of QuantLib
> in .NET.
>
> The main problem I have found which would prevent this from working within
> a multi-threaded environment (Wrapper on top of the C++ layer), are those
> of the 3 Singleton classes.
>
> ExchangeRateManager, IndexManager and Settings.
>
> Now that first 2 are not that difficult to overcome as they are used in a
> relatively small portion of the QuantLib codebase. The latter class,
> Settings, is the problem.
>
> This is used by almost every pricing, YieldCurve class.
>
> Thus if you have the scenario, even within a multithreaded C++
> application, where User A creates a YieldCurve (ie - the
> PiecewiseFlatForward class, using the constructor that takes a reference
> date) with reference date 2/MAR/2005 and User B creates a similar curve
> with reference date 2/JUN/2006 and both submit the request to a server,
> the server may strip the curves correctly, but when the 2 users want to
> calculate a swap price/rate, you now have a problem.
>
> The Settings::instance.evaluationDate() function is called to retrieve the
> calculation date. But User A wants his at 2/MAR/2005  and UserB at
> 2/JUN/2006.
>
> You could override the evaluationDate() within the global Settings class
> in each case, but then you open up a can of worms because while UserA has
> set the Settings::instance.evalutionDate() (either externally, which is
> not a good idea, because he is manipulating a global variable) or the
> programmer in code within the wrapper swap() function, UserB may come in a
> split second later into the same function and change the value again, thus
> invalidating the results that UserA will generate.
>
> You could add some sort of mutex within the Wrapper Swap() function to
> block the call until UserA has finished (The Swap function will manipulate
> the evaluationDate() function), but the locations within the QuantLib
> library where Settings::instance.evalutionDate()
> are called are too numerous. Thus you would have to write some sort of
> critical section, mutex for the whole library or make the quantlib library
> single-threaded in use.
>
> This problem is actually not only tied to YieldCurves, almost every
> pricing function is affected by this too. Thus anyone who wants to
> manipulate the evaluationDate() function within a multithreaded
> application is asking for trouble.
>
> However, maybe you guys have a solution for this, or someone has encounted
> this and has a solution.
>
> I had the chance on working on a similar library within a commercial bank
> for 6 years implementing everything from YieldCurves to the pricing and
> risk management of portfolios of CapFloors, Swaps and Swaptions. Also the
> pricing of exotic structured deals and I can tell you, the quantLib
> infrastructure, apart from CMS Swaps and portfolio and risk management
> features, contains nearly everything else that this library had. In
> addition, you have all the exotic option calculation as well.
>
> By the way, apart from this singleton issue, I believe that this is the
> best library that all financial engineers should look at, if they want to
> get their C++ financial skills to up speed in a relatively short space of
> time.
>
>
> Best Regards,
> Toyin Akin.
> CapeTools.
>
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> Quantlib-users mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Toyin Akin]

Hi,

That's one approach, however I think the evaluation date concept is actually
a financial one rather than an IT/computing one and such be implemented
as such.

For example you could have an object that not only encapsulates the
evaluation date but also whether you want to accept any cashflows being paid
today to be part of  your PV or whether this should be moved into a cash
position (discarded).

Currently this is also a global switch for the library. These 2 parameters
can be different on a deal by deal basis. You can imagine other, what are
today, global
variables that can also be placed into the same object if the variable
affects the pricing on a deal by deal level.

This object can be passed into either Pricing or YieldCurve functions to set
the tone for the deal.

These parameters have a financial quantity that are specified by the user,
rather than a C++ architectural one.

I did initially think about the map object route when I discovered the
problem, but if you are going to change all occurances of the
evalutaionDate() function to take in the threadID, you might as well
implement the object described above and use that in it's place. That way,
you don't have to worry about threads on different platforms as well as the
user being able to specify these currently global variables on a deal by
deal level.

Toy out.

>From: "Gianni Piolanti" <[hidden email]>
>To: "Toyin Akin"
><[hidden email]>,<[hidden email]>,<[hidden email]>,<[hidden email]>,<[hidden email]>
>Subject: Re: [Quantlib-users] Quantlib within a multithreaded architecture.
>Date: Sun, 7 Aug 2005 00:16:25 +0200
>
>IMHO If you haven't already done it I think you should customize the
>singleton class
>to support multithreading. Usually a Double-Checked Locking pattern is the
>right choice but you have to pay attention to the hardware architecture
>also.
>As far as Settings::instance.evalutionDate() is concerned a simple idea is
>to use the
>thread id as the key of an associative map and than overloading the
>evaluationDate appropriately
>(using the key as a function argument and returning/set the right date).
>I hope it helps.
>
>ciao Gianni.
>
>----- Original Message ----- From: "Toyin Akin" <[hidden email]>
>To: <[hidden email]>; <[hidden email]>;
><[hidden email]>;
><[hidden email]>
>Sent: Tuesday, August 02, 2005 6:02 AM
>Subject: [Quantlib-users] Quantlib within a multithreaded architecture.
>
>
>>
>>Hi All,
>>
>>As some of you may have noticed, I have pulled my CapeTools QuantLib Web
>>Site. I am in the process of producing a new version which uses the
>>current QuantLib C++ library, complete with user documentation.
>>
>>I've been working with QuantLib the last serveral months looking at the
>>possibility of producing
>>a commercial multithreaded .NET engine. Basically another layer on top on
>>QuantLib C++
>>itself, rather than a total rewrite like I did before.
>>
>>The previous approach was fine and educational in terms of how QuantLib is
>>structured, but it was a pain in the neck to keep it up to date with the
>>pace of development that the QuantLib guys were generating.
>>
>>With a C# wrapper on top of the C++ framework in which the wrapper itself
>>is enabled for multi-threaded use as well as other wrappers I am
>>developing for .NET web services,  .NET remoting
>>and a full Excel implementation (1000+ Excel functions thus far...), I can
>>concentrate on these sexy features without the full re-write of QuantLib
>>in .NET.
>>
>>The main problem I have found which would prevent this from working within
>>a multi-threaded environment (Wrapper on top of the C++ layer), are those
>>of the 3 Singleton classes.
>>
>>ExchangeRateManager, IndexManager and Settings.
>>
>>Now that first 2 are not that difficult to overcome as they are used in a
>>relatively small portion of the QuantLib codebase. The latter class,
>>Settings, is the problem.
>>
>>This is used by almost every pricing, YieldCurve class.
>>
>>Thus if you have the scenario, even within a multithreaded C++
>>application, where User A creates a YieldCurve (ie - the
>>PiecewiseFlatForward class, using the constructor that takes a reference
>>date) with reference date 2/MAR/2005 and User B creates a similar curve
>>with reference date 2/JUN/2006 and both submit the request to a server,
>>the server may strip the curves correctly, but when the 2 users want to
>>calculate a swap price/rate, you now have a problem.
>>
>>The Settings::instance.evaluationDate() function is called to retrieve the
>>calculation date. But User A wants his at 2/MAR/2005  and UserB at
>>2/JUN/2006.
>>
>>You could override the evaluationDate() within the global Settings class
>>in each case, but then you open up a can of worms because while UserA has
>>set the Settings::instance.evalutionDate() (either externally, which is
>>not a good idea, because he is manipulating a global variable) or the
>>programmer in code within the wrapper swap() function, UserB may come in a
>>split second later into the same function and change the value again, thus
>>invalidating the results that UserA will generate.
>>
>>You could add some sort of mutex within the Wrapper Swap() function to
>>block the call until UserA has finished (The Swap function will manipulate
>>the evaluationDate() function), but the locations within the QuantLib
>>library where Settings::instance.evalutionDate()
>>are called are too numerous. Thus you would have to write some sort of
>>critical section, mutex for the whole library or make the quantlib library
>>single-threaded in use.
>>
>>This problem is actually not only tied to YieldCurves, almost every
>>pricing function is affected by this too. Thus anyone who wants to
>>manipulate the evaluationDate() function within a multithreaded
>>application is asking for trouble.
>>
>>However, maybe you guys have a solution for this, or someone has encounted
>>this and has a solution.
>>
>>I had the chance on working on a similar library within a commercial bank
>>for 6 years implementing everything from YieldCurves to the pricing and
>>risk management of portfolios of CapFloors, Swaps and Swaptions. Also the
>>pricing of exotic structured deals and I can tell you, the quantLib
>>infrastructure, apart from CMS Swaps and portfolio and risk management
>>features, contains nearly everything else that this library had. In
>>addition, you have all the exotic option calculation as well.
>>
>>By the way, apart from this singleton issue, I believe that this is the
>>best library that all financial engineers should look at, if they want to
>>get their C++ financial skills to up speed in a relatively short space of
>>time.
>>
>>
>>Best Regards,
>>Toyin Akin.
>>CapeTools.
>>
>>
>>
>>
>>-------------------------------------------------------
>>SF.Net email is Sponsored by the Better Software Conference & EXPO
>>September 19-22, 2005 * San Francisco, CA * Development Lifecycle
>>Practices
>>Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>>Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>>_______________________________________________
>>Quantlib-users mailing list
>>[hidden email]
>>https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>