quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [13079] trunk/QuantLib

[Luigi B. <lui...@gm...>]

On Thu, 2007-10-18 at 01:34 -0700, cdu...@us...
wrote:
> Revision: 13079
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=13079&view=rev
> Log Message:
> -----------
> Work in progress with SabrVolSurface.

A quick note (not addressed to you, Cristina: this commit is ok, since
it is part of the volatility refactoring already underway on the trunk).

If you're about to undertake a task that is likely to span a number of
"work in progress" commits over several days, please consider creating a
development branch and merging to trunk the code once it's completed.
This is good practice in general, and especially so now that we're
nearing the creation of a release branch---for that, I'd like the trunk
not to contain half-completed work.

Thanks,
	Luigi


-- 

If I do not want others to quote me, I do not speak. 
-- Phil Wayne 

[Quantlib-dev] [ quantlib-Bugs-1812671 ] Examples failed due to blackconstantvol.hpp update

[SourceForge.net <no...@so...>]

Bugs item #1812671, was opened at 2007-10-13 05:32
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1812671&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Examples failed due to blackconstantvol.hpp update

Initial Comment:
In the Example EquityOption, `QuantLib::BlackConstantVol::BlackConstantVol can't find the corresponding prototype after adding the calender as an extra parameter. 

It also happened in other examples.



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

Comment By: Luigi Ballabio (lballabio)
Date: 2007-10-15 16:33

Message:
Logged In: YES 
user_id=75450
Originator: NO

The bug is now fixed in CVS.
Thank you for the report.


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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1812671&group_id=12740

[Quantlib-dev] [ quantlib-Bugs-1812840 ] Examples failed due to blackconstantvol.hpp update

[SourceForge.net <no...@so...>]

Bugs item #1812840, was opened at 2007-10-13 15:39
Message generated for change (Settings changed) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1812840&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Deleted
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Examples failed due to blackconstantvol.hpp update

Initial Comment:
In the Example EquityOption, `QuantLib::BlackConstantVol::BlackConstantVol can't find the corresponding prototype after adding the calender as an extra parameter. 

It also happened in other examples.



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1812840&group_id=12740

Re: [Quantlib-dev] C++ help needed: singleton.hpp

[Klaus S. <kl...@sp...>]

Hi

I'm having this problem using Visual Studio Express 2005.

I nailed it down to a 15 line program (attached to this email), which 
generates to wrong results when compiled within a separate Visual Studio 
solution _and_ the option

Common Language Runtime-Support (/clr)

is switched on. Everything is okay as soon as I'm switching this option off or 
declaring 

inline T& Singleton<T>::instance() { ..}

instead of 

T& Singleton<T>::instance() { }


cheers

-- 
Klaus Spanderen
Ludwig Erhard Str. 12
48734 Reken (Germany)
EMail: kl...@NO... (remove NOSPAM from the address)

[Quantlib-dev] [ quantlib-Bugs-1812840 ] Examples failed due to blackconstantvol.hpp update

[SourceForge.net <no...@so...>]

Bugs item #1812840, was opened at 2007-10-13 06:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1812840&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Examples failed due to blackconstantvol.hpp update

Initial Comment:
In the Example EquityOption, `QuantLib::BlackConstantVol::BlackConstantVol can't find the corresponding prototype after adding the calender as an extra parameter. 

It also happened in other examples.



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1812840&group_id=12740

[Quantlib-dev] [ quantlib-Bugs-1812671 ] Examples failed due to blackconstantvol.hpp update

[SourceForge.net <no...@so...>]

Bugs item #1812671, was opened at 2007-10-12 20:32
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1812671&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Examples failed due to blackconstantvol.hpp update

Initial Comment:
In the Example EquityOption, `QuantLib::BlackConstantVol::BlackConstantVol can't find the corresponding prototype after adding the calender as an extra parameter. 

It also happened in other examples.



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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1812671&group_id=12740

[Quantlib-dev] Finite Difference with Boundary Fixing

[Kuan-Khoon T. <kt...@en...>]

Hi,

I am new both to c++ and QL.
Recently, I completed a project on solving the BS for Vanilla American 
put using boundary fixing, ie use S=s-p0, where s is stock price and p0 
is exercise boundary, thereby fixing 0<S<Inf. The resulting equations is 
non-linear (will be linearised for numerical purpose) and will have 
time/S dependent coeffs even for const sigma and r.

I did it using MATLAB, now I am learning c++ so I was thinking of 
implementing it in QL as a practice.

My initial framework are as follows:

Construct a new FDBFAmericanEngine class, derived in much the same way 
as how FDEuropeanEngine is derived from its bases.

For this class, I provide member functions tranformOperator and 
transformBoundaryConditions.

I will also have the calculate() member function very much similar to 
the one in FDEuropeanEngine, with the exception that I will be calling 
rollback multiple times and calling both tranformOperator() and 
transformBoundaryConditions() just prior to that.

I am still writing the code now but I will like to hear if there are any 
comments, esp if this will work and is there a better way to do it for 
future flexibility.

Thanks!

Kuan

Re: [Quantlib-dev] Credit curves

[Simon I. <s.i...@gm...>]

Luigi,

Any further notice on this? If anyone is developing this at present, I'll
wait a bit for a well thought out base class interface - but sometimes it's
best just to go with a simple one.
The simplest (I feel) would be one with the basic functions:

virtual QL_Real NpvNoDefault(const Cashflow& Payment, const Date& StartDate,
const Date& EndDate) const = 0;
virtual QL_Real NpvGivenDefault(const Cashflow& Payment, const Date&
StartDate, const Date& EndDate) const = 0;

You might also want to add another parameter that makes explicit whether a
default on the end date is included.

This interface allows for stochastic default-intensity and stochastic
interest-rates. I've not worked with firm-value models, so don't know how
this interface would hold up. It also specialises for single-name credit -
multiple names would require a different interface (e.g. expected remaining
notional for an ITraxx curve).

However, if anyone is working on this and has a better concept, please let
me know...

Simon



On 9/26/07, Luigi Ballabio <lui...@gm...> wrote:
>
> On Wed, 2007-09-26 at 14:18 +0100, Simon Ibbotson wrote:
> > Hi, is there any developer out there planning to contribute a CDS /
> > bond curves (using reduced form approach)? I wouldn't want to
> > duplicate any work.
>
> There might be a contribution shortly. I don't think that it uses
> reduced form approach, but it should at least define a base interface
> for the default-probability curve. I'll get back as soon as I know for
> sure.
>
> Luigi
>
>
> --
>
> Use every man after his desert, and who shall scape whipping?
> -- Hamlet, Act II, scene II
>
>
>

Re: [Quantlib-dev] Yield Curve Boostraping Improvements

[<fho...@gm...>]

Hi!
In a case like this a look at scholar.google.com is strongly recommended.
There one finds under Appl. Math. Fin., Vol. 13, No. 2, 89-129 the correct reference to the already published paper.

Rgds
Frank

-------- Original-Nachricht --------
> Datum: Tue, 9 Oct 2007 04:31:37 -0700 (PDT)
> Von: newbie73 <lui...@av...>
> An: qua...@li...
> Betreff: Re: [Quantlib-dev] Yield Curve Boostraping Improvements

