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

[Luigi Ballabio]

On 08/02/2005 06:02:44 AM, Toyin Akin wrote:
> I've been working with QuantLib the last serveral months looking at  
> the possibility of producing a commercial multithreaded .NET engine.
> 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.

Toyin,
        apologies for the delay. I still have some catch-up to do after  
my vacations...

As to the multithreading issue: man, is this a tricky one.

It seems to me that adding an explicit parameter---be it the evaluation  
date, a thread or session ID, or some other kind of settings  
object---would percolate through and pollute too many interfaces. It  
should be added as a parameter to Instrument::NPV(),  
Instrument::calculate(), YieldTermStructure::whatever(),  
Xibor::fixing(), CashFlow::amount()... it is painful just to think of  
it. I would very like prefer that Settings remained globally accessible.

But on the other hand, we should be able to have different threads get  
hold of different Settings instances, otherwise they will either have  
to be serialized (defeating the very purpose of threads) or step on  
each other's toes. A few months ago, Ashish Kulkarni mentioned  
thread-local storage; as far as I can see, it seems an interesting  
possibility---although I'm not sure that we can code it in the library  
directly and in a portable way. Moreover, the library might be called  
from different languages, and they might provide their own thread  
implementation.

At this time, I'm inclined to turn the Singleton class into a Multiton  
and add a hook so that different instances can be requested behind the  
curtains. I'm thinking of an implementation along the lines of:

#if defined(QL_ALLOW_SESSIONS)
Integer sessionId();   // note: declared, but not defined in
                        // the library itself
#endif

T& Singleton<T>::instance() const {
     static std::map<Integer, boost::shared_ptr<T> > instances_;
     #if defined(QL_ALLOW_SESSIONS)
     Integer id = sessionId();
     #else
     Integer id = 0;
     #endif
     boost::shared_ptr<T>& instance = instances_[id];
     if (!instance)
         instances_[id] = instance = boost::shared_ptr<T>(new T);
     return *instance;
}

When QL_ALLOW_SESSIONS is undefined (which would be the default) the  
singleton will work as it does now. However, users wanting to have  
different instances will have the possibility to #define it. In this  
case, they'll have to define their own implementation of sessionId(),  
which will return a different id for different threads, and link it  
with the library. This will give them the possibility to implement  
sessionId() in the most convenient way, e.g., using thread-local  
storage in a C++ application, calling back to Python or Ruby to  
interrogate their thread manager if the library is exported to such  
languages, or doing whatever is necessary in .NET to get a thread id.

Thoughts?

Later,
        Luigi


----------------------------------------

Quote me as saying I was misquoted.
-- Groucho Marx

[Toyin Akin]

Hi,

Yep this is a tricky one!!

The threading idea is an idea, but for most people, you need to code this
extra threading logic
carefully outside of QuantLib. I was under the impression that 'thread-local
storage' was a critical resource, if you build too many objects each needing
their own resources... well I haven't tested it myself, but maybe Ashish
Kulkarni can comment on this.

I seem to remember that there was an explicit Today's Date parameter
associated with the Yieldcurve object within QuantLib 0.3.7. There you had
the setTermStructure()  function within the RateHelpers and the fixing()
function from the Xibor class refering to this YieldCurve Today's date for
reference.

I liked this because the Today's Date parameter did not touch many
interfaces, within QuantLib 0.3.7, all pricing functions refered to this
YieldCurve->TodaysDate for reference somewhere in the bowels of their
implementation. The good news here though was that the TodaysDate parameter
was associated with the YieldCurve object and not passed as an explicit
parameter.

Thus you had a local Today's Date associated with the yieldCurve. Need to
compute Theta? No problem, shift the date within the YieldCurve. No side
effects on other functions or fancy threading.

Why did this TodaysDate parameter vanish from earlier versions of QuantLib?

Thanks for checking-in the BondHelper class (with your modifications).

