quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] Preliminary tarballs for 0.3.11 release

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

Hi all,
	preliminary tarballs for the 0.3.11 release are available at =20
<http://quantlib.org/prerelease/>. If you have some time (or if you can =20
leave your office computer running a compilation during the weekend) =20
please download them and check whether there are any problems.

Thanks,
	Luigi

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

Testing can never demonstrate the absence of errors in software, only
their presence.
-- W.E. Dijkstra

[Quantlib-dev] Checked in fix to MCAmericanBasketOption

[Joseph W. <jo...@co...>]

Adds one to the required paths if odd.  Also checked in a unit test that 
used to break but not works.

I'll add in an option to make antithetic sampling optional (default off) 
in the next few days.

[Quantlib-dev] A few suggestions...

[Joseph W. <jo...@co...>]

You might want to post something on this thread in Wilmott ...

http://www.wilmott.com/messageview.cfm?catid=10&threadid=32176

and get in contact with user madmax to make sure you aren't duplicating 
each other's work.
(Assuming you aren't madmax).  If you can't get in touch with him, don't 
let that stop you, but I'd like to avoid duplication if possible.

There is a C++ header class in CVS under Processes called 
defaultable.hpp which was a first pass attempt at a defaultable object.  
The idea behind that is to combine that with BlackScholesProcess to 
create an object which represents the defaultable BlackScholesProcess, 
then use that process to calculate the differential operator matrix, 
then put that into the finite difference engines and calculate the value 
of equity options with the possibility of default.

RE: [Quantlib-dev] Credit Derivatives

[Toyin A. <toy...@ho...>]

Hi Naoufel,

Welcome to the club.

Looking forward in seeing your implementation, this is a much needed 
addition to the QuantLib library.

Best Regards,
Toyin Akin.

>From: Naoufel El Bachir <nao...@ya...>
>To: qua...@li...
>Subject: [Quantlib-dev] Credit Derivatives
>Date: Tue, 11 Oct 2005 01:00:01 +0100 (BST)
>
>Hi,
>
>I have just subscribed to this mailing list. I am a PhD student in Finance 
>working on default correlation modeling with stochastic default 
>intensities. I have been learning C++ for the last 2-2.5 years.
>
>I am interested in extending Quantlib for Credit Derivatives. For a start, 
>I was thinking about writing code for CDS, term structures of default 
>intensities, defaultable bonds, other related stuff, CDS options (Black 
>type formula with term structure of default intensities + some short rate 
>models for the default intensities...) and CDO tranches. I already have 
>some pieces here and there.
>
>I will start working on a proposal next week, and keep you posted on 
>progress. Any suggestions or ideas are welcome.
>
>Naoufel
>
>
>
>---------------------------------
>Yahoo! Messenger  NEW - crystal clear PC to PC calling worldwide with 
>voicemail

[Quantlib-dev] Credit Derivatives

[Naoufel El B. <nao...@ya...>]

Hi,
 
I have just subscribed to this mailing list. I am a PhD student in Finance working on default correlation modeling with stochastic default intensities. I have been learning C++ for the last 2-2.5 years.
 
I am interested in extending Quantlib for Credit Derivatives. For a start, I was thinking about writing code for CDS, term structures of default intensities, defaultable bonds, other related stuff, CDS options (Black type formula with term structure of default intensities + some short rate models for the default intensities...) and CDO tranches. I already have some pieces here and there.
 
I will start working on a proposal next week, and keep you posted on progress. Any suggestions or ideas are welcome.
 
Naoufel


		
---------------------------------
Yahoo! Messenger  NEW - crystal clear PC to PC calling worldwide with voicemail 

Re: [Quantlib-dev] Hold your horses... Bermudan pricing / MCAmericanBasketEngine / LSMC!

[Toyin A. <toy...@ho...>]

Hi Luigi,

As I understand it, the state variable is not actually the short rate itself 
and thus I suspect there may be intermediate steps involved in order to go 
from this to the rate itself.

I've been looking at the MonteCarlo, Processes and the Shortratemodel 
framework for the last 2 days now in order to determine the best way to 
achieve this goal, but I haven't actually fully comprehended the 
relationships between these classes.

Correlated paths may be an issue as well.

Do you think it would be possible to add an utility class (possibly with 
static functions) that given a stochatic interest rate model, it can simply 
generate an array of sample paths?

Or maybe provide a quick dirty example of how this can be done.

I know you are a busy guy...

Best Regards,
Toyin Akin.

>From: Luigi Ballabio <lui...@gm...>
>To: Toyin Akin <toy...@ho...>
>CC: mar...@li..., 
>qua...@li...,qua...@li...
>Subject: Re: [Quantlib-dev] Hold your horses... Bermudan pricing / 
>MCAmericanBasketEngine / LSMC!
>Date: Mon, 10 Oct 2005 15:20:34 +0000
>
>
>On 10/10/2005 05:02:31 PM, Toyin Akin wrote:
>>
>>One of the reasons why I was looking at this class is that  theorectically 
>>the logic enables you to perform American/Bermudan  pricing within a 
>>montecarlo framework via the LSMC method
>>(Least Squares Monte carlo).
>
>Yes---but I think the code should be heavily optimized.
>
>>However as the QuantLib code stands, I don't know if there is an easy  way 
>>to simply produce random paths of rates that follows one of the  Interest 
>>rate stochastic models.
>>
>>I know that the MonteCarlo code caters for classes within the  processes 
>>directory, but I'm not too sure about the classes within  the 
>>ShortRateModels folder.
>
>Given a OneFactorModel instance, model->dynamics()->process() gives you  
>the process followed by the underlying state variable. It should be  
>possible to pass it to the Monte Carlo framework. The same applies  (with a 
>few more methods to call) to TwoFactorModel.
>
>Later,
>	Luigi
>
>----------------------------------------
>
>This gubblick contains many nonsklarkish English flutzpahs, but the
>overall pluggandisp can be glorked from context.
>-- David Moser
>

Re: [Quantlib-dev] Hold your horses... Bermudan pricing / MCAmericanBasketEngine / LSMC!

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

On 10/10/2005 05:02:31 PM, Toyin Akin wrote:
>=20
> One of the reasons why I was looking at this class is that =20
> theorectically the logic enables you to perform American/Bermudan =20
> pricing within a montecarlo framework via the LSMC method
> (Least Squares Monte carlo).

Yes---but I think the code should be heavily optimized.

> However as the QuantLib code stands, I don't know if there is an easy =20
> way to simply produce random paths of rates that follows one of the =20
> Interest rate stochastic models.
>=20
> I know that the MonteCarlo code caters for classes within the =20
> processes directory, but I'm not too sure about the classes within =20
> the ShortRateModels folder.

Given a OneFactorModel instance, model->dynamics()->process() gives you =20
the process followed by the underlying state variable. It should be =20
possible to pass it to the Monte Carlo framework. The same applies =20
(with a few more methods to call) to TwoFactorModel.

Later,
	Luigi

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

This gubblick contains many nonsklarkish English flutzpahs, but the
overall pluggandisp can be glorked from context.
-- David Moser

[Quantlib-dev] Hold your horses... Bermudan pricing / MCAmericanBasketEngine / LSMC!

[Toyin A. <toy...@ho...>]

Hi,

Looks like the problem involving the MCAmericanBasketEngine class is being 
handled.
Thanks guys.

One of the reasons why I was looking at this class is that theorectically 
the logic enables you to
perform American/Bermudan pricing within a montecarlo framework via the LSMC 
method
(Least Squares Monte carlo).

The logic within this class caters only for American options on equity, but 
I was just wondering how much work it would take to convert this into a 
Bermudan pricer with Interest rate models.

Thus simulate rates (2 rates in this case if the underlying is a FLT/FLT 
swap) via Hullwhite, BK, HL G2++ etc... and then apply the LSMC logic to 
price Bermudans.

With such a methodology in place, you can price quite a few structured deals 
with a large number of factors, ie Bermudans on Quanto Basis Swaps, which 
requires 3 underlying models, at least, in order to price this deal. One 
each for the legs and one for the FX component. Forget using a Tree.

There are papers (ie Tiley) reporting that the results are quite good and 
it's quite a general procedure.

FinancialCAD uses this methodology in pricing not only exotic Bermudan 
swaptions but other tpyes of Interest rate products that have callable 
provisions with a high number of underlying models.

However as the QuantLib code stands, I don't know if there is an easy way to 
simply produce random paths of rates that follows one of the Interest rate 
stochastic models.

I know that the MonteCarlo code caters for classes within the processes 
directory, but I'm not too sure about the classes within the ShortRateModels 
folder.

Can I simply ask for the Montecarlo class to spit out the simulated rates 
from a HullWhite model for example?

Or another way to look at it is how easy is it to generate an array of the 
simulated movement of rates from an interest rate model?

If so, how easy is this to do?

Best Regards,
Toyin Akin.


>From: "marco\.tarenghi\@libero\.it" <mar...@li...>
>To: "toyin_akin" <toy...@ho...>
>CC: "quantlib-users" <qua...@li...>,"quantlib-dev" 
><qua...@li...>
>Subject: RE: [Quantlib-dev] RE: R: [Quantlib-users] Credit default pricing 
>/ G2++ model
>Date: Mon, 10 Oct 2005 10:49:51 +0200
>
>Hi Toyin,
>as you said, the procedure is the one described in Chapter 11 of the 
>Brigo-Mercurio book: I think you should model the two curves using 2 
>different G2 models.
>The problem is that when pricing options with bermudan features you need 
>trees: every G2 model implies a tridimensional tree but I think that you 
>cannot let the two processes evolve on the same tree since each tree (and 
>in particular the number of nodes at each time step) depends on the model 
>parameters.
>I don't know which is the best way to proceed, but I'll think a little bit 
>about that.
>Let me know if you find some hint.
>
>Marco
>---------- Initial Header -----------
>
>From      : qua...@li...
>To          : 
>qua...@li...,qua...@li...
>Cc          :
>Date      : Fri, 07 Oct 2005 18:52:24 +0100
>Subject : RE: [Quantlib-dev] RE: R: [Quantlib-users] Credit default pricing 
>/ G2++ model
>
>
>
>
>
>
>
> >
> > Hi,
> >
> > Concerning the Bermudan FLT/FLT swap (or bermudan basis swaption) 
>assuming
> > one leg is based on a LIBOR curve and the other on a BASIS curve, how 
>does
> > one refer to each individual curve within a DiscretizedAsset class 
>(assuming
> > that one wants to model the code similar to that of the DiscretizedSwap
> > class). Or is the infrastructure only suitable for only refering to a 
>single
> > curve.
> >
> > It looks like you need to model two G2++ objects and their joint 
>dynamics.
> >
> > Probably the logic presented within the beginning of Chapter 11 of
> > Brigo-Mercurio.
> >
> > Best Regards,
> > Toyin Akin.
> >
> >
> > >From: "Toyin Akin" <toy...@ho...>
> > >To: 
>qua...@li...,qua...@li...
> > >Subject: RE: [Quantlib-dev] RE: R: [Quantlib-users] Credit default 
>pricing
> > >/ G2++ model
> > >Date: Fri, 07 Oct 2005 17:21:56 +0100
> > >
> > >
> > >Hi Marco,
> > >
> > >Ignore my comments on bermudan swaptions on FLT/FLT swaps where both 
>legs
> > >are of the same currency. This can be defined, as you said, within a 
>new
> > >class inherited from the DiscretizedOption class if pricing via the 
>Tree.
> > >
> > >However can the same be said with FLT/FLT swaps with different 
>currencies
> > >on each leg (including exchange of notionals)?
> > >
> > >Best Regards,
> > >Toyin akin.
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >>From: "Toyin Akin" <toy...@ho...>
> > >>To:
> > 
> >>qua...@li...,qua...@li...
> > >>Subject: [Quantlib-dev] RE: R: [Quantlib-users] Credit default pricing 
>/
> > >>G2++ model
> > >>Date: Fri, 07 Oct 2005 08:54:53 +0100
> > >>
> > >>
> > >>Hi Marco,
> > >>
> > >>I too deduced that the main implementation was on page 149, but the
> > >>formula for M(0,T) is on pg 144. Thus I was refering just to this 
>piece of
> > >>code.
> > >>
> > >>Thankyou for the explanation. I just wanted to know where the
> > >>simplification came from and now I know.
> > >>
> > >>As for the pricing of Bermudan swaptions on FLT/FLT swaps, surely some
> > >>modifications will need to be done within the G2++ class?
> > >>
> > >>In fact you would have 2 sets of logic, one for FLT/FLT (same 
>currencies)
> > >>and one for FLT/FLT (different currencies). Or am I missing 
>something...?
> > >>
> > >>A G2++ model is perfect for pricing bermudan options on swaps, where 
>the
> > >>swaps have differing currency legs.
> > >>
> > >>Thankyou again,
> > >>Best Regards,
> > >>Toyin Akin.
> > >>
> > >>>From: "Tarenghi Marco" <mar...@ba...>
> > >>>To: "Toyin Akin" <toy...@ho...>
> > >>>Subject: R: [Quantlib-users] Credit default pricing / G2++ model
> > >>>Date: Fri, 7 Oct 2005 09:01:17 +0200
> > >>>
> > >>>
> > >>>Hi Toyin,
> > >>>for what concerning the implementation of the G2++ model, I have 
>tested
> > >>>the QuantLib functions and I think they work quite well. The formulas 
>in
> > >>>G2::SwaptionPricingFunction class you are referring to are those on 
>page
> > >>>149 of the Brigo-Mercurio book and not those on page 144.
> > >>>Anyway they use the formulas on page 144, since mux_ = -M(0,T): the 
>fact
> > >>>is that the expression of mux_ is obtained using the formulas on page 
>144
> > >>>but simply setting s=0 and t=T, so that the expression simplifies a 
>lot.
> > >>>
> > >>>I hope I have been clear enough.
> > >>>
> > >>>Also, you are right: this class can price only vanilla options.
> > >>>Bermudan and/or amortizing swaptions can be priced using trees, and 
>these
> > >>>are available in the G2 class: what you have to do is to implement a 
>new
> > >>>Swaption class which has to derive from the DiscretizedOption class.
> > >>>
> > >>>Sorry for answering directly to you and not to the mailing list but I
> > >>>cannot do it with my office pc...
> > >>>I should do it from home
> > >>>
> > >>>Best regards,
> > >>>Marco
> > >>>
> > >>>-----Messaggio originale-----
> > >>>Da: qua...@li...
> > >>>[mailto:qua...@li...]Per conto di Toyin
> > >>>Akin
> > >>>Inviato: giovedì 6 ottobre 2005 17:26
> > >>>A: lui...@gm...; qua...@li...
> > >>>Oggetto: [Quantlib-users] Credit default pricing / G2++ model
> > >>>
> > >>>
> > >>>
> > >>>Hi folks,
> > >>>
> > >>>Are there any plans to implement credit default swaps/options within
> > >>>QuantLib?
> > >>>
> > >>>I read somewhere, within one of the wilmott forums, that someone did
> > >>>actually have some working code. However I'm not too sure whether 
>they
> > >>>are
> > >>>going to dedicate this code to the QuantLib project.
> > >>>
> > >>>I certainly would like to get a good handle on a C++ implementation 
>of
> > >>>Credit derivatives as I'm pretty new to it, however I don't want to 
>start
> > >>>a
> > >>>new credit project which could take months if someone else already 
>has
> > >>>some
> > >>>working code.
> > >>>
> > >>>Also, I am stepping through the code of the G2++ model, comparing the
> > >>>math
> > >>>there to that of the Brigo-Mercurio book and all seems well apart 
>from
> > >>>one
> > >>>expression that I can't get my head around.
> > >>>
> > >>>This concerns the code within the constructor of the
> > >>>G2::SwaptionPricingFunction class.
> > >>>
> > >>>There are expressions for mux_ and muy_ which I believe corresponds 
>to
> > >>>the
> > >>>same expressions at the bottom of page 144.
> > >>>
> > >>>Taking just the mux_ expression, for example, I cannot match up the
> > >>>expressions within the book to that of the code. It's the 2nd and 3rd
> > >>>expressions of the formula (according to the book) that I am having 
>some
> > >>>trouble matching up.
> > >>>
> > >>>Can someone confirm that the code here is correct and it's just a 
>case of
> > >>>some smart mathematical  manipulation (My brain has already died 
>after
> > >>>validating all the other parts of the G2 model!!).
> > >>>
> > >>>Also from my analysis, it looks like we can only price options on 
>vanilla
> > >>>swaptions under this G2++ implementation, no variation of notionals
> > >>>(amortisation), coupons, or margins (spreads). This should be 
>possible
> > >>>but I
> > >>>believe that the limiting factor is because it is based on a 
>SimpleSwap
> > >>>object which does not allow for such rich definitions of a swap.
> > >>>
> > >>>Also, does anyone know what code changes would be needed to implement 
>a
> > >>>bermudan swaption on a FLT/FLT swap? I don't think that the
> > >>>SwaptionPricingFunction class is valid for this type of structure.
> > >>>
> > >>>Very good clean code by the way...
> > >>>
> > >>>Best Regards,
> > >>>Toyin Akin.
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>DISCLAIMER:
> > >>>Privileged/Confidential Information may be contained in this message 
>and
> > >>>in any of its attachments (the "message"). If you are not the 
>addressee
> > >>>indicated in this message (or responsible for delivery of the message 
>to
> > >>>such person), you may not copy or deliver this message to anyone. In 
>such
> > >>>case, you should destroy this message and kindly notify the sender by
> > >>>reply e-mail. The contents of this message shall be understood as 
>neither
> > >>>given nor endorsed by Banca Profilo S.p.A., nor Profilo Real Estate 
>SGR
> > >>>S.p.A., nor Profilo Asset Management SGR S.p.A., nor Profilo Academy
> > >>>S.p.A.. Banca Profilo S.p.A., Profilo Real Estate SGR S.p.A., Profilo
> > >>>Asset Management SGR S.p.A., Profilo Academy S.p.A. do not accept
> > >>>liability for corruption, interception or amendment, if any, or the
> > >>>consequences thereof.
> > >>>Il presente messaggio e/o i suoi allegati (di seguito il "messaggio")
> > >>>possono contenere informazioni privilegiate e/o confidenziali. Se non
> > >>>siete i destinatari indicati nel messaggio (o persona incaricata di
> > >>>inoltrare il messaggio al/i destinatario/i), non potete copiare o
> > >>>inoltrare il messaggio ad altri e siete invitati a distruggerlo 
>dandone
> > >>>informazione al mittente a mezzo e-mail. Il contenuto del presente
> > >>>messaggio non deve essere considerato come trasmesso o autorizzato nè 
>da
> > >>>Banca Profilo S.p.A., nè da Profilo Real Estate SGR S.p.A., nè da 
>Profilo
> > >>>Asset Management SGR S.p.A., nè da Profilo Academy S.p.A.. Nè Banca
> > >>>Profilo S.p.A., nè Profilo Real Estate SGR S.p.A., nè Profilo Asset
> > >>>Management SGR S.p.A., nè Profilo Academy S.p.A. si assumono alcuna
> > >>>responsabilità per eventuali intercettazioni, modifiche o 
>danneggiamenti
> > >>>del presente messaggio e-mail e per le eventuali conseguenze.
> > >>
> > >>
> > >>
> > >>
> > >>-------------------------------------------------------
> > >>This SF.Net email is sponsored by:
> > >>Power Architecture Resource Center: Free content, downloads, 
>discussions,
> > >>and more. http://solutions.newsforge.com/ibmarch.tmpl
> > >>_______________________________________________
> > >>Quantlib-dev mailing list
> > >>Qua...@li...
> > >>https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> > >
> > >
> > >
> > >
> > >-------------------------------------------------------
> > >This SF.Net email is sponsored by:
> > >Power Architecture Resource Center: Free content, downloads, 
>discussions,
> > >and more. http://solutions.newsforge.com/ibmarch.tmpl
> > >_______________________________________________
> > >Quantlib-dev mailing list
> > >Qua...@li...
> > >https://lists.sourceforge.net/lists/listinfo/quantlib-dev
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by:
> > Power Architecture Resource Center: Free content, downloads, 
>discussions,
> > and more. http://solutions.newsforge.com/ibmarch.tmpl
> > _______________________________________________
> > Quantlib-users mailing list
> > Qua...@li...
> > https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >
>

[Quantlib-dev] [ quantlib-Bugs-1304830 ] Compiling on Mac OS X 10.4.2 fails

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

Bugs item #1304830, was opened at 2005-09-26 15:20
Message generated for change (Comment added) made by akesson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1304830&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
Submitted By: akesson (akesson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiling on Mac OS X 10.4.2 fails

Initial Comment:
Hi there,

I am trying to compile QuantLib 3.10 on my Mac. I get the following
compiler error

ld: warning multiple definitions of symbol ___eprintf

and the compiler is complaining about some other multiple 
definitions. 
Anyone any idea what I am doing wrong ?

Logfile of the make is attached ...

Cheers

Fredrik

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

>Comment By: akesson (akesson)
Date: 2005-10-10 14:41

Message:
Logged In: YES 
user_id=1351881

The --disable-shared part did it for me (thanks for the advice). This
solves the problem I had with multiple definitions of 'core' symbols
from libgcc.

The big question is why the linker tries to link both the static AND
dynamic libgcc when trying to compile the shared libs for QuantLib. 
This can not work ...




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

Comment By: Patrick Klein (paklein)
Date: 2005-10-08 23:59

Message:
Logged In: YES 
user_id=507736

After a little probing, I found that for some reason
calendar.o was being omitted from QuantLib libraries, though
I couldn't tell why from looking at the Makefile's.  The
ugly fix was to list it twice in ql/Makefile:

am_libQuantLib_la_OBJECTS = calendar.lo calendar.lo
currency.lo date.lo 
Don't know why, but that seems to fix it.

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

Comment By: Patrick Klein (paklein)
Date: 2005-10-08 19:44

Message:
Logged In: YES 
user_id=507736

It looks like the configure script is not picking up the
version of 10.4 correctly, and this was causing the wrong
linker flags to be used. I found that if I set

setenv MACOSX_DEPLOYMENT_TARGET 10.4

then re-ran configure, everything built -- except the
examples. I'm trying now with --disable-shared, but I'm
still getting some linker errors.

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

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

[Quantlib-dev] Re: [Quantlib-users] Bug in MCAmericanBasketEngine class

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

On 10/09/2005 08:28:43 PM, Joseph Wang wrote:
> That would also work....  Do you want to add it or should I.

Please go ahead.

> Also, I've been reading up on Monte Carlo.  Chapter 10 of Peter =20
> Jackel's book Monte Carlo Methods in Finance says that antithetic =20
> sampling should not be used with low-discrepency series (especially =20
> Sobol numbers) as it will case interaction effects given that the =20
> quasi-random numbers are also almost antihetic.
> Does this have any impact on the code?

Probably. The antithetic sampling shouldn't be performed no matter =20
what---there should be a flag passed to the engine specifying whether =20
or not it should be enabled.

Later,
	Luigi

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

Steinbach's Guideline for Systems Programming:
	Never test for an error condition you don't know how to handle.

[Quantlib-dev] Re: [Quantlib-users] Question about array.hpp

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

On 10/08/2005 05:31:24 AM, Joseph Wang wrote:
> I was wondering what the design rationale was for creating a new =20
> Array class rather than using or subclassing vector<Real>?

It was to express the concept of an array in the linear-algebra sense, =20
rather than a generic container. Indeed, I shuddered slightly this =20
morning when I saw TridiagonalOperator's methods being applied to =20
generic containers :) I'm not sure that I like it.
Also, it allowed us to write things like operator*(Matrix,Array) which, =20
being specific for linear algebram I wouldn't add to std::vector's =20
interface.

Later,
	Luigi

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

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

[Quantlib-dev] Re: [Quantlib-users] Bug in MCAmericanBasketEngine class

[Joseph W. <jo...@co...>]

That would also work....  Do you want to add it or should I.

I've also added a test to the test suite that replacates the crash which 
I can check in once the fix is in place.

Also, I've been reading up on Monte Carlo.  Chapter 10 of Peter Jackel's 
book Monte Carlo Methods in Finance says that antithetic sampling should 
not be used with low-discrepency series (especially Sobol numbers) as it 
will case interaction effects given that the quasi-random numbers are 
also almost antihetic. 

Does this have any impact on the code?


Luigi Ballabio wrote:

>
> On Oct 9, 2005, at 6:12 PM, Joseph Wang wrote:
>
>> Can you add the following lines and see if it fixes things....
>>
>>        std::vector<MultiPath> multipaths(N);
>>        for (i=0; i<N/2; i++) {
>>            multipaths[i] = multipathGenerator->next().value;
>>            multipaths[N/2+i] = multipathGenerator->antithetic().value;
>>        }
>>        // Add an extra path if N is odd
>>        if (N % 2 == 1) {
>>            multipaths[N-1] = multipathGenerator->next().value;
>>        }
>
>
> Isn't it enough to make N even if it's not? At its declaration site, 
> you can write:
>
> Size N = requiredSamples_ + (requiredSamples_ % 2);
>
> Luigi
>

[Quantlib-dev] Re: [Quantlib-users] Bug in MCAmericanBasketEngine class

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

On Oct 9, 2005, at 6:12 PM, Joseph Wang wrote:

> Can you add the following lines and see if it fixes things....
>
>        std::vector<MultiPath> multipaths(N);
>        for (i=0; i<N/2; i++) {
>            multipaths[i] = multipathGenerator->next().value;
>            multipaths[N/2+i] = multipathGenerator->antithetic().value;
>        }
>        // Add an extra path if N is odd
>        if (N % 2 == 1) {
>            multipaths[N-1] = multipathGenerator->next().value;
>        }

Isn't it enough to make N even if it's not? At its declaration site, 
you can write:

Size N = requiredSamples_ + (requiredSamples_ % 2);

Luigi

[Quantlib-dev] Bug in MCAmericanBasketEngine class

[Joseph W. <jo...@co...>]

Can you add the following lines and see if it fixes things....

If it works I'll write a regression test case for it, and check it into CVS.

        std::vector<MultiPath> multipaths(N);
        for (i=0; i<N/2; i++) {
            multipaths[i] = multipathGenerator->next().value;
            multipaths[N/2+i] = multipathGenerator->antithetic().value;
        }
        // Add an extra path if N is odd
        if (N % 2 == 1) {
            multipaths[N-1] = multipathGenerator->next().value;
        }

[Quantlib-dev] [ quantlib-Bugs-1304830 ] Compiling on Mac OS X 10.4.2 fails

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

Bugs item #1304830, was opened at 2005-09-26 06:20
Message generated for change (Comment added) made by paklein
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1304830&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
Submitted By: akesson (akesson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiling on Mac OS X 10.4.2 fails

Initial Comment:
Hi there,

I am trying to compile QuantLib 3.10 on my Mac. I get the following
compiler error

ld: warning multiple definitions of symbol ___eprintf

and the compiler is complaining about some other multiple 
definitions. 
Anyone any idea what I am doing wrong ?

Logfile of the make is attached ...

Cheers

Fredrik

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

Comment By: Patrick Klein (paklein)
Date: 2005-10-08 14:59

Message:
Logged In: YES 
user_id=507736

After a little probing, I found that for some reason
calendar.o was being omitted from QuantLib libraries, though
I couldn't tell why from looking at the Makefile's.  The
ugly fix was to list it twice in ql/Makefile:

am_libQuantLib_la_OBJECTS = calendar.lo calendar.lo
currency.lo date.lo 
Don't know why, but that seems to fix it.

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

Comment By: Patrick Klein (paklein)
Date: 2005-10-08 10:44

Message:
Logged In: YES 
user_id=507736

It looks like the configure script is not picking up the
version of 10.4 correctly, and this was causing the wrong
linker flags to be used. I found that if I set

setenv MACOSX_DEPLOYMENT_TARGET 10.4

then re-ran configure, everything built -- except the
examples. I'm trying now with --disable-shared, but I'm
still getting some linker errors.

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

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

Re: [Quantlib-dev] Checked in quantlib-perl

[Dirk E. <ed...@de...>]

On 8 October 2005 at 23:11, Ferdinando Ametrano wrote:
| On 10/4/05, Joseph Wang <jo...@co...> wrote:
| >
| > I see there are experimental SWIG interfaces for clisp and R.
| >
| 
| this would be VERY interesting for me. Any pointers to R SWIG stuff?

Scroll forward two or three messages and you see me asking the same question,
Luigi (who else :) answering and me giving two more cents worth of comments
based on that find.   

Short answer:  http://www.omegahat.org/RSWIG/ and you'll to patch Swig.

Dirk

-- 
Statistics: The (futile) attempt to offer certainty about uncertainty.
         -- Roger Koenker, 'Dictionary of Received Ideas of Statistics'

Re: [Quantlib-dev] Checked in quantlib-perl

[Ferdinando A. <na...@am...>]

On 10/4/05, Joseph Wang <jo...@co...> wrote:
>
> I see there are experimental SWIG interfaces for clisp and R.
>

this would be VERY interesting for me. Any pointers to R SWIG stuff?

thank you

ciao-- Nando

[Quantlib-dev] [ quantlib-Bugs-1304830 ] Compiling on Mac OS X 10.4.2 fails

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

Bugs item #1304830, was opened at 2005-09-26 06:20
Message generated for change (Comment added) made by paklein
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1304830&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
Submitted By: akesson (akesson)
Assigned to: Nobody/Anonymous (nobody)
Summary: Compiling on Mac OS X 10.4.2 fails

Initial Comment:
Hi there,

I am trying to compile QuantLib 3.10 on my Mac. I get the following
compiler error

ld: warning multiple definitions of symbol ___eprintf

and the compiler is complaining about some other multiple 
definitions. 
Anyone any idea what I am doing wrong ?

Logfile of the make is attached ...

Cheers

Fredrik

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

Comment By: Patrick Klein (paklein)
Date: 2005-10-08 10:44

Message:
Logged In: YES 
user_id=507736

It looks like the configure script is not picking up the
version of 10.4 correctly, and this was causing the wrong
linker flags to be used. I found that if I set

setenv MACOSX_DEPLOYMENT_TARGET 10.4

then re-ran configure, everything built -- except the
examples. I'm trying now with --disable-shared, but I'm
still getting some linker errors.

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

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

[Quantlib-dev] Bug in MCAmericanBasketEngine class

[Toyin A. <toy...@ho...>]

Hi,

Seems to crash if you specify an odd number (ie - 5) for the required sample 
size parameter of the constructor.

I've tracked it down to line 445, the crash actually happens on line 458.

Seems like the logic for filling in the array is flawed when an odd number 
is specified (greater than 1).

Best Regards,
Toyin Akin.

[Quantlib-dev] Question about array.hpp

[Joseph W. <jo...@co...>]

I was wondering what the design rationale was for creating a new Array 
class rather than using or subclassing vector<Real>?

Just curious.

RE: [Quantlib-dev] RE: R: [Quantlib-users] Credit default pricing / G2++ model

[Toyin A. <toy...@ho...>]

Hi,

Concerning the Bermudan FLT/FLT swap (or bermudan basis swaption) assuming 
one leg is based on a LIBOR curve and the other on a BASIS curve, how does 
one refer to each individual curve within a DiscretizedAsset class (assuming 
that one wants to model the code similar to that of the DiscretizedSwap 
class). Or is the infrastructure only suitable for only refering to a single 
curve.

It looks like you need to model two G2++ objects and their joint dynamics.

Probably the logic presented within the beginning of Chapter 11 of 
Brigo-Mercurio.

Best Regards,
Toyin Akin.


>From: "Toyin Akin" <toy...@ho...>
>To: qua...@li...,qua...@li...
>Subject: RE: [Quantlib-dev] RE: R: [Quantlib-users] Credit default pricing 
>/ G2++ model
>Date: Fri, 07 Oct 2005 17:21:56 +0100
>
>
>Hi Marco,
>
>Ignore my comments on bermudan swaptions on FLT/FLT swaps where both legs 
>are of the same currency. This can be defined, as you said, within a new 
>class inherited from the DiscretizedOption class if pricing via the Tree.
>
>However can the same be said with FLT/FLT swaps with different currencies 
>on each leg (including exchange of notionals)?
>
>Best Regards,
>Toyin akin.
>
>
>
>
>
>
>
>>From: "Toyin Akin" <toy...@ho...>
>>To: 
>>qua...@li...,qua...@li...
>>Subject: [Quantlib-dev] RE: R: [Quantlib-users] Credit default pricing / 
>>G2++ model
>>Date: Fri, 07 Oct 2005 08:54:53 +0100
>>
>>
>>Hi Marco,
>>
>>I too deduced that the main implementation was on page 149, but the 
>>formula for M(0,T) is on pg 144. Thus I was refering just to this piece of 
>>code.
>>
>>Thankyou for the explanation. I just wanted to know where the 
>>simplification came from and now I know.
>>
>>As for the pricing of Bermudan swaptions on FLT/FLT swaps, surely some 
>>modifications will need to be done within the G2++ class?
>>
>>In fact you would have 2 sets of logic, one for FLT/FLT (same currencies) 
>>and one for FLT/FLT (different currencies). Or am I missing something...?
>>
>>A G2++ model is perfect for pricing bermudan options on swaps, where the 
>>swaps have differing currency legs.
>>
>>Thankyou again,
>>Best Regards,
>>Toyin Akin.
>>
>>>From: "Tarenghi Marco" <mar...@ba...>
>>>To: "Toyin Akin" <toy...@ho...>
>>>Subject: R: [Quantlib-users] Credit default pricing / G2++ model
>>>Date: Fri, 7 Oct 2005 09:01:17 +0200
>>>
>>>
>>>Hi Toyin,
>>>for what concerning the implementation of the G2++ model, I have tested 
>>>the QuantLib functions and I think they work quite well. The formulas in 
>>>G2::SwaptionPricingFunction class you are referring to are those on page 
>>>149 of the Brigo-Mercurio book and not those on page 144.
>>>Anyway they use the formulas on page 144, since mux_ = -M(0,T): the fact 
>>>is that the expression of mux_ is obtained using the formulas on page 144 
>>>but simply setting s=0 and t=T, so that the expression simplifies a lot.
>>>
>>>I hope I have been clear enough.
>>>
>>>Also, you are right: this class can price only vanilla options.
>>>Bermudan and/or amortizing swaptions can be priced using trees, and these 
>>>are available in the G2 class: what you have to do is to implement a new 
>>>Swaption class which has to derive from the DiscretizedOption class.
>>>
>>>Sorry for answering directly to you and not to the mailing list but I 
>>>cannot do it with my office pc...
>>>I should do it from home
>>>
>>>Best regards,
>>>Marco
>>>
>>>-----Messaggio originale-----
>>>Da: qua...@li...
>>>[mailto:qua...@li...]Per conto di Toyin
>>>Akin
>>>Inviato: giovedì 6 ottobre 2005 17:26
>>>A: lui...@gm...; qua...@li...
>>>Oggetto: [Quantlib-users] Credit default pricing / G2++ model
>>>
>>>
>>>
>>>Hi folks,
>>>
>>>Are there any plans to implement credit default swaps/options within
>>>QuantLib?
>>>
>>>I read somewhere, within one of the wilmott forums, that someone did
>>>actually have some working code. However I'm not too sure whether they 
>>>are
>>>going to dedicate this code to the QuantLib project.
>>>
>>>I certainly would like to get a good handle on a C++ implementation of
>>>Credit derivatives as I'm pretty new to it, however I don't want to start 
>>>a
>>>new credit project which could take months if someone else already has 
>>>some
>>>working code.
>>>
>>>Also, I am stepping through the code of the G2++ model, comparing the 
>>>math
>>>there to that of the Brigo-Mercurio book and all seems well apart from 
>>>one
>>>expression that I can't get my head around.
>>>
>>>This concerns the code within the constructor of the
>>>G2::SwaptionPricingFunction class.
>>>
>>>There are expressions for mux_ and muy_ which I believe corresponds to 
>>>the
>>>same expressions at the bottom of page 144.
>>>
>>>Taking just the mux_ expression, for example, I cannot match up the
>>>expressions within the book to that of the code. It's the 2nd and 3rd
>>>expressions of the formula (according to the book) that I am having some
>>>trouble matching up.
>>>
>>>Can someone confirm that the code here is correct and it's just a case of
>>>some smart mathematical  manipulation (My brain has already died after
>>>validating all the other parts of the G2 model!!).
>>>
>>>Also from my analysis, it looks like we can only price options on vanilla
>>>swaptions under this G2++ implementation, no variation of notionals
>>>(amortisation), coupons, or margins (spreads). This should be possible 
>>>but I
>>>believe that the limiting factor is because it is based on a SimpleSwap
>>>object which does not allow for such rich definitions of a swap.
>>>
>>>Also, does anyone know what code changes would be needed to implement a
>>>bermudan swaption on a FLT/FLT swap? I don't think that the
>>>SwaptionPricingFunction class is valid for this type of structure.
>>>
>>>Very good clean code by the way...
>>>
>>>Best Regards,
>>>Toyin Akin.
>>>
>>>
>>>
>>>
>>>
>>>DISCLAIMER:
>>>Privileged/Confidential Information may be contained in this message and 
>>>in any of its attachments (the "message"). If you are not the addressee 
>>>indicated in this message (or responsible for delivery of the message to 
>>>such person), you may not copy or deliver this message to anyone. In such 
>>>case, you should destroy this message and kindly notify the sender by 
>>>reply e-mail. The contents of this message shall be understood as neither 
>>>given nor endorsed by Banca Profilo S.p.A., nor Profilo Real Estate SGR 
>>>S.p.A., nor Profilo Asset Management SGR S.p.A., nor Profilo Academy 
>>>S.p.A.. Banca Profilo S.p.A., Profilo Real Estate SGR S.p.A., Profilo 
>>>Asset Management SGR S.p.A., Profilo Academy S.p.A. do not accept 
>>>liability for corruption, interception or amendment, if any, or the 
>>>consequences thereof.
>>>Il presente messaggio e/o i suoi allegati (di seguito il "messaggio") 
>>>possono contenere informazioni privilegiate e/o confidenziali. Se non 
>>>siete i destinatari indicati nel messaggio (o persona incaricata di 
>>>inoltrare il messaggio al/i destinatario/i), non potete copiare o 
>>>inoltrare il messaggio ad altri e siete invitati a distruggerlo dandone 
>>>informazione al mittente a mezzo e-mail. Il contenuto del presente 
>>>messaggio non deve essere considerato come trasmesso o autorizzato nè da 
>>>Banca Profilo S.p.A., nè da Profilo Real Estate SGR S.p.A., nè da Profilo 
>>>Asset Management SGR S.p.A., nè da Profilo Academy S.p.A.. Nè Banca 
>>>Profilo S.p.A., nè Profilo Real Estate SGR S.p.A., nè Profilo Asset 
>>>Management SGR S.p.A., nè Profilo Academy S.p.A. si assumono alcuna 
>>>responsabilità per eventuali intercettazioni, modifiche o danneggiamenti 
>>>del presente messaggio e-mail e per le eventuali conseguenze.
>>
>>
>>
>>
>>-------------------------------------------------------
>>This SF.Net email is sponsored by:
>>Power Architecture Resource Center: Free content, downloads, discussions,
>>and more. http://solutions.newsforge.com/ibmarch.tmpl
>>_______________________________________________
>>Quantlib-dev mailing list
>>Qua...@li...
>>https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Power Architecture Resource Center: Free content, downloads, discussions,
>and more. http://solutions.newsforge.com/ibmarch.tmpl
>_______________________________________________
>Quantlib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

RE: [Quantlib-dev] RE: R: [Quantlib-users] Credit default pricing / G2++ model

[Toyin A. <toy...@ho...>]

Hi Marco,

Ignore my comments on bermudan swaptions on FLT/FLT swaps where both legs 
are of the same currency. This can be defined, as you said, within a new 
class inherited from the DiscretizedOption class if pricing via the Tree.

However can the same be said with FLT/FLT swaps with different currencies on 
each leg (including exchange of notionals)?

Best Regards,
Toyin akin.







>From: "Toyin Akin" <toy...@ho...>
>To: qua...@li...,qua...@li...
>Subject: [Quantlib-dev] RE: R: [Quantlib-users] Credit default pricing / 
>G2++ model
>Date: Fri, 07 Oct 2005 08:54:53 +0100
>
>
>Hi Marco,
>
>I too deduced that the main implementation was on page 149, but the formula 
>for M(0,T) is on pg 144. Thus I was refering just to this piece of code.
>
>Thankyou for the explanation. I just wanted to know where the 
>simplification came from and now I know.
>
>As for the pricing of Bermudan swaptions on FLT/FLT swaps, surely some 
>modifications will need to be done within the G2++ class?
>
>In fact you would have 2 sets of logic, one for FLT/FLT (same currencies) 
>and one for FLT/FLT (different currencies). Or am I missing something...?
>
>A G2++ model is perfect for pricing bermudan options on swaps, where the 
>swaps have differing currency legs.
>
>Thankyou again,
>Best Regards,
>Toyin Akin.
>
>>From: "Tarenghi Marco" <mar...@ba...>
>>To: "Toyin Akin" <toy...@ho...>
>>Subject: R: [Quantlib-users] Credit default pricing / G2++ model
>>Date: Fri, 7 Oct 2005 09:01:17 +0200
>>
>>
>>Hi Toyin,
>>for what concerning the implementation of the G2++ model, I have tested 
>>the QuantLib functions and I think they work quite well. The formulas in 
>>G2::SwaptionPricingFunction class you are referring to are those on page 
>>149 of the Brigo-Mercurio book and not those on page 144.
>>Anyway they use the formulas on page 144, since mux_ = -M(0,T): the fact 
>>is that the expression of mux_ is obtained using the formulas on page 144 
>>but simply setting s=0 and t=T, so that the expression simplifies a lot.
>>
>>I hope I have been clear enough.
>>
>>Also, you are right: this class can price only vanilla options.
>>Bermudan and/or amortizing swaptions can be priced using trees, and these 
>>are available in the G2 class: what you have to do is to implement a new 
>>Swaption class which has to derive from the DiscretizedOption class.
>>
>>Sorry for answering directly to you and not to the mailing list but I 
>>cannot do it with my office pc...
>>I should do it from home
>>
>>Best regards,
>>Marco
>>
>>-----Messaggio originale-----
>>Da: qua...@li...
>>[mailto:qua...@li...]Per conto di Toyin
>>Akin
>>Inviato: giovedì 6 ottobre 2005 17:26
>>A: lui...@gm...; qua...@li...
>>Oggetto: [Quantlib-users] Credit default pricing / G2++ model
>>
>>
>>
>>Hi folks,
>>
>>Are there any plans to implement credit default swaps/options within
>>QuantLib?
>>
>>I read somewhere, within one of the wilmott forums, that someone did
>>actually have some working code. However I'm not too sure whether they are
>>going to dedicate this code to the QuantLib project.
>>
>>I certainly would like to get a good handle on a C++ implementation of
>>Credit derivatives as I'm pretty new to it, however I don't want to start 
>>a
>>new credit project which could take months if someone else already has 
>>some
>>working code.
>>
>>Also, I am stepping through the code of the G2++ model, comparing the math
>>there to that of the Brigo-Mercurio book and all seems well apart from one
>>expression that I can't get my head around.
>>
>>This concerns the code within the constructor of the
>>G2::SwaptionPricingFunction class.
>>
>>There are expressions for mux_ and muy_ which I believe corresponds to the
>>same expressions at the bottom of page 144.
>>
>>Taking just the mux_ expression, for example, I cannot match up the
>>expressions within the book to that of the code. It's the 2nd and 3rd
>>expressions of the formula (according to the book) that I am having some
>>trouble matching up.
>>
>>Can someone confirm that the code here is correct and it's just a case of
>>some smart mathematical  manipulation (My brain has already died after
>>validating all the other parts of the G2 model!!).
>>
>>Also from my analysis, it looks like we can only price options on vanilla
>>swaptions under this G2++ implementation, no variation of notionals
>>(amortisation), coupons, or margins (spreads). This should be possible but 
>>I
>>believe that the limiting factor is because it is based on a SimpleSwap
>>object which does not allow for such rich definitions of a swap.
>>
>>Also, does anyone know what code changes would be needed to implement a
>>bermudan swaption on a FLT/FLT swap? I don't think that the
>>SwaptionPricingFunction class is valid for this type of structure.
>>
>>Very good clean code by the way...
>>
>>Best Regards,
>>Toyin Akin.
>>
>>
>>
>>
>>
>>DISCLAIMER:
>>Privileged/Confidential Information may be contained in this message and 
>>in any of its attachments (the "message"). If you are not the addressee 
>>indicated in this message (or responsible for delivery of the message to 
>>such person), you may not copy or deliver this message to anyone. In such 
>>case, you should destroy this message and kindly notify the sender by 
>>reply e-mail. The contents of this message shall be understood as neither 
>>given nor endorsed by Banca Profilo S.p.A., nor Profilo Real Estate SGR 
>>S.p.A., nor Profilo Asset Management SGR S.p.A., nor Profilo Academy 
>>S.p.A.. Banca Profilo S.p.A., Profilo Real Estate SGR S.p.A., Profilo 
>>Asset Management SGR S.p.A., Profilo Academy S.p.A. do not accept 
>>liability for corruption, interception or amendment, if any, or the 
>>consequences thereof.
>>Il presente messaggio e/o i suoi allegati (di seguito il "messaggio") 
>>possono contenere informazioni privilegiate e/o confidenziali. Se non 
>>siete i destinatari indicati nel messaggio (o persona incaricata di 
>>inoltrare il messaggio al/i destinatario/i), non potete copiare o 
>>inoltrare il messaggio ad altri e siete invitati a distruggerlo dandone 
>>informazione al mittente a mezzo e-mail. Il contenuto del presente 
>>messaggio non deve essere considerato come trasmesso o autorizzato nè da 
>>Banca Profilo S.p.A., nè da Profilo Real Estate SGR S.p.A., nè da Profilo 
>>Asset Management SGR S.p.A., nè da Profilo Academy S.p.A.. Nè Banca 
>>Profilo S.p.A., nè Profilo Real Estate SGR S.p.A., nè Profilo Asset 
>>Management SGR S.p.A., nè Profilo Academy S.p.A. si assumono alcuna 
>>responsabilità per eventuali intercettazioni, modifiche o danneggiamenti 
>>del presente messaggio e-mail e per le eventuali conseguenze.
>
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by:
>Power Architecture Resource Center: Free content, downloads, discussions,
>and more. http://solutions.newsforge.com/ibmarch.tmpl
>_______________________________________________
>Quantlib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] RE: R: [Quantlib-users] Credit default pricing / G2++ model

[Toyin A. <toy...@ho...>]

Hi Marco,

I too deduced that the main implementation was on page 149, but the formula 
for M(0,T) is on pg 144. Thus I was refering just to this piece of code.

Thankyou for the explanation. I just wanted to know where the simplification 
came from and now I know.

As for the pricing of Bermudan swaptions on FLT/FLT swaps, surely some 
modifications will need to be done within the G2++ class?

In fact you would have 2 sets of logic, one for FLT/FLT (same currencies) 
and one for FLT/FLT (different currencies). Or am I missing something...?

A G2++ model is perfect for pricing bermudan options on swaps, where the 
swaps have differing currency legs.

Thankyou again,
Best Regards,
Toyin Akin.

>From: "Tarenghi Marco" <mar...@ba...>
>To: "Toyin Akin" <toy...@ho...>
>Subject: R: [Quantlib-users] Credit default pricing / G2++ model
>Date: Fri, 7 Oct 2005 09:01:17 +0200
>
>
>Hi Toyin,
>for what concerning the implementation of the G2++ model, I have tested the 
>QuantLib functions and I think they work quite well. The formulas in 
>G2::SwaptionPricingFunction class you are referring to are those on page 
>149 of the Brigo-Mercurio book and not those on page 144.
>Anyway they use the formulas on page 144, since mux_ = -M(0,T): the fact is 
>that the expression of mux_ is obtained using the formulas on page 144 but 
>simply setting s=0 and t=T, so that the expression simplifies a lot.
>
>I hope I have been clear enough.
>
>Also, you are right: this class can price only vanilla options.
>Bermudan and/or amortizing swaptions can be priced using trees, and these 
>are available in the G2 class: what you have to do is to implement a new 
>Swaption class which has to derive from the DiscretizedOption class.
>
>Sorry for answering directly to you and not to the mailing list but I 
>cannot do it with my office pc...
>I should do it from home
>
>Best regards,
>Marco
>
>-----Messaggio originale-----
>Da: qua...@li...
>[mailto:qua...@li...]Per conto di Toyin
>Akin
>Inviato: giovedì 6 ottobre 2005 17:26
>A: lui...@gm...; qua...@li...
>Oggetto: [Quantlib-users] Credit default pricing / G2++ model
>
>
>
>Hi folks,
>
>Are there any plans to implement credit default swaps/options within
>QuantLib?
>
>I read somewhere, within one of the wilmott forums, that someone did
>actually have some working code. However I'm not too sure whether they are
>going to dedicate this code to the QuantLib project.
>
>I certainly would like to get a good handle on a C++ implementation of
>Credit derivatives as I'm pretty new to it, however I don't want to start a
>new credit project which could take months if someone else already has some
>working code.
>
>Also, I am stepping through the code of the G2++ model, comparing the math
>there to that of the Brigo-Mercurio book and all seems well apart from one
>expression that I can't get my head around.
>
>This concerns the code within the constructor of the
>G2::SwaptionPricingFunction class.
>
>There are expressions for mux_ and muy_ which I believe corresponds to the
>same expressions at the bottom of page 144.
>
>Taking just the mux_ expression, for example, I cannot match up the
>expressions within the book to that of the code. It's the 2nd and 3rd
>expressions of the formula (according to the book) that I am having some
>trouble matching up.
>
>Can someone confirm that the code here is correct and it's just a case of
>some smart mathematical  manipulation (My brain has already died after
>validating all the other parts of the G2 model!!).
>
>Also from my analysis, it looks like we can only price options on vanilla
>swaptions under this G2++ implementation, no variation of notionals
>(amortisation), coupons, or margins (spreads). This should be possible but 
>I
>believe that the limiting factor is because it is based on a SimpleSwap
>object which does not allow for such rich definitions of a swap.
>
>Also, does anyone know what code changes would be needed to implement a
>bermudan swaption on a FLT/FLT swap? I don't think that the
>SwaptionPricingFunction class is valid for this type of structure.
>
>Very good clean code by the way...
>
>Best Regards,
>Toyin Akin.
>
>
>
>
>
>DISCLAIMER:
>Privileged/Confidential Information may be contained in this message and in 
>any of its attachments (the "message"). If you are not the addressee 
>indicated in this message (or responsible for delivery of the message to 
>such person), you may not copy or deliver this message to anyone. In such 
>case, you should destroy this message and kindly notify the sender by reply 
>e-mail. The contents of this message shall be understood as neither given 
>nor endorsed by Banca Profilo S.p.A., nor Profilo Real Estate SGR S.p.A., 
>nor Profilo Asset Management SGR S.p.A., nor Profilo Academy S.p.A.. Banca 
>Profilo S.p.A., Profilo Real Estate SGR S.p.A., Profilo Asset Management 
>SGR S.p.A., Profilo Academy S.p.A. do not accept liability for corruption, 
>interception or amendment, if any, or the consequences thereof.
>Il presente messaggio e/o i suoi allegati (di seguito il "messaggio") 
>possono contenere informazioni privilegiate e/o confidenziali. Se non siete 
>i destinatari indicati nel messaggio (o persona incaricata di inoltrare il 
>messaggio al/i destinatario/i), non potete copiare o inoltrare il messaggio 
>ad altri e siete invitati a distruggerlo dandone informazione al mittente a 
>mezzo e-mail. Il contenuto del presente messaggio non deve essere 
>considerato come trasmesso o autorizzato nè da Banca Profilo S.p.A., nè da 
>Profilo Real Estate SGR S.p.A., nè da Profilo Asset Management SGR S.p.A., 
>nè da Profilo Academy S.p.A.. Nè Banca Profilo S.p.A., nè Profilo Real 
>Estate SGR S.p.A., nè Profilo Asset Management SGR S.p.A., nè Profilo 
>Academy S.p.A. si assumono alcuna responsabilità per eventuali 
>intercettazioni, modifiche o danneggiamenti del presente messaggio e-mail e 
>per le eventuali conseguenze.

[Quantlib-dev] [ quantlib-Patches-1297412 ] 0.3.10 : right dsw/dsp

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

Patches item #1297412, was opened at 2005-09-21 10:44
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=1297412&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: Rejected
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: 0.3.10 : right dsw/dsp

Initial Comment:
Directory structure with the correct dsp et dsw;
This is a temporary/immediate solution for bug n° 1297396 


fca...@ya...

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2005-10-06 13:46

Message:
Logged In: YES 
user_id=75450

The corresponding bug report was rejected.

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

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

[Quantlib-dev] [ quantlib-Bugs-1292749 ] error building quantlib-python

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

Bugs item #1292749, was opened at 2005-09-16 12:15
Message generated for change (Settings changed) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1292749&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
Submitted By: Tommy (mesilliac)
>Assigned to: Luigi Ballabio (lballabio)
Summary: error building quantlib-python

Initial Comment:
I'm trying to install quantlib-python on a Gentoo Linux
system. Quantlib itself seems to have built and
installed fine, but when I try to build quantlib-python
(with "python setup.py build" for example) it fails
after outputting the following:

"""

running build
running build_py
creating build
creating build/lib.linux-i686-2.4
creating build/lib.linux-i686-2.4/QuantLib
copying QuantLib/__init__.py ->
build/lib.linux-i686-2.4/QuantLib
copying QuantLib/QuantLib.py ->
build/lib.linux-i686-2.4/QuantLib
running build_ext
building 'QuantLib._QuantLib' extension
creating build/temp.linux-i686-2.4
creating build/temp.linux-i686-2.4/QuantLib
g++ -fno-strict-aliasing -DNDEBUG -O2 -march=i686
-fomit-frame-pointer -fPIC -I/usr/include
-I/usr/include/python2.4 -c QuantLib/quantlib_wrap.cpp
-o build/temp.linux-i686-2.4/QuantLib/quantlib_wrap.o
-Wno-unused -O2 -march=i686 -fomit-frame-pointer
In file included from
/usr/include/ql/PricingEngines/Barrier/all.hpp:24,
                 from
/usr/include/ql/PricingEngines/all.hpp:31,
                 from /usr/include/ql/quantlib.hpp:41,
                 from QuantLib/quantlib_wrap.cpp:1878:
/usr/include/ql/PricingEngines/Barrier/analyticbarrierengine.hpp:56:
error: declaration
   does not declare anything
/usr/include/ql/PricingEngines/Barrier/analyticbarrierengine.hpp:56:
error: syntax
   error before `__asm__'
error: command 'g++' failed with exit status 1

"""

line 56 of analyticbarrierengine.hpp is:

        Real barrier() const;

and I can't see anything obviously wrong with it
(although I'm no good with C or C++).

I'm using python 2.4 and gcc 3.3.6.

it does this with both quantlib-0.3.9 and
quantlib-0.3.10 (haven't tried any other versions).



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

Comment By: Luigi Ballabio (lballabio)
Date: 2005-10-06 13:45

Message:
Logged In: YES 
user_id=75450

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=1292749&group_id=12740