> 
> Is the Hagan-West paper titled, "Interpolation Methods for Curve
> Construction" ?  If so, then I just printed a copy of it last week.  As
> far
> as the method I referred to in my earlier post, it is not published
> publicly.  It was written as internal research at Lehman Brothers in the
> late 80s, so I have an older printed photocopy laying around that I used
> as
> a reference.
> 
> - Luis
> 
> 
> 
> Bianchetti Marco-2 wrote:
> > 
> > Yes, I confirm the Hagan-West paper as a key reference.
> > Luis, is the method you mention published somewhere ?
> > Ciao
> > Marco
> >  
> > 
> > 	-----Original Message-----
> > 	From: qua...@li...
> > [mailto:qua...@li...] On Behalf Of Simon
> > Ibbotson
> > 	Sent: 02 October 2007 15:03
> > 	To: newbie73
> > 	Cc: qua...@li...
> > 	Subject: Re: [Quantlib-dev] Yield Curve Boostraping Improvements
> > 	
> > 	
> > 	You might want to examine the paper by Hagan&West on smooth
> > yieldcurve construction. Their convex monotone spline method gives great
> > results.
> > 	 
> > 	Simon
> > 
> > 
> > 	 
> > 	On 10/2/07, newbie73 <lui...@av...> wrote: 
> > 
> > 
> > 		The choppy forward curves appear regardless of which
> > interpolation method is
> > 		used.  The term structure of 3m or 6m forward rates
> > results in a saw-tooth 
> > 		term structure which deviates from market by huge
> > amounts.
> > 		
> > 		Regarding the knot points, I was referring to picking
> > maturities that do not
> > 		necessarily correspond with the chosen instruments.  The
> > methodology we use 
> > 		here treats the area between each knot point as its own
> > curve (or curve
> > 		function), so you end up with many separate curves which
> > segment the yield
> > 		curve which are then combined to ensure smooth forward
> > curve generation. 
> > 		
> > 		The technique itself is quite old and was developed by
> > Lehman in the late
> > 		80s, but works well in most cases I've encountered.
> > 		
> > 		- Luis
> > 		
> > 		
> > 		Luigi Ballabio wrote:
> > 		>
> > 		> On Mon, 2007-10-01 at 07:20 -0700, newbie73 wrote: 
> > 		>
> > 		>> So far I've been quite happy with the functionality
> > in the QuantLib
> > 		>> library - I'd like to start using it to compare to
> > market pricing.
> > 		>> I've found that the curve stripping methodology
> > produces extremely 
> > 		>> jagged forward curves which result in poor pricing of
> > several market
> > 		>> structures.
> > 		>
> > 		> Does this depend on the chosen interpolation?
> > 		>
> > 		>> Also, some algorithmic help in dynamically selecting
> > knot points would be 
> > 		>> much appreciated as well.  The basic idea is the
> > creation of a smooth
> > 		>> interpolation method for a selected set of knot
> > points for a given curve.
> > 		>
> > 		> "Selecting knot points" as in "choosing which
> > instruments to use among 
> > 		> the available ones" (which is what Nando referred to)
> > or as in "choosing
> > 		> a set of knots freely, i.e., not necessarily
> > corresponding to instrument
> > 		> maturities"?
> > 		>
> > 		> Later, 
> > 		>       Luigi
> > 		>
> > 		>
> > 		> --
> > 		>
> > 		> This gubblick contains many nonsklarkish English
> > flutzpahs, but the
> > 		> overall pluggandisp can be glorked from context.
> > 		> -- David Moser
> > 		>
> > 		>
> > 		>
> > 		>
> > ------------------------------------------------------------------------
> > -
> > 		> This SF.net email is sponsored by: Microsoft
> > 		> Defy all challenges. Microsoft(R) Visual Studio 2005.
> > 		>
> > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> > 		> _______________________________________________
> > 		> QuantLib-dev mailing list
> > 		> Qua...@li... 
> > 		>
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> > 		>
> > 		>
> > 		
> > 		--
> > 		View this message in context:
> > http://www.nabble.com/Yield-Curve-Boostraping-Improvements-tf4548647.htm
> > l#a12997264
> > 		Sent from the quantlib-dev mailing list archive at
> > Nabble.com.
> > 		
> > 		
> > 	
> > ------------------------------------------------------------------------
> > - 
> > 		This SF.net email is sponsored by: Microsoft
> > 		Defy all challenges. Microsoft(R) Visual Studio 2005.
> > 		http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ 
> > 		_______________________________________________
> > 		QuantLib-dev mailing list
> > 		Qua...@li...
> > 	
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> > 		
> > 
> > 
> > 
> >
> -------------------------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems?  Stop.
> > Now Search log events and configuration files using AJAX and a browser.
> > Download your FREE copy of Splunk now >> http://get.splunk.com/
> > _______________________________________________
> > QuantLib-dev mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> > 
> > 
> 
> -- 
> View this message in context:
> http://www.nabble.com/Yield-Curve-Boostraping-Improvements-tf4548647.html#a13113782
> Sent from the quantlib-dev mailing list archive at Nabble.com.
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

-- 
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! 
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer

Re: [Quantlib-dev] Yield Curve Boostraping Improvements

[newbie73 <lui...@av...>]

Is the Hagan-West paper titled, "Interpolation Methods for Curve
Construction" ?  If so, then I just printed a copy of it last week.  As far
as the method I referred to in my earlier post, it is not published
publicly.  It was written as internal research at Lehman Brothers in the
late 80s, so I have an older printed photocopy laying around that I used as
a reference.

- Luis



Bianchetti Marco-2 wrote:
> 
> Yes, I confirm the Hagan-West paper as a key reference.
> Luis, is the method you mention published somewhere ?
> Ciao
> Marco
>  
> 
> 	-----Original Message-----
> 	From: qua...@li...
> [mailto:qua...@li...] On Behalf Of Simon
> Ibbotson
> 	Sent: 02 October 2007 15:03
> 	To: newbie73
> 	Cc: qua...@li...
> 	Subject: Re: [Quantlib-dev] Yield Curve Boostraping Improvements
> 	
> 	
> 	You might want to examine the paper by Hagan&West on smooth
> yieldcurve construction. Their convex monotone spline method gives great
> results.
> 	 
> 	Simon
> 
> 
> 	 
> 	On 10/2/07, newbie73 <lui...@av...> wrote: 
> 
> 
> 		The choppy forward curves appear regardless of which
> interpolation method is
> 		used.  The term structure of 3m or 6m forward rates
> results in a saw-tooth 
> 		term structure which deviates from market by huge
> amounts.
> 		
> 		Regarding the knot points, I was referring to picking
> maturities that do not
> 		necessarily correspond with the chosen instruments.  The
> methodology we use 
> 		here treats the area between each knot point as its own
> curve (or curve
> 		function), so you end up with many separate curves which
> segment the yield
> 		curve which are then combined to ensure smooth forward
> curve generation. 
> 		
> 		The technique itself is quite old and was developed by
> Lehman in the late
> 		80s, but works well in most cases I've encountered.
> 		
> 		- Luis
> 		
> 		
> 		Luigi Ballabio wrote:
> 		>
> 		> On Mon, 2007-10-01 at 07:20 -0700, newbie73 wrote: 
> 		>
> 		>> So far I've been quite happy with the functionality
> in the QuantLib
> 		>> library - I'd like to start using it to compare to
> market pricing.
> 		>> I've found that the curve stripping methodology
> produces extremely 
> 		>> jagged forward curves which result in poor pricing of
> several market
> 		>> structures.
> 		>
> 		> Does this depend on the chosen interpolation?
> 		>
> 		>> Also, some algorithmic help in dynamically selecting
> knot points would be 
> 		>> much appreciated as well.  The basic idea is the
> creation of a smooth
> 		>> interpolation method for a selected set of knot
> points for a given curve.
> 		>
> 		> "Selecting knot points" as in "choosing which
> instruments to use among 
> 		> the available ones" (which is what Nando referred to)
> or as in "choosing
> 		> a set of knots freely, i.e., not necessarily
> corresponding to instrument
> 		> maturities"?
> 		>
> 		> Later, 
> 		>       Luigi
> 		>
> 		>
> 		> --
> 		>
> 		> This gubblick contains many nonsklarkish English
> flutzpahs, but the
> 		> overall pluggandisp can be glorked from context.
> 		> -- David Moser
> 		>
> 		>
> 		>
> 		>
> ------------------------------------------------------------------------
> -
> 		> This SF.net email is sponsored by: Microsoft
> 		> Defy all challenges. Microsoft(R) Visual Studio 2005.
> 		>
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 		> _______________________________________________
> 		> QuantLib-dev mailing list
> 		> Qua...@li... 
> 		>
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 		>
> 		>
> 		
> 		--
> 		View this message in context:
> http://www.nabble.com/Yield-Curve-Boostraping-Improvements-tf4548647.htm
> l#a12997264
> 		Sent from the quantlib-dev mailing list archive at
> Nabble.com.
> 		
> 		
> 	
> ------------------------------------------------------------------------
> - 
> 		This SF.net email is sponsored by: Microsoft
> 		Defy all challenges. Microsoft(R) Visual Studio 2005.
> 		http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ 
> 		_______________________________________________
> 		QuantLib-dev mailing list
> 		Qua...@li...
> 	
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 		
> 
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> 
> 