Best Regards,
Toy out.

>From: Luigi Ballabio <[hidden email]>
>To: Toyin Akin <[hidden email]>
>CC: [hidden email]
>Subject: [Quantlib-users] Re: [Quantlib-dev] Quantlib within a
>multithreaded architecture.
>Date: Fri, 09 Sep 2005 09:47:46 +0000
>
>
>On 08/02/2005 06:02:44 AM, Toyin Akin wrote:
>>I've been working with QuantLib the last serveral months looking at  the
>>possibility of producing a commercial multithreaded .NET engine.
>>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.
>
>Toyin,
> apologies for the delay. I still have some catch-up to do after  my
>vacations...
>
>As to the multithreading issue: man, is this a tricky one.
>
>It seems to me that adding an explicit parameter---be it the evaluation  
>date, a thread or session ID, or some other kind of settings  
>object---would percolate through and pollute too many interfaces. It  
>should be added as a parameter to Instrument::NPV(),  
>Instrument::calculate(), YieldTermStructure::whatever(),  Xibor::fixing(),
>CashFlow::amount()... it is painful just to think of  it. I would very like
>prefer that Settings remained globally accessible.
>
>But on the other hand, we should be able to have different threads get  
>hold of different Settings instances, otherwise they will either have  to
>be serialized (defeating the very purpose of threads) or step on  each
>other's toes. A few months ago, Ashish Kulkarni mentioned  thread-local
>storage; as far as I can see, it seems an interesting  
>possibility---although I'm not sure that we can code it in the library  
>directly and in a portable way. Moreover, the library might be called  from
>different languages, and they might provide their own thread  
>implementation.
>
>At this time, I'm inclined to turn the Singleton class into a Multiton  and
>add a hook so that different instances can be requested behind the  
>curtains. I'm thinking of an implementation along the lines of:
>
>#if defined(QL_ALLOW_SESSIONS)
>Integer sessionId();   // note: declared, but not defined in
>                        // the library itself
>#endif
>
>T& Singleton<T>::instance() const {
>     static std::map<Integer, boost::shared_ptr<T> > instances_;
>     #if defined(QL_ALLOW_SESSIONS)
>     Integer id = sessionId();
>     #else
>     Integer id = 0;
>     #endif
>     boost::shared_ptr<T>& instance = instances_[id];
>     if (!instance)
>         instances_[id] = instance = boost::shared_ptr<T>(new T);
>     return *instance;
>}
>
>When QL_ALLOW_SESSIONS is undefined (which would be the default) the  
>singleton will work as it does now. However, users wanting to have  
>different instances will have the possibility to #define it. In this  case,
>they'll have to define their own implementation of sessionId(),  which will
>return a different id for different threads, and link it  with the library.
>This will give them the possibility to implement  sessionId() in the most
>convenient way, e.g., using thread-local  storage in a C++ application,
>calling back to Python or Ruby to  interrogate their thread manager if the
>library is exported to such  languages, or doing whatever is necessary in
>.NET to get a thread id.
>
>Thoughts?
>
>Later,
> Luigi
>
>
>----------------------------------------
>
>Quote me as saying I was misquoted.
>-- Groucho Marx
>
>
>
>-------------------------------------------------------
>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

[Ferdinando Ametrano-4]

Hi Toyin

>I seem to remember that there was an explicit Today's Date parameter
>associated with the Yieldcurve object within QuantLib 0.3.7.

right

>Thus you had a local Today's Date associated with the yieldCurve. Need to
>compute Theta? No problem, shift the date within the YieldCurve. No side
>effects on other functions or fancy threading.
>Why did this TodaysDate parameter vanish from earlier versions of QuantLib?

one of the reason YieldCurve's TodaysDate disappeared is exactly to have a
more robust day-theta, that is you shift TodaysDate in the Settings and
you'll get the whole effect of day-shifting, including any possible
contributions from those objects you didn't know you had a theta dependence
from