-- 
View this message in context: http://www.nabble.com/Yield-Curve-Boostraping-Improvements-tf4548647.html#a13113782
Sent from the quantlib-dev mailing list archive at Nabble.com.

Re: [Quantlib-dev] System interface

[Simon I. <s.i...@gm...>]

DQpjbGFzcyBFeGFtcGxlSW5zdHJ1bWVudCA6IHB1YmxpYyBJbnN0cnVtZW50DQp7DQpwdWJsaWM6
DQoJRXhhbXBsZUluc3RydW1lbnQohSk7IC8vISBTdGFuZGFyZCBDb25zdHJ1Y3Rvcg0KICAgIEV4
YW1wbGVJbnN0cnVtZW50KGNvbnN0IEV4YW1wbGVJbnN0cnVtZW50OjpUZXJtc2hlZXQmIFRyYWRl
c2hlZXQsIC8vITwgSW5mb3JtYXRpb24gcGFzc2VkIGluLg0KICAgICAgICAgICAgICAgICAgICAg
SGFuZGxlPFByaWNpbmdFbnZpcm9ubWVudD4mIFByaWNlRW52LCAgICAgICAgICAgIC8vITwgRW52
aXJvbm1lbnQgZm9yIHByaWNpbmcNCgkJCSAgICAgICAgIGNvbnN0IHN0ZDo6c3RyaW5nJiBNb2Rl
bE5hbWUgPSAiIiwNCgkJCSAgICAgICAgIGNvbnN0IHN0ZDo6c3RyaW5nJiBFbmdpbmVOYW1lID0g
IiINCiAgICAgICAgICAgICAgICAgICAgICkNCiAgICAgICAgICAgICAgICAgICAgIDogcHJpY2lu
Z0Vudl8oUHJpY2VFbnYpDQogICAgew0KICAgICAgICAvL2ZpcnN0IGluc3RhbnRpYXRlIHRoZSBw
YXlvZmZzIGZvciB0aGlzIG9iamVjdCB0aGF0IHdpbGwgYmUgcGFzc2VkIHRvIHRoZSBwcmljZXIg
bGF0ZXIuDQogICAgICAgIGdldENhc2hmbG93c0FuZFBheW9mZihUcmFkZXNoZWV0KTsNCiAgICAg
ICAgcHJvY2Vzc18gPSBQcmljZUVudi0+Z2V0U3RvY2hhc3RpY1Byb2Nlc3MoIkV4YW1wbGVJbnN0
cnVtZW50IiwgVHJhZGVzaGVldCwgTW9kZWxOYW1lKTsNCiAgICAgICAgZW5naW5lXyA9IFByaWNl
RW52LT5nZXRQcmljaW5nRW5naW5lKCJFeGFtcGxlSW5zdHJ1bWVudCIsIEVuZ2luZU5hbWUpOw0K
ICAgICAgICByZWdpc3RlcldpdGgoZW5naW5lXyk7DQogICAgICAgIHJlZ2lzdGVyV2l0aChwcm9j
ZXNzXyk7DQogICAgfQ0KcHJpdmF0ZToNCiAgICBib29zdDo6c2hhcmVkX3B0cjxQcmljaW5nRW5n
aW5lPiBlbmdpbmVfOw0KICAgIGJvb3N0OjpzaGFyZWRfcHRyPFN0b2NoYXN0aWNQcm9jZXNzPiBw
cm9jZXNzXzsNCiAgICBIYW5kbGU8UHJpY2luZ0Vudmlyb25tZW50PiBwcmljaW5nRW52XzsNCn07
DQoNCmNsYXNzIFByaWNpbmdFbnZpcm9ubWVudCA6DQp7DQogICAgLy8hIFJldHVybnMgYSBwcmlj
aW5nIGVuZ2luZSBmcm9tIGEgZmFjdG9yeS4NCiAgICBib29zdDo6c2hhcmVkX3B0cjxQcmljaW5n
RW5naW5lPiBnZXRQcmljaW5nRW5naW5lKGNvbnN0IHN0ZDo6c3RyaW5nJiBJbnN0cnVtZW50VHlw
ZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IGNvbnN0IHN0ZDo6c3RyaW5nJiBFbmdpbmVOYW1lKQ0KICAgIHsNCiAgICAgICAgcmV0dXJuIGVu
Z2luZUZhY3RvcnlfLT5nZXRTcGVjaWZpY0VuZ2luZShJbnN0cnVtZW50VHlwZSwNCiAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBFbmdpbmVOYW1lKTsNCiAg
ICB9DQoNCiAgICAvLyEgUmV0dXJucyBhIHN0b2NoYXN0aWMgcHJvY2VzcyBmcm9tIGEgZmFjdG9y
eS4NCiAgICBib29zdDo6c2hhcmVkX3B0cjxTdG9jaGFzdGljUHJvY2Vzcz4gZ2V0U3RvY2hQcm9j
ZXNzKGNvbnN0IHN0ZDo6c3RyaW5nJiBJbnN0cnVtZW50VHlwZSwNCiAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIEluc3RydW1lbnQ6OlRlcm1z
aGVldCYgVHJhZGVTaGVldCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgIGNvbnN0IHN0ZDo6c3RyaW5nJiBNb2RlbE5hbWUpDQogICAgew0K
ICAgICAgICByZXR1cm4gcHJvY2Vzc0ZhY3RvcnlfLT5nZXRTcGVjaWZpY1Byb2Nlc3MoSW5zdHJ1
bWVudFR5cGUsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBUcmFkZVNoZWV0LA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgTW9kZWxOYW1lLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgbWFya2V0RGF0YV8pOw0KICAgIH0NCnByaXZhdGU6DQogICAgSGFu
ZGxlPE1hcmtldERhdGFDb2xsZWN0aW9uPiBtYXJrZXREYXRhXzsNCiAgICBIYW5kbGU8UHJpY2lu
Z0VuZ2luZUZhY3Rvcnk+IGVuZ2luZUZhY3RvcnlfOw0KICAgIEhhbmRsZTxTdG9jaFByb2Nlc3NG
YWN0b3J5PiBwcm9jZXNzRmFjdG9yeV87DQp9Ow0KDQpjbGFzcyBQcm9jZXNzRmFjdG9yeQ0Kew0K
ICAgIC8vISBVc2VzIGEgc3RhbmRhcmQgcGF0dGVybiBmb3IgY3JlYXRpbmcgYW4gb2JqZWN0IHNw
ZWNpZmllZCBieSBhIHN0cmluZy4NCiAgICBib29zdDo6c2hhcmVkX3B0cjxTdG9jaGFzdGljUHJv
Y2Vzcz4gZ2V0U3BlY2lmaWNQcm9jZXNzKGNvbnN0IHN0ZDo6c3RyaW5nJiBJbnN0cnVtZW50VHlw
ZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgIEluc3RydW1lbnQ6OlRlcm1zaGVldCYgVHJhZGVTaGVldCwNCiAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0ZDo6c3RyaW5n
IE1vZGVsTmFtZSwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgIEhhbmRsZTxNYXJrZXREYXRhQ29sbGVjdGlvbj4mIE1hcmtldERhdGEp
DQogICAgew0KICAgICAgICBpZihNb2RlbE5hbWUgPT0gIiIpDQogICAgICAgICAgICBNb2RlbE5h
bWUgPSBnZXREZWZhdWx0TW9kZWxOYW1lKEluc3RydW1lbnRUeXBlKTsNCg0KICAgICAgICByZXR1
cm4gSW5zdGFuY2UoKS5DcmVhdGVTdG9jaGFzdGljUHJvY2VzcyhNb2RlbE5hbWUsIFRyYWRlU2hl
ZXQsIE1hcmtldERhdGEpOw0KICAgIH0NCn0NCg0KY2xhc3MgRXhhbXBsZVhDY3lNb2RlbCA6IHB1
YmxpYyBTdG9jaGFzdGljUHJvY2Vzcw0Kew0KICAgIC8vISBJbml0aWFsaXNlcyB0aGUgTW9kZWwN
CiAgICBFeGFtcGxlWENjeU1vZGVsKEluc3RydW1lbnQ6OlRlcm1zaGVldCYgVHJhZGVTaGVldCwN
CiAgICAgICAgICAgICAgICAgICAgIEhhbmRsZTxNYXJrZXREYXRhQ29sbGVjdGlvbj4mIE1hcmtl
dERhdGEpDQogICAgew0KICAgICAgICAvL0ZpcnN0IGdldCB0aGUgZnVuZGluZyBhbmQgZm9yd2Fy
ZGluZyBjdXJ2ZXMNCiAgICAgICAgVHJhZGVTaGVldC5maWxsWWllbGRDdXJ2ZURhdGEoZmlyc3RZ
aWVsZEN1cnZlRGVzY3JpcHRvcl8sIDApOw0KICAgICAgICBmaXJzdERpc2NvdW50Q3VydmVfID0g
IE1hcmtldERhdGEtPmdldERpc2NvdW50Q3VydmUoZmlyc3RZaWVsZEN1cnZlRGVzY3JpcHRvcl8p
Ow0KICAgICAgICBmaXJzdEZvcndhcmRDdXJ2ZV8gPSBNYXJrZXREYXRhLT5nZXRGb3J3YXJkQ3Vy
dmUoZmlyc3RZaWVsZEN1cnZlRGVzY3JpcHRvcl8pOw0KICAgICAgICBUcmFkZVNoZWV0LmZpbGxZ
aWVsZEN1cnZlRGF0YShzZWNvbmRZaWVsZEN1cnZlRGVzY3JpcHRvcl8sIDEpOw0KICAgICAgICBz
ZWNvbmREaXNjb3VudEN1cnZlXyA9ICBNYXJrZXREYXRhLT5nZXREaXNjb3VudEN1cnZlKHNlY29u
ZFlpZWxkQ3VydmVEZXNjcmlwdG9yXyk7DQogICAgICAgIHNlY29uZEZvcndhcmRDdXJ2ZV8gPSBN
YXJrZXREYXRhLT5nZXRGb3J3YXJkQ3VydmUoc2Vjb25kWWllbGRDdXJ2ZURlc2NyaXB0b3JfKTsN
Cg0KICAgICAgICAvL1RoZW4gZ2V0IHRoZSBGWCBWYWx1ZQ0KICAgICAgICBUcmFkZVNoZWV0LmZp
bGxGWFNwb3REYXRhKGZ4U3BvdERlc2NyaXB0b3JfKTsNCiAgICAgICAgZnhTcG90VmFsdWVfID0g
TWFya2V0RGF0YS0+Z2V0RlhTcG90VmFsdWUoZnhTcG90RGF0YV8pOw0KDQogICAgICAgIC8vVGhl
biBnZXQgdGhlIFZvbCBEYXRhDQogICAgICAgIFRyYWRlU2hlZXQuZmlsbEZYVm9sRGF0YShmeFZv
bERhdGFfKTsNCiAgICAgICAgZnhWb2xTdXJmYWNlXyA9IE1hcmtldERhdGEtPmdldEZYVm9sU3Vy
ZmFjZShmeFZvbERhdGFfKTsNCiAgICAgICAgVHJhZGVTaGVldC5maWxsSVJWb2xEYXRhKGZpcnN0
SVJWb2xEZXNjcmlwdG9yXywgMCk7DQogICAgICAgIGZpcnN0SVJWb2xDdWJlXyA9IE1hcmtldERh
dGEtPmdldElSVm9sQ3ViZShmaXJzdElSVm9sRGVzY3JpcHRvcl8pOw0KICAgICAgICBUcmFkZVNo
ZWV0LmZpbGxJUlZvbERhdGEoc2Vjb25kSVJWb2xEZXNjcmlwdG9yXywgMSk7DQogICAgICAgIHNl
Y29uZElSVm9sQ3ViZV8gPSBNYXJrZXREYXRhLT5nZXRJUlZvbEN1YmUoc2Vjb25kSVJWb2xEZXNj
cmlwdG9yXyk7DQoNCiAgICAgICAgLy9maW5hbGx5LCBnZXQgc3BlY2lhbGlzZWQgY29ycmVsYXRp
b24gKGFzc3VtaW5nIHdlIGRvbid0IGNhbGlicmF0ZSkNCiAgICAgICAgY29ycmVsYXRpb25zXyA9
IE1hcmtldERhdGEtPmdldENvcnJlbGF0aW9ucygiSFctQmxhY2stSFciLCBmeFNwb3REZXNjcmlw
dG9yXyk7DQoNCiAgICAgICAgcmVnaXN0ZXJNZSgpOyAvL3JlZ2lzdGVyIHdpdGggdGhlIG1hcmtl
dCBkYXRhIG9iamVjdHMNCiAgICB9DQp9Ow0KDQpjbGFzcyBNYXJrZXREYXRhQ29sbGVjdGlvbiA6
IHB1YmxpYyBPYnNlcnZhYmxlDQp7DQogICAgLy8NCiAgICB0ZW1wbGF0ZSA8Y2xhc3MgVD4NCiAg
ICB2b2lkIGdldERhdGFTdWJzZXQoY29uc3Qgc3RkOjp2ZWN0b3I8c3RkOjpzdHJpbmc+JiBUYWdz
LCAgICAgICAgLy8hPCBUYWdzIHdoaWNoIGRlZmluZSB0aGUgcmVxdWlyZWQgb2JqZWN0DQogICAg
ICAgICAgICAgICAgICAgICAgIGNvbnN0IHN0ZDo6dmVjdG9yPHN0ZDo6c3RyaW5nPiYgVmFsdWVz
LCAgICAgIC8vITwgVmFsdWVzIHdoaWNoIGNhbi9tdXN0IGJlIG1hdGNoZWQNCiAgICAgICAgICAg
ICAgICAgICAgICAgY29uc3Qgc3RkOjptYXA8dmVjdG9yPHN0ZDo6c3RyaW5nPiwgVD4mIFNldCwg
Ly8hPCBUaGUgaW5wdXQgc2V0IG9mIHBvc3NpYmxlIGRhdGENCiAgICAgICAgICAgICAgICAgICAg
ICAgc3RkOjptYXA8dmVjdG9yPHN0ZDo6c3RyaW5nPiwgVD4mIFN1YnNldCwgICAgLy8hPCBUaGUg
b3V0cHV0IHNldA0KICAgICAgICAgICAgICAgICAgICAgICBib29sIFRocm93RXJyb3IgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAvKiE8IElmIHRydWUsIHRoZW4gdGhlIGlucHV0IGRhdGEg
bXVzdCBiZSBtYXRjaGVkLA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGlmIGZhbHNlLCB0aGVuIHRyeSB0byBt
YXRjaCBlYWNoIFRhZzo6VmFsdWUgaW4gdHVybg0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKi8NCiAgICAgICAgICAg
ICAgICAgICAgICAgKSBjb25zdA0KICAgIHsuLi59DQoNCiAgICB0ZW1wbGF0ZSA8Y2xhc3MgVD4N
CiAgICB2b2lkIGdldFNwZWNpZmljSW5zdGFuY2UoY29uc3QgQmFzZURlc2NyaXB0b3ImIERlc2Ny
aXB0b3IsDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgIHN0ZDo6bWFwPHZlY3RvcjxzdGQ6
OnN0cmluZz4sIFQ+JiBEYXRhU2V0KQ0KICAgIHsNCiAgICAgICAgLy9maXJzdGx5IHRoZXJlIGFy
ZSBzb21lIHZhbHVlcyB0aGF0IGFic29sdXRlbHkgTVVTVCBtYXRjaC4NCiAgICAgICAgZ2V0RGF0
YVN1YnNldChEZXNjcmlwdG9yLmdldFJlcXVpcmVkRGF0YVRhZ3MoKSwNCiAgICAgICAgICAgICAg
ICAgICAgICBEZXNjcmlwdG9yLmdldFJlcXVpcmVkRGF0YVZhbHVlcygpLA0KICAgICAgICAgICAg
ICAgICAgICAgIERhdGFTZXQsDQogICAgICAgICAgICAgICAgICAgICAgRGF0YVNldCwNCiAgICAg
ICAgICAgICAgICAgICAgICB0cnVlKTsNCiAgICAgICAgLy90aGVuIHRoZXJlIGFyZSBzb21lIHZh
bHVlcyB0aGF0IG1heSBtYXRjaCAoYW5kIGFyZSBzZXQgYXMgcGFydCBvZiB0aGUgdHJhZGUpDQog
ICAgICAgIGdldERhdGFTdWJzZXQoRGVzY3JpcHRvci5nZXRUcmFkZUlkVGFncygpLA0KICAgICAg
ICAgICAgICAgICAgICAgIERlc2NyaXB0b3IuZ2V0VHJhZGVJZFZhbHVlcygpLA0KICAgICAgICAg
ICAgICAgICAgICAgIERhdGFTZXQsDQogICAgICAgICAgICAgICAgICAgICAgRGF0YVNldCwNCiAg
ICAgICAgICAgICAgICAgICAgICBmYWxzZSk7DQogICAgICAgIC8vdGhlbiB0aGVyZSBhcmUgc29t
ZSB2YWx1ZXMgdGhhdCBtYXkgbWF0Y2ggKGFuZCBhcmUgcGFydCBvZiB0aGUgb2JqZWN0IHR5cGUg
ZGVzY3JpcHRpb24pDQogICAgICAgIGdldERhdGFTdWJzZXQoRGVzY3JpcHRvci5nZXRPcHRpb25h
bFRhZ3MoKSwNCiAgICAgICAgICAgICAgICAgICAgICBEZXNjcmlwdG9yLmdldE9wdGlvbmFsVmFs
dWVzKCksDQogICAgICAgICAgICAgICAgICAgICAgRGF0YVNldCwNCiAgICAgICAgICAgICAgICAg
ICAgICBEYXRhU2V0LA0KICAgICAgICAgICAgICAgICAgICAgIGZhbHNlKTsNCiAgICB9DQoNCiAg
ICAvLyEgcmV0dXJucyBhIGhhbmRsZSB0byB0aGUgcmVxdWlyZWQgZGlzY291bnQgY3VydmUNCiAg
ICBIYW5kbGU8WWllbGRUZXJtU3RydWN0dXJlPiBnZXREaXNjb3VudEN1cnZlKFlpZWxkQ3VydmVE
ZXNjcmlwdG9yJiBEZXNjcmlwdG9yKQ0KICAgIHsNCiAgICAgICAgc3RkOjptYXA8IHZlY3Rvcjxz
dGQ6OnN0cmluZz4sIEhhbmRsZTxZaWVsZFRlcm1TdHJ1Y3R1cmU+ID4gZGF0YVNldCh5aWVsZEN1
cnZlU2V0Xyk7DQogICAgICAgIGdldFNwZWNpZmljSW5zdGFuY2UoRGVzY3JpcHRvciwgZGF0YVNl
dCk7DQogICAgICAgIHZlY3RvcjxzdGQ6OnN0cmluZz4gZGlzY291bnRUYWcoMSwgIllpZWxkQ3Vy
dmUgVHlwZSIpLCBkaXNjb3VudFZhbHVlKDEsICJEaXNjb3VudCIpOw0KICAgICAgICBnZXREYXRh
U3Vic2V0KGRpc2NvdW50VGFnLCBkaXNjb3VudFZhbHVlLCBkYXRhU2V0LCBkYXRhU2V0LCBpc0Zv
cndhcmRDdXJ2ZUFsbG93ZWQoKSk7IC8vZnVuY3Rpb25hbGl0eSB0byBhbGxvdyBhIGZvcndhcmQg
Y3VydmUgYXMgYSBkaXNjb3VudCBjdXJ2ZQ0KICAgICAgICBpZihkYXRhU2V0LnNpemUoKSAhPSAx
KQ0KICAgICAgICAgICAgdGhyb3cuLi47DQoNCiAgICAgICAgcmV0dXJuIGRhdGFTZXQuZnJvbnQo
KTsNCiAgICB9ICAgICAgDQp9Ow0KDQoNCg0KDQovL0ZJTkFMTFksIHNvbWUgZXhhbXBsZSBjb2Rl
IGZvciB3aGF0IHNob3VsZCBiZSBpbnNpZGUgYSBmdW5jdGlvbiBzdWNoIGFzIFRlcm1zaGVldDo6
ZmlsbFlpZWxkQ3VydmVEYXRhKCkNCnZvaWQgVGVybXNoZWV0OjpmaWxsWWllbGRDdXJ2ZURhdGEo
WWllbGRDdXJ2ZURlc2NyaXB0b3ImIERlc2NyaXB0b3IsIEludGVnZXIgQ3VycmVuY3lOdW0pIGNv
bnN0DQp7DQogICAgc3RkOjp2ZWN0b3I8IHN0ZDo6c3RyaW5nID4gY3VycmVuY3lUYWcoMSwgIkN1
cnJlbmN5Iik7DQogICAgRGVzY3JpcHRvci5zZXRSZXF1aXJlZERhdGEoY3VycmVuY3lUYWcsIHN0
ZDo6dmVjdG9yPHN0ZDo6c3RyaW5nPiAoMSwgZ2V0Q3VycmVuY3lOYW1lKEN1cnJlbmN5TnVtKSkp
Ow0KDQogICAgLy9UaGUgdHJhZGUgdGFncyBzaG91bGQgaGF2ZSBhIGNvbW1vbiBmb3JtYXQgYWNy
b3NzIGFsbCB0cmFkZXMsIGxpa2UgInRyYWRlSUQiLCAidHJhZGVHcm91cCIsICJ0cmFkZUJvb2si
Lg0KICAgIERlc2NyaXB0b3Iuc2V0VHJhZGVJZChnZXRUcmFkZUlkVGFncygpLCBnZXRUcmFkZUlk
VmFsdWVzKCkpOyANCg0KICAgIHN0ZDo6dmVjdG9yPCBzdGQ6OnN0cmluZyA+IG9wdGlvbmFsVGFn
cywgb3B0aW9uYWxWYWx1ZXM7DQogICAgb3B0aW9uYWxUYWdzLnB1c2hfYmFjaygiSW5kZXgiKTsN
CiAgICBvcHRpb25hbFZhbHVlcy5wdXNoX2JhY2soZ2V0SW5kZXhOYW1lKEN1cnJlbmN5TnVtKSk7
DQp9

Re: [Quantlib-dev] System interface

[Simon I. <s.i...@gm...>]

Okay, here's my first stab at sketching the implementation, I've attached a
file showing the basic draft of the pattern.

There are several classes outlined - I've tried to follow the basic
structure of QuantLib and derived from the basic classes... if I've broken a
pattern irreparably, let me know.


 The Termsheet class (deliberately left opaque), which supplies
cashflows/payoff for the Instrument and information to resolve the market
data.
The Instrument derived class which holds the payoff and cashflow arguments
for the PricingEngine.
The PricingEnvironment which supplies the StochasticProcess and
PricingEngine for the Instrument and the MarketDataCollection for the
StochasticProcess.
The StochasticProcess derived object, which determines the type of market
data required.
The MarketDataCollection class, which supplies the specific market data
objects.


This is idealised, there may be cases where the Instrument does not require
a StochasticProcess or PricingEngine and should simply get the required
market data from the PricingEnvironment itself.

All comments are welcome,

Simon




On 10/3/07, Luigi Ballabio <lui...@gm...> wrote:
>
> On Fri, 2007-09-28 at 10:12 +0100, Simon Ibbotson wrote:
> > The library is currently devised (from what I've seen) s.t. the market
> > data is given to the model or instrument as a specific type or set of
> > types. [...] I term this pattern the PUSH method. In it, the
> > business/quant knowledge specific to the model is split between the
> > model code (where the data is used) and the calling code (where the
> > data is constructed and allocated to the model.
> >
> > However, for system development and more complicated products, I much
> > prefer the PULL method. In this pattern,  a generic market data
> > collection object is passed to the model and the model itself
> > determines which specific data is required for pricing.
>
> Simon,
>        interesting idea.  However, I'm not sure that I'd jump into it
> right
> now---I'm aiming for a 0.9.0 release by the end of the year and a 1.0
> release shortly afterwards, with a couple of refactoring and some
> maintenance work to be done before that.  In order to deliver the
> releases, I'd keep your idea for later. Since, as you said, it's an
> incremental modification (an instrument might implement both approaches,
> right?) it can be introduced in later releases without breaking backward
> compatibility (which we'll have to think about after we release 1.0)
>
> This said, I repeat: interesting idea. Why don't you sketch the
> implementation of one instrument so that we can go into details?
>
> Later,
>        Luigi
>
>
> --
>
> I hate quotations.
> -- Ralph Waldo Emerson
>
>
>

[Quantlib-dev] Hybrid models

[<fho...@gm...>]

Has somebody already had the opportunity to play around with hybrid models? A first start could be just Hull-White for IR with Black-Scholes for equity but obvious extensions are also of interest. Are there already any experiences of this kind? Is there any generic setup already in place?

Rgds
Frank

-- 
Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kanns mit allen: http://www.gmx.net/de/go/multimessenger

Re: [Quantlib-dev] FpML & SOAP volunteering interests

[Luigi B. <lui...@gm...>]

On Oct 6, 2007, at 4:59 PM, Eric Ehlers wrote:
> SourceForge reorganized the mailing list archives, breaking the links  
> that
> I posted in that message.  But if you search the quantlib-dev archive  
> for
> FpML, all the messages are still there from the earlier discussion in
> which the initial design for QuantLib-Fpml was first sketched out.  The
> crux of that exchange was this message from Ferdinando on 9 February  
> 2005:
>
> http://sourceforge.net/mailarchive/message.php? 
> msg_id=6.0.0.22.0.20050209194225.025f0620%40mail.ametrano.net

I might add that the design of the library evolved since that message  
was written. Right now we're moving towards a design in which the  
instrument _is_ the term sheet.

Later,
	Luigi

Re: [Quantlib-dev] FpML & SOAP volunteering interests

[Eric E. <eri...@na...>]

Hi Prashant,

> Hey Eric,
> All I could find from the archives was your communication on same topic
> about 1-1/2yr ago w/ Shilpi Agarwal from Sapient. Apparently, her
> request was exactly similar to mine. Not sure if she is still interested
> in joining up on QuantLib FpmL extension.
>
> In that post/communication w/ her you had specifically pointed to 5
> links to the posts which supposedly talk about design approaches to
> QuantLib-FpML extension.
>
> Unfortunately when I clicked those links, none of them work. They give
> some kind of Error ---Post not found equivalent.

SourceForge reorganized the mailing list archives, breaking the links that
I posted in that message.  But if you search the quantlib-dev archive for
FpML, all the messages are still there from the earlier discussion in
which the initial design for QuantLib-Fpml was first sketched out.  The
crux of that exchange was this message from Ferdinando on 9 February 2005:

http://sourceforge.net/mailarchive/message.php?msg_id=6.0.0.22.0.20050209194225.025f0620%40mail.ametrano.net

Regards,
Eric

Re: [Quantlib-dev] 2. Re: C++ help needed: singleton.hpp (Luigi Ballabio)

[Mark j. <mar...@gm...>]

Oh no, this was just following up on Klaus's comments.


On 06/10/2007, Luigi Ballabio <lui...@gm...> wrote:
>
> On Oct 6, 2007, at 12:12 AM, Mark joshi wrote:
> > There some bugginess in VC 6,0 with static member variables in
> > templatized functions. I.e. it gets confused about how many copies of
> > the variable there are.
>
> Mark,
>         I'm not surprised---we dropped support for VC 6.0 a couple of releases
> ago.  Do you need to make the library work with it?
>
> Luigi
>
>


-- 
Assoc Prof Mark Joshi
Centre for Actuarial Studies
University of Melbourne
My website is www.markjoshi.com

Re: [Quantlib-dev] 2. Re: C++ help needed: singleton.hpp (Luigi Ballabio)

[Luigi B. <lui...@gm...>]

On Oct 6, 2007, at 12:12 AM, Mark joshi wrote:
> There some bugginess in VC 6,0 with static member variables in 
> templatized functions. I.e. it gets confused about how many copies of 
> the variable there are.

Mark,
	I'm not surprised---we dropped support for VC 6.0 a couple of releases 
ago.  Do you need to make the library work with it?

Luigi

[Quantlib-dev] 2. Re: C++ help needed: singleton.hpp (Luigi Ballabio)

[Mark j. <mar...@gm...>]

There some bugginess in VC 6,0 with static member variables in templatized
functions. I.e. it gets confused about how many copies of the variable there
are.

Mark

Re: [Quantlib-dev] Yield Curve Boostraping Improvements

[Bianchetti M. <mar...@ba...>]

Yes, I confirm the Hagan-West paper as a key reference.
Luis, is the method you mention published somewhere ?
Ciao
Marco
=20

	-----Original Message-----
	From: qua...@li...
[mailto:qua...@li...] On Behalf Of Simon
Ibbotson
	Sent: 02 October 2007 15:03
	To: newbie73
	Cc: qua...@li...
	Subject: Re: [Quantlib-dev] Yield Curve Boostraping Improvements
=09
=09
	You might want to examine the paper by Hagan&West on smooth
yieldcurve construction. Their convex monotone spline method gives great
results.
	=20
	Simon


	=20
	On 10/2/07, newbie73 <lui...@av...> wrote:=20


		The choppy forward curves appear regardless of which
interpolation method is
		used.  The term structure of 3m or 6m forward rates
results in a saw-tooth=20
		term structure which deviates from market by huge
amounts.
	=09
		Regarding the knot points, I was referring to picking
maturities that do not
		necessarily correspond with the chosen instruments.  The
methodology we use=20
		here treats the area between each knot point as its own
curve (or curve
		function), so you end up with many separate curves which
segment the yield
		curve which are then combined to ensure smooth forward
curve generation.=20
	=09
		The technique itself is quite old and was developed by
Lehman in the late
		80s, but works well in most cases I've encountered.
	=09
		- Luis
	=09
	=09
		Luigi Ballabio wrote:
		>
		> On Mon, 2007-10-01 at 07:20 -0700, newbie73 wrote:=20
		>
		>> So far I've been quite happy with the functionality
in the QuantLib
		>> library - I'd like to start using it to compare to
market pricing.
		>> I've found that the curve stripping methodology
produces extremely=20
		>> jagged forward curves which result in poor pricing of
several market
		>> structures.
		>
		> Does this depend on the chosen interpolation?
		>
		>> Also, some algorithmic help in dynamically selecting
knot points would be=20
		>> much appreciated as well.  The basic idea is the
creation of a smooth
		>> interpolation method for a selected set of knot
points for a given curve.
		>
		> "Selecting knot points" as in "choosing which
instruments to use among=20
		> the available ones" (which is what Nando referred to)
or as in "choosing
		> a set of knots freely, i.e., not necessarily
corresponding to instrument
		> maturities"?
		>
		> Later,=20
		>       Luigi
		>
		>
		> --
		>
		> This gubblick contains many nonsklarkish English
flutzpahs, but the
		> overall pluggandisp can be glorked from context.
		> -- David Moser
		>
		>
		>
		>
------------------------------------------------------------------------
-
		> This SF.net email is sponsored by: Microsoft
		> Defy all challenges. Microsoft(R) Visual Studio 2005.
		>
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
		> _______________________________________________
		> QuantLib-dev mailing list
		> Qua...@li...=20
		>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
		>
		>
	=09
		--
		View this message in context:
http://www.nabble.com/Yield-Curve-Boostraping-Improvements-tf4548647.htm
l#a12997264
		Sent from the quantlib-dev mailing list archive at
Nabble.com.
	=09
	=09
=09
------------------------------------------------------------------------
-=20
		This SF.net email is sponsored by: Microsoft
		Defy all challenges. Microsoft(R) Visual Studio 2005.
		http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/=20
		_______________________________________________
		QuantLib-dev mailing list
		Qua...@li...
=09
https://lists.sourceforge.net/lists/listinfo/quantlib-dev
	=09

Re: [Quantlib-dev] FpML & SOAP volunteering interests

[Sarode, P. <pra...@wa...>]

Hey Eric,
All I could find from the archives was your communication on same topic
about 1-1/2yr ago w/ Shilpi Agarwal from Sapient. Apparently, her
request was exactly similar to mine. Not sure if she is still interested
in joining up on QuantLib FpmL extension.

In that post/communication w/ her you had specifically pointed to 5
links to the posts which supposedly talk about design approaches to
QuantLib-FpML extension.=20

Unfortunately when I clicked those links, none of them work. They give
some kind of Error ---Post not found equivalent.

So effectively I am still stuck at the point where I cannot ready on the
historical ideas proposed around QuantLib-FpML binding.


Prashant Sarode
Vice President Corporate & Investment Banking Technology
Wachovia
1 704 715 5563(L)
1 617 319 8162(M)

-----Original Message-----
From: Eric Ehlers [mailto:eri...@na...]=20
Sent: Friday, October 05, 2007 8:27 AM
To: Sarode, Prashant
Cc: qua...@li...
Subject: Re: [Quantlib-dev] FpML & SOAP volunteering interests

Hi Prashant,

> Hi,
>
> I am Prashant Sarode. I have strong experience in FpML (4.1-4.4
> especially Post-Trade Processes/Mid-2-Back Office side) and SOAP based
> services. I am new to but very interested in QuantLib project and its
> user community.

Welcome.

> I am writing this email to the group to:
>
> 1>Volunteer myself for the request from QuantLib website around any
> potential work that overlaps/involves QuanLib + FpML and SOAP. My
> longest experience has been around FpML + SOAP in a J2EE tech
> stack---now moving into grid technology stack.

In the mailing list archives you can see that the subject of
FpML-enabling
QuantLib has been under discussion for some time.  In an initial
exchange,
a high-level design was sketched out.  Subsequent correspondence about
implementation led to the creation of module QuantLib-FpML on the svn
trunk, but to my knowledge no further progress was made.  If you're
interested in picking this up I imagine you would find a lot of
interest.

An alternative to FpML is serialization based on ValueObjects in
ObjectHandler.  This approach is less sophisticated but easier to
implement.  This functionality has been implemented on the subversion
trunk for inclusion in the upcoming release of QuantLib version 0.9.0.

Regards,
Eric

Re: [Quantlib-dev] FpML & SOAP volunteering interests

[Eric E. <eri...@na...>]

Hi Prashant,

> Hi,
>
> I am Prashant Sarode. I have strong experience in FpML (4.1-4.4
> especially Post-Trade Processes/Mid-2-Back Office side) and SOAP based
> services. I am new to but very interested in QuantLib project and its
> user community.

Welcome.

> I am writing this email to the group to:
>
> 1>Volunteer myself for the request from QuantLib website around any
> potential work that overlaps/involves QuanLib + FpML and SOAP. My
> longest experience has been around FpML + SOAP in a J2EE tech
> stack---now moving into grid technology stack.

In the mailing list archives you can see that the subject of FpML-enabling
QuantLib has been under discussion for some time.  In an initial exchange,
a high-level design was sketched out.  Subsequent correspondence about
implementation led to the creation of module QuantLib-FpML on the svn
trunk, but to my knowledge no further progress was made.  If you're
interested in picking this up I imagine you would find a lot of interest.

An alternative to FpML is serialization based on ValueObjects in
ObjectHandler.  This approach is less sophisticated but easier to
implement.  This functionality has been implemented on the subversion
trunk for inclusion in the upcoming release of QuantLib version 0.9.0.

Regards,
Eric

[Quantlib-dev] [ quantlib-Bugs-1603024 ] ./configure fails on Mac OS X 10.4

[SourceForge.net <no...@so...>]

Bugs item #1603024, was opened at 2006-11-26 07:45
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1603024&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Deleted
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ./configure fails on Mac OS X 10.4 

Initial Comment:
It is my first time to install Boost and Quantlib on my Mac OS X, but it is not successfull yet, so I wish I could get some help.

I have installed boost_1_33_1 in a directory:
~/Study/Programming/Boost/boost_1_33_1/
, which includes both /boost and /libs directories.

In the Quantlib directory (I'm using QuantLib-0.3.14), if I run
sh -x ./configure
then, a file 'config.log' is generated. Inside the log file, some of the error messages read
===========================================
conftest.c:10:28: error: ac_nonexistent.h: No such file or directory
conftest.cpp:21:28: error: ac_nonexistent.h: No such file or directory
configure; failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "QuantLib"
...
| /* end confdefs.h. */
| #include <ac_nonexistent.h>
...
conftest.cpp:25: error: 'M_SQRT_2' was not declared in this scope
conftest.cpp:26: error: 'M_SQRTPI' was not declared in this scope
...
conftest.cpp:24:29: error: boost/version.hpp No such file or directory
conftest.cpp:25:37: error: boost/shared_ptr.hpp: No such file or directory
conftest.cpp:26:33: error: boost/assert.hpp: No such file or directlry
conftest.cpp:27:43: error: boost/current_function.hpp: No such file or directory
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "QuantLib"
...
| /* end confdefs.h. */
| #include < boost/version.hpp >
| #include < boost/shared_ptr.hpp >
| #include < boost/assert.hpp >
| #include < boost/current_function.hpp >
...
configure:20272: result: no
configure:20274: error: Boost development files not found
===========================================

Currently, my .hpp files such as version.hpp etc. are located in ~/Study/Programming/Boost/boost_1_33_1/libs. I assume that the errors occurs owing to the incorrect PATH, but I do not know how to fix it. I will appreciate much if anybody help me out.

Many thanks.





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

>Comment By: Luigi Ballabio (lballabio)
Date: 2007-10-05 09:55

Message:
Logged In: YES 
user_id=75450
Originator: NO

Run configure as

./configure --with-boost-include=~/Study/Programming/Boost/boost_1_33_1
--with-boost-lib=~/Study/Programming/Boost/boost_1_33_1/libs


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

Comment By: Nobody/Anonymous (nobody)
Date: 2007-10-03 21:48

Message:
Logged In: NO 

Hi, I compiled and installed both boost and quantlib on my macbook:
Download sources, un-tar.gz into directory, ./configure, make, sudo make
install. Boost installed itself into /usr/local/include/boost-1_34_1/boost.
 I linked it to /usr/local/include/boost so that quantlib could find it.
Then ./configure etc. for ql. Cheers Christian

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1603024&group_id=12740

[Quantlib-dev] FpML & SOAP volunteering interests

[Sarode, P. <pra...@wa...>]

Hi,

I am Prashant Sarode. I have strong experience in FpML (4.1-4.4
especially Post-Trade Processes/Mid-2-Back Office side) and SOAP based
services. I am new to but very interested in QuantLib project and its
user community.

=20

I am writing this email to the group to:

1>Volunteer myself for the request from QuantLib website around any
potential work that overlaps/involves QuanLib + FpML and SOAP. My
longest experience has been around FpML + SOAP in a J2EE tech
stack---now moving into grid technology stack.

=20

2> I wish to understand real business use cases of QuantLib + FpML +
SOAP. Has there been any activity in the direction already.

=20

3> I am also interested to find if any work has been done around high
performance/acceleration of any QuantLib functions/modules or Engines
which otherwise takes long time. Basically, interested in know any
QuantLib areas/functions/modules which can benefit from Grid-enablement.

=20

=20

Prashant Sarode

Vice President Corporate & Investment Banking Technology

Wachovia

1 704 715 5563(L)

1 617 319 8162(M)

=20

[Quantlib-dev] [ quantlib-Bugs-1603024 ] ./configure fails on Mac OS X 10.4

[SourceForge.net <no...@so...>]

Bugs item #1603024, was opened at 2006-11-25 22:45
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1603024&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: ./configure fails on Mac OS X 10.4 

Initial Comment:
It is my first time to install Boost and Quantlib on my Mac OS X, but it is not successfull yet, so I wish I could get some help.

I have installed boost_1_33_1 in a directory:
~/Study/Programming/Boost/boost_1_33_1/
, which includes both /boost and /libs directories.

In the Quantlib directory (I'm using QuantLib-0.3.14), if I run
sh -x ./configure
then, a file 'config.log' is generated. Inside the log file, some of the error messages read
===========================================
conftest.c:10:28: error: ac_nonexistent.h: No such file or directory
conftest.cpp:21:28: error: ac_nonexistent.h: No such file or directory
configure; failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "QuantLib"
...
| /* end confdefs.h. */
| #include <ac_nonexistent.h>
...
conftest.cpp:25: error: 'M_SQRT_2' was not declared in this scope
conftest.cpp:26: error: 'M_SQRTPI' was not declared in this scope
...
conftest.cpp:24:29: error: boost/version.hpp No such file or directory
conftest.cpp:25:37: error: boost/shared_ptr.hpp: No such file or directory
conftest.cpp:26:33: error: boost/assert.hpp: No such file or directlry
conftest.cpp:27:43: error: boost/current_function.hpp: No such file or directory
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME "QuantLib"
...
| /* end confdefs.h. */
| #include < boost/version.hpp >
| #include < boost/shared_ptr.hpp >
| #include < boost/assert.hpp >
| #include < boost/current_function.hpp >
...
configure:20272: result: no
configure:20274: error: Boost development files not found
===========================================

Currently, my .hpp files such as version.hpp etc. are located in ~/Study/Programming/Boost/boost_1_33_1/libs. I assume that the errors occurs owing to the incorrect PATH, but I do not know how to fix it. I will appreciate much if anybody help me out.

Many thanks.





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

Comment By: Nobody/Anonymous (nobody)
Date: 2007-10-03 12:48

Message:
Logged In: NO 

Hi, I compiled and installed both boost and quantlib on my macbook:
Download sources, un-tar.gz into directory, ./configure, make, sudo make
install. Boost installed itself into /usr/local/include/boost-1_34_1/boost.
 I linked it to /usr/local/include/boost so that quantlib could find it.
Then ./configure etc. for ql. Cheers Christian

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

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1603024&group_id=12740

Re: [Quantlib-dev] System interface

[Luigi B. <lui...@gm...>]

On Fri, 2007-09-28 at 10:12 +0100, Simon Ibbotson wrote:
> The library is currently devised (from what I've seen) s.t. the market
> data is given to the model or instrument as a specific type or set of
> types. [...] I term this pattern the PUSH method. In it, the
> business/quant knowledge specific to the model is split between the
> model code (where the data is used) and the calling code (where the
> data is constructed and allocated to the model.
>  
> However, for system development and more complicated products, I much
> prefer the PULL method. In this pattern,  a generic market data
> collection object is passed to the model and the model itself
> determines which specific data is required for pricing.

Simon,
	interesting idea.  However, I'm not sure that I'd jump into it right
now---I'm aiming for a 0.9.0 release by the end of the year and a 1.0
release shortly afterwards, with a couple of refactoring and some
maintenance work to be done before that.  In order to deliver the
releases, I'd keep your idea for later. Since, as you said, it's an
incremental modification (an instrument might implement both approaches,
right?) it can be introduced in later releases without breaking backward
compatibility (which we'll have to think about after we release 1.0)

This said, I repeat: interesting idea. Why don't you sketch the
implementation of one instrument so that we can go into details?

Later,
	Luigi


-- 

I hate quotations. 
-- Ralph Waldo Emerson