As for the threading problem: Luigi's proposal sounds very very good to me.

ciao -- Nando


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.21/96 - Release Date: 9/10/2005

[Toyin Akin]

Hi Ferdinando,

I'm not against the threading idea, I was just wondering why the change of
design from a local TodaysDate where you had more flexibility of computing
individual Theta components to the global evalDate() functionality. This to
me was a simpler solution to implement than the threading one.

A classic example of this is finding the theta due to discounting cashflows
only (with fixing rates and volatility values unchanged). Or theta due to
fixing rates (vols and discounting remaining constant).

It seemed to me that by changing all the object's TodaysDate you can also
find the global Theta change.

However I agree with you that you can get a more accurate Theta from a
global change because you do not need to track every occurance of where
Theta has an effect, however you lose the local theta flexability.

Because of this funnny global theta-ness it does make sense now to have a
global date parameter (in order to make sure you capture the sum of all
theta components), but only local to the set of objects which are to be
effected by it. From the solution Luigi has proposed (same ID for the
related objects), this seems possible.

Again the 'local thread storage' may be an issue, I read somewhere that it
is an very precious resource and thus within a multiuser environment with
hundreds of users each creating many objects, I'm too too sure if it is
scalable, but I'm not an expert on C++ threading!!

Best Regards,

Toy out.

>From: Ferdinando Ametrano <[hidden email]>
>To: "Toyin Akin" <[hidden email]>
>CC: QuantLib-users <[hidden email]>
>Subject: RE: [Quantlib-users] Quantlib within a multithreaded  
>architecture.
>Date: Sat, 10 Sep 2005 16:45:02 +0200
>
>Hi Toyin
>
>>I seem to remember that there was an explicit Today's Date parameter
>>associated with the Yieldcurve object within QuantLib 0.3.7.
>
>right
>
>>Thus you had a local Today's Date associated with the yieldCurve. Need to
>>compute Theta? No problem, shift the date within the YieldCurve. No side
>>effects on other functions or fancy threading.
>>Why did this TodaysDate parameter vanish from earlier versions of
>>QuantLib?
>
>one of the reason YieldCurve's TodaysDate disappeared is exactly to have a
>more robust day-theta, that is you shift TodaysDate in the Settings and
>you'll get the whole effect of day-shifting, including any possible
>contributions from those objects you didn't know you had a theta dependence
>from
>
>As for the threading problem: Luigi's proposal sounds very very good to me.
>
>ciao -- Nando
>
>
>--
>No virus found in this outgoing message.
>Checked by AVG Anti-Virus.
>Version: 7.0.344 / Virus Database: 267.10.21/96 - Release Date: 9/10/2005
>
>

[Ferdinando Ametrano-4]

Hi Toyin

>However I agree with you that you can get a more accurate Theta from a
>global change because you do not need to track every occurance of where
>Theta has an effect, however you lose the local theta flexability.

my humble opinion is that if you're looking for "local" theta you're better
with the original theta definition: the derivative with respect to time.
When you deal with day-theta, i.e. the effect of moving to tomorrow, to
have a global variable is a safer approach.
Of course your mileage might vary.

Besides this was not the only reason TodaysDate disappeared. Another one
was that to check for your yield and volatility curves having the same
TodaysDate many many times in the library was clunky..

ciao -- Nando


--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.344 / Virus Database: 267.10.21/96 - Release Date: 9/10/2005

[Luigi Ballabio]

On 09/10/2005 10:20:20 AM, Toyin Akin wrote:
>
> Yep this is a tricky one!!
>
> The threading idea is an idea, but for most people, you need to code  
> this extra threading logic carefully outside of QuantLib.

Yes. Thread-local storage was an example---the actual logic would be  
implemented by the user. All I would provide in the library is the hook  
for inserting the logic.

Luigi

----------------------------------------

Every solution breeds new problems.
-- unknown