quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] CDS last period

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

Hi all,
    sorry I've been sitting out of this one.  Do go ahead (only one
thing: with regard to the day counter, I'd prefer to have an
additional parameter for the existing day counter, as in
Actual360(IncludeLastDay), rather than an additional day counter).

You're also correct when you say that we'll need some expert to look
at the thing---speaking of which, how comfortable are you with git? If
you forked the QuantLib mirror I've put on github and pushed your
changes there, it would make it easier both to do a code review and to
merge the changes afterwards.  No big deal if you want to just post
here though.

Thanks,
    Luigi

On Tue, Oct 16, 2012 at 8:39 PM, Peter Caspers <pca...@gm...> wrote:
> Hi Pepe,
>
> sure. I'll do the day counter and the last period thing in the fixed
> rate leg and create a new rate helper with accrual rebate. Then we can
> merge. Give me some days.  I want to test against Bloomberg, the Markit
> calculator and perhaps also Murex.
>
> I guess Roland should approve the changes and the way they are done
> before they enter the library.
>
> Regards
> Peter
>
> Am 16.10.2012 12:31, schrieb ja...@fr...:
>> Hi,
>> shall we do anything about this? Do you want to implement the day counter and I can
>> change the engines for the rebate?
>> Can anyone else give an opinion?
>> Best
>> Pepe
>>
>>
>> ----- Mail original -----
>> De: ja...@fr...
>> À: "Peter Caspers" <pca...@gm...>
>> Cc: qua...@li...
>> Envoyé: Mercredi 10 Octobre 2012 18:59:28
>> Objet: Re: [Quantlib-dev] CDS last period
>>
>> Couldnt help it: The conventional spread conversion is a good proxy to check
>> things like the accrual rebate or other features like the one you mentioned
>> initially in this post.
>>
>> Took todays CDS spreads for Portugal and used DEPOSWAPS from today for the TS
>> (should have used yesterday though). These are my figures and Markits quotes:
>>
>> Without and with accrual rebate in both bootstrapping and pricing/conversion:
>>
>>                                      Mkit 5Y conv   QL NoR    QL+Rebt
>> upfront=11   for 5Y lowest bid:         443        439.21    443.38
>> upfront=14.5 for 5Y highest ask:        506        499.28    504.30
>>
>> The correction you propose is still missing. With an artificil fix (adding 1
>> day to the last coupon in the pricing):
>> 443.24
>> 504.15
>>
>> Regards
>> Pepe
>>
>>
>> ----- Mail original -----
>> De: ja...@fr...
>> À: "Peter Caspers" <pca...@gm...>
>> Cc: qua...@li...
>> Envoyé: Mercredi 10 Octobre 2012 13:43:14
>> Objet: Re: [Quantlib-dev] CDS last period
>>
>>
>> Sorry, yes your right settlement is T+3 for upfront and accrual rebate
>> computed to T+1.
>>
>> Yes, thats what I think too. I have my engines patched to bootstrap that way,
>> its not a big change. Small difference yes, still it can be seen as a 3M
>> oscillation.
>>
>> On the way Markit works that was my assumption for the upfront quotes,
>> Markit's 'standard cds contract converter specification' mentions
>> this on p.3, section 'solving for the constant hazard rate'; there it
>> says that the upfront does not include the rebate. So their quotes must
>> be that way.
>> A way to test minimum coherence is to compute with QL the conventional
>> spread Markit quotes alongside and I get agreement or 1bp difference
>> at max (for a ~100bp conventional level of spreads). Which is quite decent
>> considering that it is not rare to see Markit converting the same upfront
>> quote by two sources on the same day to two different conv spreads (by 1bp).
>> Also when I did this I was using the yieldTS from T, not T-1 as the converter
>> mandates. I was not far from the last standard coupon date though, that makes
>> agreement easier; I was too lazy to follow this with time...
>>
>> Best regards
>> Pepe
>>
>>
>> ----- Mail original -----
>> De: "Peter Caspers" <pca...@gm...>
>> À: ja...@fr...
>> Cc: qua...@li...
>> Envoyé: Mardi 9 Octobre 2012 22:00:06
>> Objet: Re: [Quantlib-dev] CDS last period
>>
>> Hi,
>>
>> since the CreditDefaultSwap allows for an arbitrary schedule the accrual
>> rebate can be handled via the upfront amount, i.e. if you provide the
>> dirty upfront amount you get what is standard now, don't you? So no need
>> for an extension unless (and that's what you are probably pointing at?)
>> you want automatic computation of the accrual rebate amount.  Btw I
>> think the upfront payment is usually done on T + 3 open days (not T+1),
>> is that correct?
>>
>> What I planned however is to implement a CDS bootstrap helper which can
>> pay a full first coupon and an accrual rebate (computed from last roll
>> date to T+1) on T+3. In fact the spreads provided by markit are meant
>> using this convention rather than paying a short first coupon, at least
>> some guy working there told me so. Can you validate this? Admittedly
>> this makes only a little difference in the bootstrapped curve in
>> general, but why not do it correctly if you can.
>>
>> Kind regards
>> Peter
>>
>> Am 09.10.2012 13:05, schrieb ja...@fr...:
>>> Hi,
>>> True; your solution looks good, it allows to use it in other places and it allows non-standard CDS
>>> contracts too.
>>>
>>> Also, apparently theres another flow not treated in the CDS. According to the same new rules the accrued
>>> amount on the first coupon is paid by the protection buyer on the coupon payment (or default) date but
>>> it is rebated by the protection seller on T+1 (together with the upfront payment). It would have the
>>> same effect as not paying the initial accrual except for the discount factor (which is at an uncertain
>>> time).
>>>
>>> See:
>>> *The CDS Big Bang: Understanding the Changes to the Global CDS Contract and North American Conventions;
>>> p.18 Markit March 2009
>>> *Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April 2009  p.4
>>> *The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64
>>>
>>> Do you mind having a look on this too, pls? To have someone elses opinion.
>>>
>>> And another related point to the new convention intial accrual is that I have also patched the
>>> constructors moving this:
>>>           QL_REQUIRE(protectionStart_ <= schedule[0],
>>>                      "protection can not start after accrual");
>>> which used to be true in the old convention,
>>> into this:
>>>           QL_REQUIRE((protectionStart_ <= schedule[0])
>>>               || (schedule.rule() == DateGeneration::Rule::CDS),
>>>                      "protection can not start after accrual");
>>> since now it can be the case that the protection period starts before T+1 (actually T-60) but
>>> rather than my hacks it might be better to leave it open completely;
>>>
>>> Best
>>> pp
>>>
>>> ----- Mail original -----
>>> De: "Peter Caspers" <pca...@gm...>
>>> À: qua...@li...
>>> Envoyé: Dimanche 7 Octobre 2012 20:49:53
>>> Objet: [Quantlib-dev] CDS last period
>>>
>>> Hi,
>>>
>>> the days in the last period of a CDS are usually counted as (d2-d1+1),
>>> i.e. including the first and the last date. I might miss something but
>>> this seems not possible in the current implementation of the credit
>>> default swap? This would be my plan to fix that:
>>>
>>> 1.    Implement a new day counter Actual360Inc counting (d2-d1+1) days
>>> 2.    Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method
>>> to FixedRateLeg and extend the Leg() operator accordingly
>>> 3.    Add a parameter const DayCounter& lastPeriodDayCounter =
>>> DayCounter() to the CreditDefaultSwap constructors and invoke
>>> withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
>>> parameter is not empty
>>>
>>> Maybe one could also default the dayCounter to Actual360() and the
>>> lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
>>> constructors already to match the usual use case?
>>>
>>> Does that make sense?
>>>
>>> Thank you
>>> Peter
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------------------------------------------------------------------------
>>> Don't let slow site performance ruin your business. Deploy New Relic APM
>>> Deploy New Relic app performance management and know exactly
>>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>>> http://p.sf.net/sfu/newrelic-dev2dev
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] CDS last period

[Peter C. <pca...@gm...>]

Hi Pepe,

sure. I'll do the day counter and the last period thing in the fixed 
rate leg and create a new rate helper with accrual rebate. Then we can 
merge. Give me some days.  I want to test against Bloomberg, the Markit 
calculator and perhaps also Murex.

I guess Roland should approve the changes and the way they are done 
before they enter the library.

Regards
Peter

Am 16.10.2012 12:31, schrieb ja...@fr...:
> Hi,
> shall we do anything about this? Do you want to implement the day counter and I can
> change the engines for the rebate?
> Can anyone else give an opinion?
> Best
> Pepe
>
>
> ----- Mail original -----
> De: ja...@fr...
> À: "Peter Caspers" <pca...@gm...>
> Cc: qua...@li...
> Envoyé: Mercredi 10 Octobre 2012 18:59:28
> Objet: Re: [Quantlib-dev] CDS last period
>
> Couldnt help it: The conventional spread conversion is a good proxy to check
> things like the accrual rebate or other features like the one you mentioned
> initially in this post.
>
> Took todays CDS spreads for Portugal and used DEPOSWAPS from today for the TS
> (should have used yesterday though). These are my figures and Markits quotes:
>
> Without and with accrual rebate in both bootstrapping and pricing/conversion:
>
>                                      Mkit 5Y conv   QL NoR    QL+Rebt
> upfront=11   for 5Y lowest bid:         443        439.21    443.38
> upfront=14.5 for 5Y highest ask:        506        499.28    504.30
>
> The correction you propose is still missing. With an artificil fix (adding 1
> day to the last coupon in the pricing):
> 443.24
> 504.15
>
> Regards
> Pepe
>
>
> ----- Mail original -----
> De: ja...@fr...
> À: "Peter Caspers" <pca...@gm...>
> Cc: qua...@li...
> Envoyé: Mercredi 10 Octobre 2012 13:43:14
> Objet: Re: [Quantlib-dev] CDS last period
>
>
> Sorry, yes your right settlement is T+3 for upfront and accrual rebate
> computed to T+1.
>
> Yes, thats what I think too. I have my engines patched to bootstrap that way,
> its not a big change. Small difference yes, still it can be seen as a 3M
> oscillation.
>
> On the way Markit works that was my assumption for the upfront quotes,
> Markit's 'standard cds contract converter specification' mentions
> this on p.3, section 'solving for the constant hazard rate'; there it
> says that the upfront does not include the rebate. So their quotes must
> be that way.
> A way to test minimum coherence is to compute with QL the conventional
> spread Markit quotes alongside and I get agreement or 1bp difference
> at max (for a ~100bp conventional level of spreads). Which is quite decent
> considering that it is not rare to see Markit converting the same upfront
> quote by two sources on the same day to two different conv spreads (by 1bp).
> Also when I did this I was using the yieldTS from T, not T-1 as the converter
> mandates. I was not far from the last standard coupon date though, that makes
> agreement easier; I was too lazy to follow this with time...
>
> Best regards
> Pepe
>
>
> ----- Mail original -----
> De: "Peter Caspers" <pca...@gm...>
> À: ja...@fr...
> Cc: qua...@li...
> Envoyé: Mardi 9 Octobre 2012 22:00:06
> Objet: Re: [Quantlib-dev] CDS last period
>
> Hi,
>
> since the CreditDefaultSwap allows for an arbitrary schedule the accrual
> rebate can be handled via the upfront amount, i.e. if you provide the
> dirty upfront amount you get what is standard now, don't you? So no need
> for an extension unless (and that's what you are probably pointing at?)
> you want automatic computation of the accrual rebate amount.  Btw I
> think the upfront payment is usually done on T + 3 open days (not T+1),
> is that correct?
>
> What I planned however is to implement a CDS bootstrap helper which can
> pay a full first coupon and an accrual rebate (computed from last roll
> date to T+1) on T+3. In fact the spreads provided by markit are meant
> using this convention rather than paying a short first coupon, at least
> some guy working there told me so. Can you validate this? Admittedly
> this makes only a little difference in the bootstrapped curve in
> general, but why not do it correctly if you can.
>
> Kind regards
> Peter
>
> Am 09.10.2012 13:05, schrieb ja...@fr...:
>> Hi,
>> True; your solution looks good, it allows to use it in other places and it allows non-standard CDS
>> contracts too.
>>
>> Also, apparently theres another flow not treated in the CDS. According to the same new rules the accrued
>> amount on the first coupon is paid by the protection buyer on the coupon payment (or default) date but
>> it is rebated by the protection seller on T+1 (together with the upfront payment). It would have the
>> same effect as not paying the initial accrual except for the discount factor (which is at an uncertain
>> time).
>>
>> See:
>> *The CDS Big Bang: Understanding the Changes to the Global CDS Contract and North American Conventions;
>> p.18 Markit March 2009
>> *Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April 2009  p.4
>> *The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64
>>
>> Do you mind having a look on this too, pls? To have someone elses opinion.
>>
>> And another related point to the new convention intial accrual is that I have also patched the
>> constructors moving this:
>>           QL_REQUIRE(protectionStart_ <= schedule[0],
>>                      "protection can not start after accrual");
>> which used to be true in the old convention,
>> into this:
>>           QL_REQUIRE((protectionStart_ <= schedule[0])
>>               || (schedule.rule() == DateGeneration::Rule::CDS),
>>                      "protection can not start after accrual");
>> since now it can be the case that the protection period starts before T+1 (actually T-60) but
>> rather than my hacks it might be better to leave it open completely;
>>
>> Best
>> pp
>>
>> ----- Mail original -----
>> De: "Peter Caspers" <pca...@gm...>
>> À: qua...@li...
>> Envoyé: Dimanche 7 Octobre 2012 20:49:53
>> Objet: [Quantlib-dev] CDS last period
>>
>> Hi,
>>
>> the days in the last period of a CDS are usually counted as (d2-d1+1),
>> i.e. including the first and the last date. I might miss something but
>> this seems not possible in the current implementation of the credit
>> default swap? This would be my plan to fix that:
>>
>> 1.    Implement a new day counter Actual360Inc counting (d2-d1+1) days
>> 2.    Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method
>> to FixedRateLeg and extend the Leg() operator accordingly
>> 3.    Add a parameter const DayCounter& lastPeriodDayCounter =
>> DayCounter() to the CreditDefaultSwap constructors and invoke
>> withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
>> parameter is not empty
>>
>> Maybe one could also default the dayCounter to Actual360() and the
>> lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
>> constructors already to match the usual use case?
>>
>> Does that make sense?
>>
>> Thank you
>> Peter
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Don't let slow site performance ruin your business. Deploy New Relic APM
>> Deploy New Relic app performance management and know exactly
>> what is happening inside your Ruby, Python, PHP, Java, and .NET app
>> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
>> http://p.sf.net/sfu/newrelic-dev2dev
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] CDS last period

[<ja...@fr...>]

Hi,
shall we do anything about this? Do you want to implement the day counter and I can 
change the engines for the rebate?
Can anyone else give an opinion?
Best
Pepe


----- Mail original -----
De: ja...@fr...
À: "Peter Caspers" <pca...@gm...>
Cc: qua...@li...
Envoyé: Mercredi 10 Octobre 2012 18:59:28
Objet: Re: [Quantlib-dev] CDS last period

Couldnt help it: The conventional spread conversion is a good proxy to check 
things like the accrual rebate or other features like the one you mentioned 
initially in this post.

Took todays CDS spreads for Portugal and used DEPOSWAPS from today for the TS 
(should have used yesterday though). These are my figures and Markits quotes:

Without and with accrual rebate in both bootstrapping and pricing/conversion:

                                    Mkit 5Y conv   QL NoR    QL+Rebt
upfront=11   for 5Y lowest bid:         443        439.21    443.38
upfront=14.5 for 5Y highest ask:        506        499.28    504.30

The correction you propose is still missing. With an artificil fix (adding 1 
day to the last coupon in the pricing):
443.24
504.15

Regards
Pepe


----- Mail original -----
De: ja...@fr...
À: "Peter Caspers" <pca...@gm...>
Cc: qua...@li...
Envoyé: Mercredi 10 Octobre 2012 13:43:14
Objet: Re: [Quantlib-dev] CDS last period


Sorry, yes your right settlement is T+3 for upfront and accrual rebate 
computed to T+1. 

Yes, thats what I think too. I have my engines patched to bootstrap that way,
its not a big change. Small difference yes, still it can be seen as a 3M 
oscillation.

On the way Markit works that was my assumption for the upfront quotes, 
Markit's 'standard cds contract converter specification' mentions 
this on p.3, section 'solving for the constant hazard rate'; there it 
says that the upfront does not include the rebate. So their quotes must 
be that way.
A way to test minimum coherence is to compute with QL the conventional 
spread Markit quotes alongside and I get agreement or 1bp difference 
at max (for a ~100bp conventional level of spreads). Which is quite decent 
considering that it is not rare to see Markit converting the same upfront 
quote by two sources on the same day to two different conv spreads (by 1bp). 
Also when I did this I was using the yieldTS from T, not T-1 as the converter 
mandates. I was not far from the last standard coupon date though, that makes 
agreement easier; I was too lazy to follow this with time...

Best regards
Pepe


----- Mail original -----
De: "Peter Caspers" <pca...@gm...>
À: ja...@fr...
Cc: qua...@li...
Envoyé: Mardi 9 Octobre 2012 22:00:06
Objet: Re: [Quantlib-dev] CDS last period

Hi,

since the CreditDefaultSwap allows for an arbitrary schedule the accrual 
rebate can be handled via the upfront amount, i.e. if you provide the 
dirty upfront amount you get what is standard now, don't you? So no need 
for an extension unless (and that's what you are probably pointing at?) 
you want automatic computation of the accrual rebate amount.  Btw I 
think the upfront payment is usually done on T + 3 open days (not T+1), 
is that correct?

What I planned however is to implement a CDS bootstrap helper which can 
pay a full first coupon and an accrual rebate (computed from last roll 
date to T+1) on T+3. In fact the spreads provided by markit are meant 
using this convention rather than paying a short first coupon, at least 
some guy working there told me so. Can you validate this? Admittedly 
this makes only a little difference in the bootstrapped curve in 
general, but why not do it correctly if you can.

Kind regards
Peter

Am 09.10.2012 13:05, schrieb ja...@fr...:
> Hi,
> True; your solution looks good, it allows to use it in other places and it allows non-standard CDS
> contracts too.
>
> Also, apparently theres another flow not treated in the CDS. According to the same new rules the accrued
> amount on the first coupon is paid by the protection buyer on the coupon payment (or default) date but
> it is rebated by the protection seller on T+1 (together with the upfront payment). It would have the
> same effect as not paying the initial accrual except for the discount factor (which is at an uncertain
> time).
>
> See:
> *The CDS Big Bang: Understanding the Changes to the Global CDS Contract and North American Conventions;
> p.18 Markit March 2009
> *Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April 2009  p.4
> *The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64
>
> Do you mind having a look on this too, pls? To have someone elses opinion.
>
> And another related point to the new convention intial accrual is that I have also patched the
> constructors moving this:
>          QL_REQUIRE(protectionStart_ <= schedule[0],
>                     "protection can not start after accrual");
> which used to be true in the old convention,
> into this:
>          QL_REQUIRE((protectionStart_ <= schedule[0])
>              || (schedule.rule() == DateGeneration::Rule::CDS),
>                     "protection can not start after accrual");
> since now it can be the case that the protection period starts before T+1 (actually T-60) but
> rather than my hacks it might be better to leave it open completely;
>
> Best
> pp
>
> ----- Mail original -----
> De: "Peter Caspers" <pca...@gm...>
> À: qua...@li...
> Envoyé: Dimanche 7 Octobre 2012 20:49:53
> Objet: [Quantlib-dev] CDS last period
>
> Hi,
>
> the days in the last period of a CDS are usually counted as (d2-d1+1),
> i.e. including the first and the last date. I might miss something but
> this seems not possible in the current implementation of the credit
> default swap? This would be my plan to fix that:
>
> 1.    Implement a new day counter Actual360Inc counting (d2-d1+1) days
> 2.    Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method
> to FixedRateLeg and extend the Leg() operator accordingly
> 3.    Add a parameter const DayCounter& lastPeriodDayCounter =
> DayCounter() to the CreditDefaultSwap constructors and invoke
> withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
> parameter is not empty
>
> Maybe one could also default the dayCounter to Actual360() and the
> lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
> constructors already to match the usual use case?
>
> Does that make sense?
>
> Thank you
> Peter
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev


------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] CAT Bond valuation

[Grześ A. <gan...@gm...>]

Hi,

Thanks for a detailed reply! I will look into it after I come back
from holidays.

Grzegorz

On 10/15/12, Luigi Ballabio <lui...@gm...> wrote:
> Grześ,
>     apologies for the delay.  As I was telling you, there's currently
> no example for coupon amounts calculated in a MC simulation.  If you
> want to go that route, you'll have to:
>
> - write the simulation itself.  There are a number of engines you can
> use as an example, so you should be covered with regards to creating a
> path generator, a path pricer and the several other pieces you'll
> need.  The notable difference in your case is that you'll want to
> return a number of cashflow amounts from the simulation, not a single
> number.  To do that, you'll have to use the second template argument
> of PathPricer: I think all the existing engines use its default (that
> is, Real for a single number) but you'll have to specify that you'll
> return a vector<Real> or something like it.
>
> - link the coupons to the simulation.  Again, there's no code doing
> this yet.  What I'd do is to create a new class inheriting from
> CashFlow and taking a pointer to the MC simulation.  When their
> amount() method is called, instances of this class should ask the
> simulation for the corresponding result.  In turn, this means that a)
> they should know which cashflow they are (the 1st, the 2nd...) among
> those calculated by the simulation and b) the simulation must
> implement some kind of caching to avoid being run several times as the
> Bond class asks its cashflows for their amounts.
>
> The above should keep you busy for a while :)
> Let me know when you need further advice...
>
> Later,
>     Luigi
>
>
> On Thu, Sep 13, 2012 at 5:56 PM, Grześ Andruszkiewicz
> <gan...@gm...> wrote:
>> Hi Luigi,
>>
>> Thanks for a long reply. We were just trying to follow your advice and
>> extend the Bond class, but we found a few potential issues:
>> 1. The Coupon class seems to have a fixed notional, whereas in our
>> case the notional could become smaller as a result of CAT events (that
>> deplete the notional of the CAT bond)
>> 2. The Bond class seems to assume that we can always calculate the
>> coupon amounts (independently for every coupon). I am not sure that
>> this is possible for CAT bonds (i.e. that coupons will be correlated
>> as a result of depleting the notional, catastrophe seasonality, etc.),
>> at least I am not comfortable to assume it at this point.
>> 3. Moreover, we wanted to have a way to price these instruments using
>> Monte Carlo techniques, i.e. use the underlying CAT engine to generate
>> random scenarios of events, given the events calculate the NPV of the
>> bond for every case, and average the results at the end. It is not
>> clear to how to achieve this with the Bond class...
>>
>> Are there other types of instruments in QuantLib with similar
>> characteristics, that we could use as examples?
>>
>> Kind regards,
>> Grzegorz
>>
>> On 31 August 2012 15:45, Luigi Ballabio <lui...@gm...> wrote:
>>> Hi Grześ,
>>>     I'd start by doing the least possible coding :)   Let me elaborate.
>>>
>>> In the architecture of QuantLib, you'll need an instrument class
>>> (describing the contract) and an engine class (doing the actual
>>> pricing).  You can ask your resident expert (hi, Lorenzo) or read
>>> chapter 2 of <https://sites.google.com/site/luigiballabio/>.
>>>
>>> As for the instrument, it is very tempting to inherit it from the
>>> existing Bond class (it's a bond, after all).  In the short term,
>>> that's what I advice.
>>>
>>> In the long term, I'm a bit worried that functions taking a Bond
>>> instance (such as, for instance, BondFunctions::yield, which
>>> calculates the bond yield) would take a CAT bond and do their job like
>>> they do for each other bond; that is, extract its coupons and perform
>>> the yield calculations disregarding the catastrophe feature.  This
>>> might or might not be what you want.
>>>
>>> In the _very_ short term, though, I'd just use the existing fixed-rate
>>> and floating-rate bond classes and use those until you see that the
>>> thing works.  It will save you some development time which I'd rather
>>> use for getting to a first working version.
>>>
>>> Which brings me to the second part, i.e., the engine class.  It will
>>> probably need to contain a discount curve and your loss distribution.
>>> Any idea about how you'll use them?
>>>
>>> Later,
>>>     Luigi
>>>
>>>
>>> On Fri, Aug 24, 2012 at 5:08 PM, Grześ Andruszkiewicz
>>> <gan...@gm...> wrote:
>>>> Hi Luigi,
>>>>
>>>> Thanks for your reply! I personally can't claim to be proficient with
>>>> Quantlib, but my colleague Lorenzo (CC'd) did the 3-day course in
>>>> London with yourself, so he must be an expert ;)
>>>>
>>>> I don't think there are any established models for CAT bonds. We are
>>>> actually part of one of these academic-industry projects and one of
>>>> the goals is to come up with a model and implementation for these
>>>> instruments. We thought it might be a good idea to make this
>>>> implementation part of quantlib, to make it potentially useful for
>>>> someone.
>>>>
>>>> To start with, I would be grateful for any hints on where to start,
>>>> e.g. what would be your first guess on the place in the class
>>>> hierarchy where this instrument would fit?
>

-- 
Sent from my mobile device

Re: [Quantlib-dev] CAT Bond valuation

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

Grześ,
    apologies for the delay.  As I was telling you, there's currently
no example for coupon amounts calculated in a MC simulation.  If you
want to go that route, you'll have to:

- write the simulation itself.  There are a number of engines you can
use as an example, so you should be covered with regards to creating a
path generator, a path pricer and the several other pieces you'll
need.  The notable difference in your case is that you'll want to
return a number of cashflow amounts from the simulation, not a single
number.  To do that, you'll have to use the second template argument
of PathPricer: I think all the existing engines use its default (that
is, Real for a single number) but you'll have to specify that you'll
return a vector<Real> or something like it.

- link the coupons to the simulation.  Again, there's no code doing
this yet.  What I'd do is to create a new class inheriting from
CashFlow and taking a pointer to the MC simulation.  When their
amount() method is called, instances of this class should ask the
simulation for the corresponding result.  In turn, this means that a)
they should know which cashflow they are (the 1st, the 2nd...) among
those calculated by the simulation and b) the simulation must
implement some kind of caching to avoid being run several times as the
Bond class asks its cashflows for their amounts.

The above should keep you busy for a while :)
Let me know when you need further advice...

Later,
    Luigi


On Thu, Sep 13, 2012 at 5:56 PM, Grześ Andruszkiewicz
<gan...@gm...> wrote:
> Hi Luigi,
>
> Thanks for a long reply. We were just trying to follow your advice and
> extend the Bond class, but we found a few potential issues:
> 1. The Coupon class seems to have a fixed notional, whereas in our
> case the notional could become smaller as a result of CAT events (that
> deplete the notional of the CAT bond)
> 2. The Bond class seems to assume that we can always calculate the
> coupon amounts (independently for every coupon). I am not sure that
> this is possible for CAT bonds (i.e. that coupons will be correlated
> as a result of depleting the notional, catastrophe seasonality, etc.),
> at least I am not comfortable to assume it at this point.
> 3. Moreover, we wanted to have a way to price these instruments using
> Monte Carlo techniques, i.e. use the underlying CAT engine to generate
> random scenarios of events, given the events calculate the NPV of the
> bond for every case, and average the results at the end. It is not
> clear to how to achieve this with the Bond class...
>
> Are there other types of instruments in QuantLib with similar
> characteristics, that we could use as examples?
>
> Kind regards,
> Grzegorz
>
> On 31 August 2012 15:45, Luigi Ballabio <lui...@gm...> wrote:
>> Hi Grześ,
>>     I'd start by doing the least possible coding :)   Let me elaborate.
>>
>> In the architecture of QuantLib, you'll need an instrument class
>> (describing the contract) and an engine class (doing the actual
>> pricing).  You can ask your resident expert (hi, Lorenzo) or read
>> chapter 2 of <https://sites.google.com/site/luigiballabio/>.
>>
>> As for the instrument, it is very tempting to inherit it from the
>> existing Bond class (it's a bond, after all).  In the short term,
>> that's what I advice.
>>
>> In the long term, I'm a bit worried that functions taking a Bond
>> instance (such as, for instance, BondFunctions::yield, which
>> calculates the bond yield) would take a CAT bond and do their job like
>> they do for each other bond; that is, extract its coupons and perform
>> the yield calculations disregarding the catastrophe feature.  This
>> might or might not be what you want.
>>
>> In the _very_ short term, though, I'd just use the existing fixed-rate
>> and floating-rate bond classes and use those until you see that the
>> thing works.  It will save you some development time which I'd rather
>> use for getting to a first working version.
>>
>> Which brings me to the second part, i.e., the engine class.  It will
>> probably need to contain a discount curve and your loss distribution.
>> Any idea about how you'll use them?
>>
>> Later,
>>     Luigi
>>
>>
>> On Fri, Aug 24, 2012 at 5:08 PM, Grześ Andruszkiewicz
>> <gan...@gm...> wrote:
>>> Hi Luigi,
>>>
>>> Thanks for your reply! I personally can't claim to be proficient with
>>> Quantlib, but my colleague Lorenzo (CC'd) did the 3-day course in
>>> London with yourself, so he must be an expert ;)
>>>
>>> I don't think there are any established models for CAT bonds. We are
>>> actually part of one of these academic-industry projects and one of
>>> the goals is to come up with a model and implementation for these
>>> instruments. We thought it might be a good idea to make this
>>> implementation part of quantlib, to make it potentially useful for
>>> someone.
>>>
>>> To start with, I would be grateful for any hints on where to start,
>>> e.g. what would be your first guess on the place in the class
>>> hierarchy where this instrument would fit?

Re: [Quantlib-dev] CDS last period

[<ja...@fr...>]

Couldnt help it: The conventional spread conversion is a good proxy to check 
things like the accrual rebate or other features like the one you mentioned 
initially in this post.

Took todays CDS spreads for Portugal and used DEPOSWAPS from today for the TS 
(should have used yesterday though). These are my figures and Markits quotes:

Without and with accrual rebate in both bootstrapping and pricing/conversion:

                                    Mkit 5Y conv   QL NoR    QL+Rebt
upfront=11   for 5Y lowest bid:         443        439.21    443.38
upfront=14.5 for 5Y highest ask:        506        499.28    504.30

The correction you propose is still missing. With an artificil fix (adding 1 
day to the last coupon in the pricing):
443.24
504.15

Regards
Pepe


----- Mail original -----
De: ja...@fr...
À: "Peter Caspers" <pca...@gm...>
Cc: qua...@li...
Envoyé: Mercredi 10 Octobre 2012 13:43:14
Objet: Re: [Quantlib-dev] CDS last period


Sorry, yes your right settlement is T+3 for upfront and accrual rebate 
computed to T+1. 

Yes, thats what I think too. I have my engines patched to bootstrap that way,
its not a big change. Small difference yes, still it can be seen as a 3M 
oscillation.

On the way Markit works that was my assumption for the upfront quotes, 
Markit's 'standard cds contract converter specification' mentions 
this on p.3, section 'solving for the constant hazard rate'; there it 
says that the upfront does not include the rebate. So their quotes must 
be that way.
A way to test minimum coherence is to compute with QL the conventional 
spread Markit quotes alongside and I get agreement or 1bp difference 
at max (for a ~100bp conventional level of spreads). Which is quite decent 
considering that it is not rare to see Markit converting the same upfront 
quote by two sources on the same day to two different conv spreads (by 1bp). 
Also when I did this I was using the yieldTS from T, not T-1 as the converter 
mandates. I was not far from the last standard coupon date though, that makes 
agreement easier; I was too lazy to follow this with time...

Best regards
Pepe


----- Mail original -----
De: "Peter Caspers" <pca...@gm...>
À: ja...@fr...
Cc: qua...@li...
Envoyé: Mardi 9 Octobre 2012 22:00:06
Objet: Re: [Quantlib-dev] CDS last period

Hi,

since the CreditDefaultSwap allows for an arbitrary schedule the accrual 
rebate can be handled via the upfront amount, i.e. if you provide the 
dirty upfront amount you get what is standard now, don't you? So no need 
for an extension unless (and that's what you are probably pointing at?) 
you want automatic computation of the accrual rebate amount.  Btw I 
think the upfront payment is usually done on T + 3 open days (not T+1), 
is that correct?

What I planned however is to implement a CDS bootstrap helper which can 
pay a full first coupon and an accrual rebate (computed from last roll 
date to T+1) on T+3. In fact the spreads provided by markit are meant 
using this convention rather than paying a short first coupon, at least 
some guy working there told me so. Can you validate this? Admittedly 
this makes only a little difference in the bootstrapped curve in 
general, but why not do it correctly if you can.

Kind regards
Peter

Am 09.10.2012 13:05, schrieb ja...@fr...:
> Hi,
> True; your solution looks good, it allows to use it in other places and it allows non-standard CDS
> contracts too.
>
> Also, apparently theres another flow not treated in the CDS. According to the same new rules the accrued
> amount on the first coupon is paid by the protection buyer on the coupon payment (or default) date but
> it is rebated by the protection seller on T+1 (together with the upfront payment). It would have the
> same effect as not paying the initial accrual except for the discount factor (which is at an uncertain
> time).
>
> See:
> *The CDS Big Bang: Understanding the Changes to the Global CDS Contract and North American Conventions;
> p.18 Markit March 2009
> *Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April 2009  p.4
> *The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64
>
> Do you mind having a look on this too, pls? To have someone elses opinion.
>
> And another related point to the new convention intial accrual is that I have also patched the
> constructors moving this:
>          QL_REQUIRE(protectionStart_ <= schedule[0],
>                     "protection can not start after accrual");
> which used to be true in the old convention,
> into this:
>          QL_REQUIRE((protectionStart_ <= schedule[0])
>              || (schedule.rule() == DateGeneration::Rule::CDS),
>                     "protection can not start after accrual");
> since now it can be the case that the protection period starts before T+1 (actually T-60) but
> rather than my hacks it might be better to leave it open completely;
>
> Best
> pp
>
> ----- Mail original -----
> De: "Peter Caspers" <pca...@gm...>
> À: qua...@li...
> Envoyé: Dimanche 7 Octobre 2012 20:49:53
> Objet: [Quantlib-dev] CDS last period
>
> Hi,
>
> the days in the last period of a CDS are usually counted as (d2-d1+1),
> i.e. including the first and the last date. I might miss something but
> this seems not possible in the current implementation of the credit
> default swap? This would be my plan to fix that:
>
> 1.    Implement a new day counter Actual360Inc counting (d2-d1+1) days
> 2.    Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method
> to FixedRateLeg and extend the Leg() operator accordingly
> 3.    Add a parameter const DayCounter& lastPeriodDayCounter =
> DayCounter() to the CreditDefaultSwap constructors and invoke
> withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
> parameter is not empty
>
> Maybe one could also default the dayCounter to Actual360() and the
> lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
> constructors already to match the usual use case?
>
> Does that make sense?
>
> Thank you
> Peter
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev


------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] CDS last period

[<ja...@fr...>]

Sorry, yes your right settlement is T+3 for upfront and accrual rebate 
computed to T+1. 

Yes, thats what I think too. I have my engines patched to bootstrap that way,
its not a big change. Small difference yes, still it can be seen as a 3M 
oscillation.

On the way Markit works that was my assumption for the upfront quotes, 
Markit's 'standard cds contract converter specification' mentions 
this on p.3, section 'solving for the constant hazard rate'; there it 
says that the upfront does not include the rebate. So their quotes must 
be that way.
A way to test minimum coherence is to compute with QL the conventional 
spread Markit quotes alongside and I get agreement or 1bp difference 
at max (for a ~100bp conventional level of spreads). Which is quite decent 
considering that it is not rare to see Markit converting the same upfront 
quote by two sources on the same day to two different conv spreads (by 1bp). 
Also when I did this I was using the yieldTS from T, not T-1 as the converter 
mandates. I was not far from the last standard coupon date though, that makes 
agreement easier; I was too lazy to follow this with time...

Best regards
Pepe


----- Mail original -----
De: "Peter Caspers" <pca...@gm...>
À: ja...@fr...
Cc: qua...@li...
Envoyé: Mardi 9 Octobre 2012 22:00:06
Objet: Re: [Quantlib-dev] CDS last period

Hi,

since the CreditDefaultSwap allows for an arbitrary schedule the accrual 
rebate can be handled via the upfront amount, i.e. if you provide the 
dirty upfront amount you get what is standard now, don't you? So no need 
for an extension unless (and that's what you are probably pointing at?) 
you want automatic computation of the accrual rebate amount.  Btw I 
think the upfront payment is usually done on T + 3 open days (not T+1), 
is that correct?

What I planned however is to implement a CDS bootstrap helper which can 
pay a full first coupon and an accrual rebate (computed from last roll 
date to T+1) on T+3. In fact the spreads provided by markit are meant 
using this convention rather than paying a short first coupon, at least 
some guy working there told me so. Can you validate this? Admittedly 
this makes only a little difference in the bootstrapped curve in 
general, but why not do it correctly if you can.

Kind regards
Peter

Am 09.10.2012 13:05, schrieb ja...@fr...:
> Hi,
> True; your solution looks good, it allows to use it in other places and it allows non-standard CDS
> contracts too.
>
> Also, apparently theres another flow not treated in the CDS. According to the same new rules the accrued
> amount on the first coupon is paid by the protection buyer on the coupon payment (or default) date but
> it is rebated by the protection seller on T+1 (together with the upfront payment). It would have the
> same effect as not paying the initial accrual except for the discount factor (which is at an uncertain
> time).
>
> See:
> *The CDS Big Bang: Understanding the Changes to the Global CDS Contract and North American Conventions;
> p.18 Markit March 2009
> *Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April 2009  p.4
> *The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64
>
> Do you mind having a look on this too, pls? To have someone elses opinion.
>
> And another related point to the new convention intial accrual is that I have also patched the
> constructors moving this:
>          QL_REQUIRE(protectionStart_ <= schedule[0],
>                     "protection can not start after accrual");
> which used to be true in the old convention,
> into this:
>          QL_REQUIRE((protectionStart_ <= schedule[0])
>              || (schedule.rule() == DateGeneration::Rule::CDS),
>                     "protection can not start after accrual");
> since now it can be the case that the protection period starts before T+1 (actually T-60) but
> rather than my hacks it might be better to leave it open completely;
>
> Best
> pp
>
> ----- Mail original -----
> De: "Peter Caspers" <pca...@gm...>
> À: qua...@li...
> Envoyé: Dimanche 7 Octobre 2012 20:49:53
> Objet: [Quantlib-dev] CDS last period
>
> Hi,
>
> the days in the last period of a CDS are usually counted as (d2-d1+1),
> i.e. including the first and the last date. I might miss something but
> this seems not possible in the current implementation of the credit
> default swap? This would be my plan to fix that:
>
> 1.    Implement a new day counter Actual360Inc counting (d2-d1+1) days
> 2.    Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method
> to FixedRateLeg and extend the Leg() operator accordingly
> 3.    Add a parameter const DayCounter& lastPeriodDayCounter =
> DayCounter() to the CreditDefaultSwap constructors and invoke
> withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
> parameter is not empty
>
> Maybe one could also default the dayCounter to Actual360() and the
> lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
> constructors already to match the usual use case?
>
> Does that make sense?
>
> Thank you
> Peter
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] [ quantlib-Bugs-3513775 ] Addin Error for QuantLibXl on Excel 2010 64-Bit

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

Bugs item #3513775, was opened at 2012-03-31 13:12
Message generated for change (Comment added) made by krowax
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3513775&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: TriRalf (x-ralf-x)
Assigned to: Nobody/Anonymous (nobody)
Summary: Addin Error for QuantLibXl on Excel 2010 64-Bit

Initial Comment:
Hi all,

I get an error when I open the "QuantLibXL.xla" addin on Excel 2010 64-bit:
    "Compile error: The code in this project must be updated for use on 64-bit systems" 
Microsoft explains: error message when you edit a VBA macro in the 64-bit version of an Office 2010 program (see http://support.microsoft.com/kb/983043)

The error comes from the line:
    Private Declare Function SetCurrentDirectory Lib "kernel32" Alias "SetCurrentDirectoryA" (ByVal lpPathName As String) As Long

Can you please update the addin accordingly.


Best regards,
Ralf


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

Comment By: Krowax (krowax)
Date: 2012-10-09 15:36

Message:
I have similar issues with Excel 2010 64-bit and QuantlibXl 1.2:

When I try to add the XLL file to the add-ins, I get an "invalid add-in"
error.

My guess is that it has been built for the 32-bit platform only and would
need to be rebuilt for 64-bit - Can somebody confirm this?

And could somebody who has a working compilation setup (i.e. with all
required libraries/projects) rebuild it for 64-bit?

Thanks
krowax

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

Comment By: TriRalf (x-ralf-x)
Date: 2012-08-14 12:04

Message:
Hi,

why doesn't anyone pick this item up? There is only one line of code to
change.

Regards,
Ralf

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

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

Re: [Quantlib-dev] CDS last period

[Peter C. <pca...@gm...>]

Hi,

since the CreditDefaultSwap allows for an arbitrary schedule the accrual 
rebate can be handled via the upfront amount, i.e. if you provide the 
dirty upfront amount you get what is standard now, don't you? So no need 
for an extension unless (and that's what you are probably pointing at?) 
you want automatic computation of the accrual rebate amount.  Btw I 
think the upfront payment is usually done on T + 3 open days (not T+1), 
is that correct?

What I planned however is to implement a CDS bootstrap helper which can 
pay a full first coupon and an accrual rebate (computed from last roll 
date to T+1) on T+3. In fact the spreads provided by markit are meant 
using this convention rather than paying a short first coupon, at least 
some guy working there told me so. Can you validate this? Admittedly 
this makes only a little difference in the bootstrapped curve in 
general, but why not do it correctly if you can.

Kind regards
Peter

Am 09.10.2012 13:05, schrieb ja...@fr...:
> Hi,
> True; your solution looks good, it allows to use it in other places and it allows non-standard CDS
> contracts too.
>
> Also, apparently theres another flow not treated in the CDS. According to the same new rules the accrued
> amount on the first coupon is paid by the protection buyer on the coupon payment (or default) date but
> it is rebated by the protection seller on T+1 (together with the upfront payment). It would have the
> same effect as not paying the initial accrual except for the discount factor (which is at an uncertain
> time).
>
> See:
> *The CDS Big Bang: Understanding the Changes to the Global CDS Contract and North American Conventions;
> p.18 Markit March 2009
> *Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April 2009  p.4
> *The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64
>
> Do you mind having a look on this too, pls? To have someone elses opinion.
>
> And another related point to the new convention intial accrual is that I have also patched the
> constructors moving this:
>          QL_REQUIRE(protectionStart_ <= schedule[0],
>                     "protection can not start after accrual");
> which used to be true in the old convention,
> into this:
>          QL_REQUIRE((protectionStart_ <= schedule[0])
>              || (schedule.rule() == DateGeneration::Rule::CDS),
>                     "protection can not start after accrual");
> since now it can be the case that the protection period starts before T+1 (actually T-60) but
> rather than my hacks it might be better to leave it open completely;
>
> Best
> pp
>
> ----- Mail original -----
> De: "Peter Caspers" <pca...@gm...>
> À: qua...@li...
> Envoyé: Dimanche 7 Octobre 2012 20:49:53
> Objet: [Quantlib-dev] CDS last period
>
> Hi,
>
> the days in the last period of a CDS are usually counted as (d2-d1+1),
> i.e. including the first and the last date. I might miss something but
> this seems not possible in the current implementation of the credit
> default swap? This would be my plan to fix that:
>
> 1.    Implement a new day counter Actual360Inc counting (d2-d1+1) days
> 2.    Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method
> to FixedRateLeg and extend the Leg() operator accordingly
> 3.    Add a parameter const DayCounter& lastPeriodDayCounter =
> DayCounter() to the CreditDefaultSwap constructors and invoke
> withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this
> parameter is not empty
>
> Maybe one could also default the dayCounter to Actual360() and the
> lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap
> constructors already to match the usual use case?
>
> Does that make sense?
>
> Thank you
> Peter
>
>
>
>
>
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] CDS last period

[<ja...@fr...>]

Hi, 
True; your solution looks good, it allows to use it in other places and it allows non-standard CDS
contracts too.

Also, apparently theres another flow not treated in the CDS. According to the same new rules the accrued 
amount on the first coupon is paid by the protection buyer on the coupon payment (or default) date but 
it is rebated by the protection seller on T+1 (together with the upfront payment). It would have the 
same effect as not paying the initial accrual except for the discount factor (which is at an uncertain 
time).

See:
*The CDS Big Bang: Understanding the Changes to the Global CDS Contract and North American Conventions; 
p.18 Markit March 2009
*Charting a Course Through the CDS Big Bang; Fitchsolutions 7 April 2009  p.4 
*The CDS Big Bang; Otis Casey, Markit Magazine – Spring 2009 p.64

Do you mind having a look on this too, pls? To have someone elses opinion.

And another related point to the new convention intial accrual is that I have also patched the
constructors moving this:
        QL_REQUIRE(protectionStart_ <= schedule[0],
                   "protection can not start after accrual");
which used to be true in the old convention,
into this:
        QL_REQUIRE((protectionStart_ <= schedule[0]) 
            || (schedule.rule() == DateGeneration::Rule::CDS),
                   "protection can not start after accrual");
since now it can be the case that the protection period starts before T+1 (actually T-60) but 
rather than my hacks it might be better to leave it open completely; 

Best
pp

----- Mail original -----
De: "Peter Caspers" <pca...@gm...>
À: qua...@li...
Envoyé: Dimanche 7 Octobre 2012 20:49:53
Objet: [Quantlib-dev] CDS last period

Hi,

the days in the last period of a CDS are usually counted as (d2-d1+1), 
i.e. including the first and the last date. I might miss something but 
this seems not possible in the current implementation of the credit 
default swap? This would be my plan to fix that:

1.    Implement a new day counter Actual360Inc counting (d2-d1+1) days
2.    Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method 
to FixedRateLeg and extend the Leg() operator accordingly
3.    Add a parameter const DayCounter& lastPeriodDayCounter = 
DayCounter() to the CreditDefaultSwap constructors and invoke 
withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this 
parameter is not empty

Maybe one could also default the dayCounter to Actual360() and the 
lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap 
constructors already to match the usual use case?

Does that make sense?

Thank you
Peter







------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] [ quantlib-Bugs-3575440 ] a small one - gammadistribution.cpp

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

Bugs item #3575440, was opened at 2012-10-08 03:20
Message generated for change (Tracker Item Submitted) made by qsong
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3575440&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: ian.qsong (qsong)
Assigned to: Nobody/Anonymous (nobody)
Summary: a small one - gammadistribution.cpp

Initial Comment:
LN #56 in gammadistribution.cpp reads as

     return h*std::exp(-x + a_*std::log(x) - gln), which should be

     return 1.0 - h*std::exp(-x + a_*std::log(x) - gln).

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

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

[Quantlib-dev] CDS last period

[Peter C. <pca...@gm...>]

Hi,

the days in the last period of a CDS are usually counted as (d2-d1+1), 
i.e. including the first and the last date. I might miss something but 
this seems not possible in the current implementation of the credit 
default swap? This would be my plan to fix that:

1.    Implement a new day counter Actual360Inc counting (d2-d1+1) days
2.    Add a lastPeriodDC_ variable and withLastPeriodDayCounter() method 
to FixedRateLeg and extend the Leg() operator accordingly
3.    Add a parameter const DayCounter& lastPeriodDayCounter = 
DayCounter() to the CreditDefaultSwap constructors and invoke 
withLastPeriodDayCounter(lastPeriodDayCounter) in the code if this 
parameter is not empty

Maybe one could also default the dayCounter to Actual360() and the 
lastPeriodDayCounter to Actual360Inc() in the CreditDefaultSwap 
constructors already to match the usual use case?

Does that make sense?

Thank you
Peter

[Quantlib-dev] writing SWIG file for forward/FRA

[Tawanda G. <tg...@gm...>]

I am trying to expose the FRA instrument. I have managed to write the swig file and it compiles. However, I cannot create the object. It consistently produces the error:


Wrong arguments for overloaded function 'new_ForwardRateAgreement'
 Possible C/C++ prototypes are:
   ForwardRateAgreementPtr::ForwardRateAgreementPtr(Date const &,Date const &,Position::Type,Rate,Real,boost::shared_ptr< IborIndex > const &,QuantLib::Handle< YieldTermStructure > const &)
   ForwardRateAgreementPtr::ForwardRateAgreementPtr(Date const &,Date const &,Position::Type,Rate,Real,boost::shared_ptr< IborIndex > const &)

What am I doing wrong? Below are the contents of the swig file:



#ifndef quantlib_forwards_i
#define quantlib_forwards_i

%include instruments.i
%include termstructures.i
%include cashflows.i
%include grid.i
%include stl.i
%{
using QuantLib::Position;
using QuantLib::Forward;
using QuantLib::ForwardRateAgreement;
using QuantLib::Seasonality;
typedef boost::shared_ptr<Instrument> ForwardPtr;
typedef boost::shared_ptr<Instrument> ForwardRateAgreementPtr;
%}

struct Position {
    enum Type { Long, Short};
};

%rename(Forward) ForwardPtr;
class ForwardPtr : public boost::shared_ptr<Instrument> {
  public:
    %extend {
        
        Date settlementDate() {
            return boost::dynamic_pointer_cast<Forward>(*self)->settlementDate();
        }
	BusinessDayConvention businessDayConvention() {
            return boost::dynamic_pointer_cast<Forward>(*self)->businessDayConvention();
	}
        Rate spotValue() {
            return boost::dynamic_pointer_cast<Forward>(*self)->spotValue();
        }
	Rate forwardValue() {
            return boost::dynamic_pointer_cast<Forward>(*self)->forwardValue();
        }
        InterestRate impliedYield(Real underlyingSpotValue,
                                  Real forwardValue,
                                  Date settlementDate,
                                  Compounding compoundingConvention,
                                  DayCounter dayCounter) {
           return boost::dynamic_pointer_cast<Forward>(*self)->impliedYield(
				  underlyingSpotValue,
                                  forwardValue,
                                  settlementDate,
                                  compoundingConvention,
                                  dayCounter);
        }
        }
  protected: /* added this later, but did not help*/
        Forward(const DayCounter& dayCounter,
                const Calendar& calendar,
                BusinessDayConvention businessDayConvention,
                Natural settlementDays,
                const boost::shared_ptr<Payoff>& payoff,
                const Date& valueDate,
                const Date& maturityDate,
                const Handle<YieldTermStructure>& discountCurve =
                                                Handle<YieldTermStructure>()) {
                return new ForwardPtr(new Forward(dayCounter,
			calendar,
                	businessDayConvention,
                	settlementDays,
                	payoff,
                	valueDate,
                	maturityDate,
                	discountCurve));
        }
    
};

%rename(ForwardRateAgreement) ForwardRateAgreementPtr;
class ForwardRateAgreementPtr : public ForwardPtr {
  public:
    %extend {
        ForwardRateAgreementPtr(
                const Date& valueDate,
                const Date& maturityDate,
                Position::Type type,
                Rate strikeForwardRate,
                Real notionalAmount,
                const boost::shared_ptr<IborIndex>& index,
                const Handle<YieldTermStructure>& discountCurve =
                                                 Handle<YieldTermStructure>()) { 
			    return new ForwardRateAgreementPtr(
			                 new ForwardRateAgreement(valueDate,
                                                                  maturityDate,
                             					  type,
                             					  strikeForwardRate,
                             					  notionalAmount,
                             					  index,
                             					  discountCurve));
            }

        
       Real spotIncome(const Handle<YieldTermStructure>& incomeDiscountCurve) const {
          return boost::dynamic_pointer_cast<ForwardRateAgreement>(*self)-> spotIncome(
                            incomeDiscountCurve);
           }
      /*Real spotValue() {
        return boost::dynamic_pointer_cast<ForwardRateAgreement>(*self)->spotValue();
      }*/
    }
};


#endif

[Quantlib-dev] R: Re: QuantLib 1.2 error at memory location

[<tar...@li...>]

Thanks Mike, now it works

ciao

P


----Messaggio originale----
Da: mjb...@gm...
Data: 04/10/2012 2.30
A: "tar...@li..."<tar...@li...>
Cc: <qua...@li...>
Ogg: Re: [Quantlib-dev] QuantLib 1.2 error at memory location

Hi,


you are running a debug version of this quant lib module but do not have the debug symbols present on your machine.
You'll need to get hold of a release version of the 1.2 (no debug symbols) or build 1.2 yourself on the machine that you are running your code on.


Cheers,


Mike



On Thu, Oct 4, 2012 at 12:54 AM, tar...@li... <tar...@li...> wrote:


Hello,

I have update QuantLib from 1.1 to 1.2 and I got a strange error.

QLSBTesting.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', Cannot find or open
the PDB file
'QLSBTesting.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', Cannot find or
open the PDB file
'QLSBTesting.exe': Loaded 'C:\WINDOWS\system32\msvcp100.dll', Cannot find or
open the PDB file
'QLSBTesting.exe': Loaded 'C:\WINDOWS\system32\msvcr100.dll', Cannot find or
open the PDB file
First-chance exception at 0x7c812afb in QLSBTesting.exe: Microsoft C++
exception: QuantLib::Error at memory location 0x0012fc68..
The program '[4108] QLSBTesting.exe: Native' has exited with code 0 (0x0).

Here is the piece of code which worked on 1.1 but return me the above error
after moved to 1.2. The pronlem is when I call the InterpolatedDiscountCurve (
see at the end of the code)
Have you any clue?

Thanks in advance
Paolo

                                           std::vector<std::string> sb_dates;
                sb_dates.push_back("2012-10-03");
                sb_dates.push_back("2012-11-05");
                sb_dates.push_back("2012-11-05");
                sb_dates.push_back("2012-12-05");
                sb_dates.push_back("2013-10-07");
                sb_dates.push_back("2014-10-06");
                sb_dates.push_back("2017-10-05");
                sb_dates.push_back("2024-10-07");
                sb_dates.push_back("2032-10-05");

                std::vector<double> sb_values;
                sb_values.push_back(1.0);
                sb_values.push_back(0.999981);
                sb_values.push_back( 0.99997);
                sb_values.push_back( 0.999878);
                sb_values.push_back( 0.996254);
                sb_values.push_back( 0.991456);
                sb_values.push_back(0.95465);
                sb_values.push_back( 0.785955);
                sb_values.push_back(0.623019);

                std::string sb_datatype("discountfactor");
                std::string sb_dcf("act360");
                std::string sb_interpolation("Linear");
                std::vector<std::string> sb_dates2interp;

                std::vector<QuantLib::Date> dates;
                if (dates.size() < sb_dates.size()) { dates.resize(sb_dates.size()); }
                std::vector<QuantLib::Date> dates2interp;
                if (dates2interp.size() < sb_dates2interp.size()) { dates2interp.resize
(sb_dates2interp.size()); }

                // Converting the dates string into QuantLib Date
                for (size_t i=0; i<sb_dates.size(); ++i) {
                        dates[i] = QuantLib::DateParser::parseISO(sb_dates[i]);
                }
                for (size_t i=0; i<sb_dates2interp.size(); ++i) {
                        dates2interp[i] = QuantLib::DateParser::parseISO(sb_dates2interp[i]);
                }

                // Day counter
                QuantLib::DayCounter basis = QuantLib::Actual360();
                if (sb_dcf.compare("actact") == 0) { basis = QuantLib::ActualActual(); }
                if (sb_dcf.compare("act365") == 0) { basis = QuantLib::Actual365Fixed(); }
                if (sb_dcf.compare("30360") == 0) { basis = QuantLib::Thirty360(); }
                if (sb_dcf.compare("act360") == 0) { basis = QuantLib::Actual360(); }
                if (sb_dcf.compare("bus252") == 0) { basis = QuantLib::Business252(); }

                // Yield term structure
                QuantLib::RelinkableHandle<YieldTermStructure> yc;

                if (sb_datatype.compare("discountfactor") == 0) {

                        std::vector<QuantLib::DiscountFactor> dfs;
                        if (dfs.size() < sb_values.size()) { dfs.resize(sb_values.size()); }
                        for (size_t i=0; i<sb_values.size(); ++i) {
                                dfs[i] = sb_values[i];
                                std::cout << dfs[i] << std::endl;
                        }

                        if (sb_interpolation.compare("Linear") == 0) {
                                std::cout << "START: " << std::endl;
                                boost::shared_ptr<YieldTermStructure> dfcurve(new QuantLib::
InterpolatedDiscountCurve<Linear>(dates, dfs, basis));
                                yc.linkTo(dfcurve);
                                std::cout << "VALUE DF: " << dfcurve->(dates2interp[1]) << std::endl;
                        }
                                            }

------------------------------------------------------------------------------
Don't let slow site performance ruin your business. Deploy New Relic APM
Deploy New Relic app performance management and know exactly
what is happening inside your Ruby, Python, PHP, Java, and .NET app
Try New Relic at no cost today and get our sweet Data Nerd shirt too!
http://p.sf.net/sfu/newrelic-dev2dev
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] QuantLib 1.2 error at memory location

[Michael B. <mjb...@gm...>]

Hi,

you are running a debug version of this quant lib module but do not have
the debug symbols present on your machine.
You'll need to get hold of a release version of the 1.2 (no debug symbols)
or build 1.2 yourself on the machine that you are running your code on.

Cheers,

Mike

On Thu, Oct 4, 2012 at 12:54 AM, tar...@li...
<tar...@li...>wrote:

>
> Hello,
>
> I have update QuantLib from 1.1 to 1.2 and I got a strange error.
>
> QLSBTesting.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', Cannot find or
> open
> the PDB file
> 'QLSBTesting.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', Cannot find
> or
> open the PDB file
> 'QLSBTesting.exe': Loaded 'C:\WINDOWS\system32\msvcp100.dll', Cannot find
> or
> open the PDB file
> 'QLSBTesting.exe': Loaded 'C:\WINDOWS\system32\msvcr100.dll', Cannot find
> or
> open the PDB file
> First-chance exception at 0x7c812afb in QLSBTesting.exe: Microsoft C++
> exception: QuantLib::Error at memory location 0x0012fc68..
> The program '[4108] QLSBTesting.exe: Native' has exited with code 0 (0x0).
>
> Here is the piece of code which worked on 1.1 but return me the above error
> after moved to 1.2. The pronlem is when I call the
> InterpolatedDiscountCurve (
> see at the end of the code)
> Have you any clue?
>
> Thanks in advance
> Paolo
>
>                                            std::vector<std::string>
> sb_dates;
>                 sb_dates.push_back("2012-10-03");
>                 sb_dates.push_back("2012-11-05");
>                 sb_dates.push_back("2012-11-05");
>                 sb_dates.push_back("2012-12-05");
>                 sb_dates.push_back("2013-10-07");
>                 sb_dates.push_back("2014-10-06");
>                 sb_dates.push_back("2017-10-05");
>                 sb_dates.push_back("2024-10-07");
>                 sb_dates.push_back("2032-10-05");
>
>                 std::vector<double> sb_values;
>                 sb_values.push_back(1.0);
>                 sb_values.push_back(0.999981);
>                 sb_values.push_back( 0.99997);
>                 sb_values.push_back( 0.999878);
>                 sb_values.push_back( 0.996254);
>                 sb_values.push_back( 0.991456);
>                 sb_values.push_back(0.95465);
>                 sb_values.push_back( 0.785955);
>                 sb_values.push_back(0.623019);
>
>                 std::string sb_datatype("discountfactor");
>                 std::string sb_dcf("act360");
>                 std::string sb_interpolation("Linear");
>                 std::vector<std::string> sb_dates2interp;
>
>                 std::vector<QuantLib::Date> dates;
>                 if (dates.size() < sb_dates.size()) {
> dates.resize(sb_dates.size()); }
>                 std::vector<QuantLib::Date> dates2interp;
>                 if (dates2interp.size() < sb_dates2interp.size()) {
> dates2interp.resize
> (sb_dates2interp.size()); }
>
>                 // Converting the dates string into QuantLib Date
>                 for (size_t i=0; i<sb_dates.size(); ++i) {
>                         dates[i] =
> QuantLib::DateParser::parseISO(sb_dates[i]);
>                 }
>                 for (size_t i=0; i<sb_dates2interp.size(); ++i) {
>                         dates2interp[i] =
> QuantLib::DateParser::parseISO(sb_dates2interp[i]);
>                 }
>
>                 // Day counter
>                 QuantLib::DayCounter basis = QuantLib::Actual360();
>                 if (sb_dcf.compare("actact") == 0) { basis =
> QuantLib::ActualActual(); }
>                 if (sb_dcf.compare("act365") == 0) { basis =
> QuantLib::Actual365Fixed(); }
>                 if (sb_dcf.compare("30360") == 0) { basis =
> QuantLib::Thirty360(); }
>                 if (sb_dcf.compare("act360") == 0) { basis =
> QuantLib::Actual360(); }
>                 if (sb_dcf.compare("bus252") == 0) { basis =
> QuantLib::Business252(); }
>
>                 // Yield term structure
>                 QuantLib::RelinkableHandle<YieldTermStructure> yc;
>
>                 if (sb_datatype.compare("discountfactor") == 0) {
>
>                         std::vector<QuantLib::DiscountFactor> dfs;
>                         if (dfs.size() < sb_values.size()) {
> dfs.resize(sb_values.size()); }
>                         for (size_t i=0; i<sb_values.size(); ++i) {
>                                 dfs[i] = sb_values[i];
>                                 std::cout << dfs[i] << std::endl;
>                         }
>
>                         if (sb_interpolation.compare("Linear") == 0) {
>                                 std::cout << "START: " << std::endl;
>                                 boost::shared_ptr<YieldTermStructure>
> dfcurve(new QuantLib::
> InterpolatedDiscountCurve<Linear>(dates, dfs, basis));
>                                 yc.linkTo(dfcurve);
>                                 std::cout << "VALUE DF: " <<
> dfcurve->(dates2interp[1]) << std::endl;
>                         }
>                                             }
>
>
> ------------------------------------------------------------------------------
> Don't let slow site performance ruin your business. Deploy New Relic APM
> Deploy New Relic app performance management and know exactly
> what is happening inside your Ruby, Python, PHP, Java, and .NET app
> Try New Relic at no cost today and get our sweet Data Nerd shirt too!
> http://p.sf.net/sfu/newrelic-dev2dev
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] QuantLib 1.2 error at memory location

[<tar...@li...>]

Hello,

I have update QuantLib from 1.1 to 1.2 and I got a strange error.

QLSBTesting.exe': Loaded 'C:\WINDOWS\system32\ntdll.dll', Cannot find or open 
the PDB file
'QLSBTesting.exe': Loaded 'C:\WINDOWS\system32\kernel32.dll', Cannot find or 
open the PDB file
'QLSBTesting.exe': Loaded 'C:\WINDOWS\system32\msvcp100.dll', Cannot find or 
open the PDB file
'QLSBTesting.exe': Loaded 'C:\WINDOWS\system32\msvcr100.dll', Cannot find or 
open the PDB file
First-chance exception at 0x7c812afb in QLSBTesting.exe: Microsoft C++ 
exception: QuantLib::Error at memory location 0x0012fc68..
The program '[4108] QLSBTesting.exe: Native' has exited with code 0 (0x0).

Here is the piece of code which worked on 1.1 but return me the above error 
after moved to 1.2. The pronlem is when I call the InterpolatedDiscountCurve ( 
see at the end of the code)
Have you any clue?

Thanks in advance
Paolo

                                           std::vector<std::string> sb_dates;
		sb_dates.push_back("2012-10-03");
		sb_dates.push_back("2012-11-05");
		sb_dates.push_back("2012-11-05");
		sb_dates.push_back("2012-12-05");
		sb_dates.push_back("2013-10-07");
		sb_dates.push_back("2014-10-06");
		sb_dates.push_back("2017-10-05");
		sb_dates.push_back("2024-10-07");
		sb_dates.push_back("2032-10-05");

		std::vector<double> sb_values;
		sb_values.push_back(1.0);
		sb_values.push_back(0.999981);
		sb_values.push_back( 0.99997);
		sb_values.push_back( 0.999878);
		sb_values.push_back( 0.996254);
		sb_values.push_back( 0.991456);
		sb_values.push_back(0.95465);
		sb_values.push_back( 0.785955);
		sb_values.push_back(0.623019);

		std::string sb_datatype("discountfactor");
		std::string sb_dcf("act360");
		std::string sb_interpolation("Linear");
		std::vector<std::string> sb_dates2interp;

		std::vector<QuantLib::Date> dates;
		if (dates.size() < sb_dates.size()) { dates.resize(sb_dates.size()); }
		std::vector<QuantLib::Date> dates2interp;
		if (dates2interp.size() < sb_dates2interp.size()) { dates2interp.resize
(sb_dates2interp.size()); }

		// Converting the dates string into QuantLib Date
		for (size_t i=0; i<sb_dates.size(); ++i) {
			dates[i] = QuantLib::DateParser::parseISO(sb_dates[i]);
		}
		for (size_t i=0; i<sb_dates2interp.size(); ++i) {
			dates2interp[i] = QuantLib::DateParser::parseISO(sb_dates2interp[i]); 
		}

		// Day counter
		QuantLib::DayCounter basis = QuantLib::Actual360();
		if (sb_dcf.compare("actact") == 0) { basis = QuantLib::ActualActual(); }
		if (sb_dcf.compare("act365") == 0) { basis = QuantLib::Actual365Fixed(); }
		if (sb_dcf.compare("30360") == 0) { basis = QuantLib::Thirty360(); }
		if (sb_dcf.compare("act360") == 0) { basis = QuantLib::Actual360(); }
		if (sb_dcf.compare("bus252") == 0) { basis = QuantLib::Business252(); }

		// Yield term structure
		QuantLib::RelinkableHandle<YieldTermStructure> yc;

		if (sb_datatype.compare("discountfactor") == 0) {

			std::vector<QuantLib::DiscountFactor> dfs;
			if (dfs.size() < sb_values.size()) { dfs.resize(sb_values.size()); }
			for (size_t i=0; i<sb_values.size(); ++i) {
				dfs[i] = sb_values[i];
				std::cout << dfs[i] << std::endl;
			}

			if (sb_interpolation.compare("Linear") == 0) {
				std::cout << "START: " << std::endl;
				boost::shared_ptr<YieldTermStructure> dfcurve(new QuantLib::
InterpolatedDiscountCurve<Linear>(dates, dfs, basis));
				yc.linkTo(dfcurve);
				std::cout << "VALUE DF: " << dfcurve->(dates2interp[1]) << std::endl;
			}
                                            }

Re: [Quantlib-dev] Cashflows accrued methods

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

Yes, you're right.  Thanks for the heads-up.

Luigi

On Mon, Sep 17, 2012 at 10:06 PM, Peter Caspers <pca...@gm...> wrote:
> Hi Luigi, Nando,
>
> the methods Cashflows::accruedPeriod(), accruedDays() and accruedAmount()
> default the settlementDate to Date(), which I guess should mean to take the
> evaluation date as the settlement date. However this does not work with the
> methods in Coupon invoked from here. As a result 0.0 is returned always,
> when no settlement date is specified.
>
> I think therefore that
>
> if (settlementDate == Date())
>        settlementDate = Settings::instance().evaluationDate();
>
> should be added to the methods mentioned above. I observe this in 1.1.
>
> Regards
> Peter
>

Re: [Quantlib-dev] QuantLib XLL

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

Hi Tim,

On 2012-09-19 15:14, Mills, Tim wrote:
> I am assuming that this Addin is for a specific version of Microsoft
> Office as it is an XLL not a XLM file as I have tried to load it in
> Office 2007 and it does not work

QuantLibXL works with Excel 2007.  Exactly what error are you getting?

Please follow the instructions at this link...

     http://www.quantlibxl.org/installation.html

...and please let us know exactly where it goes wrong.

Kind Regards,
Eric
-- 
===================================================
Eric Ehlers
nazcatech sprl | Brussels | http://www.nazcatech.be
* Distributed computing for pricing analytics
* Use Microsoft Excel as a client to the Grid

Re: [Quantlib-dev] [Quantlib-users] Two design questions about quantlib

[David E. <id...@ya...>]

I'm trying to use Command and Chain of Responsibility interfaces to isolate the subject-matter specific finance from the implementation pattern. That way, all finance could use singleton access (i.e. know about finance-specific classes and methods), while the implementation pattern could go through streaming and dispatch methods, which would provide generic interfaces, like xml text, or maybe name-value maps. 
 
So I'll "pollute" the finance space with streaming and dispatch interfaces, but nothing functionally intrusive. I view that as the finance subject matter being required to hold itself accountable, which seems reasonable. That would double as builtin support for debugging and swig. It would require a complete refactoring, so for proof of concept I'll write a few simple classes from scratch.
 
Users could write their own base implementation patterns, or use the default Observable. Implementation patterns would inherit from CofC and Command, and the dispatch methods would be called generically by the pattern's active function method, e.g. onNotify(), or visit(). Automake macros could insert base class references to patterns for however you wanted to build it. You'd build a couple of separate sos or dlls, and the core lib/libs would only use singleton types in their interfaces.

As soon as I have a Visitor-based proof of concept for the first part I'll distribute a gzip. We'll see if anybody thinks it makes sense to use this idea. I think there's enough finance-specific material to make it worthwhile.

Dave Eaves
 

________________________________
 From: Luigi Ballabio <lui...@gm...>
To: David Eaves <id...@ya...> 
Cc: qua...@li...; "qua...@li..." <qua...@li...> 
Sent: Monday, September 24, 2012 1:36 AM
Subject: Re: [Quantlib-users] Two design questions about quantlib
  
Hi David,
    apologies for the delay.

You've put your finger on a sore spot.  It has been bugging me for a
while that it's just not possible to get a simple price without
instantiating an instrument and a pricing engine.  And of course, all
this comes from the pervasiveness of Observer.  Like the Vorlons in
Babylon 5, we thought we were doing good but ended up meddling with
people...

I have been thinking of trying to extract the functional core, so that
the basic pricing functions are available as functions (which is, I
guess, what you're driving at when you talk of implementing them as
Singletons) and the pricing-engine classes call the functions and take
care of observability.  For simple functionality, this could be done
in a backward-compatible way as to avoid code divergence.  I'm not
sure how this would work out in more complex cases, where the event
chains are
 more tangled.  And while this would be simple for engines,
I've a feeling that it would be difficult to do for things like term
structures, where it's more difficult to extract the functionality
from the object responding to events.

Another possibility would be to allow one to choose whether any given
object should listen to events or not.  But this can get messy very
quickly.

I guess what I'm trying to say is that I don't have a clear picture of
where to go :)
If anybody wants to weigh in, please do so.  I'd be nice to have a bit
of discussion on this.

Later,
    Luigi


On Mon, Sep 3, 2012 at 10:22 PM, David Eaves <id...@ya...> wrote:
> (html didn't post well before, re-posting both quantlib-dev and quantlib-users)
>
> I've been writing quant software for almost 20
 years, and this is my first look at quantlib. It's very impressive, but I have two design questions that I wanted to float in the quantlib-dev list, and see what kind of thoughtful responses there might be. No need to respond instantly: I'd like to hear considered responses.
>
> This is all descended from the Observer design pattern, plus some other support. Which is nice, I did a bunch of event-driven systems back in the 1990s, very cool. And it scales reasonably well, within a single OS and machine.
>
> 1) Poll: How many users/developers have ever wanted to use this product without the Observer design pattern, which I find impedes distributed computing, general transparency, and audit?
>
> 2) Has anybody thought about how one might implement the subject matter independently, as Singleton, and embed it within a design pattern of ones own choosing? E.g. I'd like to be able to use these methods in a Command/Visitor
 context, but see a rewrite as codebase divergence, a big no-no for me.
>
> Thanks,
>
> Dave Eaves
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-dev] [Quantlib-users] Two design questions about quantlib

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

Hi David,
    apologies for the delay.

You've put your finger on a sore spot.  It has been bugging me for a
while that it's just not possible to get a simple price without
instantiating an instrument and a pricing engine.  And of course, all
this comes from the pervasiveness of Observer.  Like the Vorlons in
Babylon 5, we thought we were doing good but ended up meddling with
people...

I have been thinking of trying to extract the functional core, so that
the basic pricing functions are available as functions (which is, I
guess, what you're driving at when you talk of implementing them as
Singletons) and the pricing-engine classes call the functions and take
care of observability.  For simple functionality, this could be done
in a backward-compatible way as to avoid code divergence.  I'm not
sure how this would work out in more complex cases, where the event
chains are more tangled.  And while this would be simple for engines,
I've a feeling that it would be difficult to do for things like term
structures, where it's more difficult to extract the functionality
from the object responding to events.

Another possibility would be to allow one to choose whether any given
object should listen to events or not.  But this can get messy very
quickly.

I guess what I'm trying to say is that I don't have a clear picture of
where to go :)
If anybody wants to weigh in, please do so.  I'd be nice to have a bit
of discussion on this.

Later,
    Luigi


On Mon, Sep 3, 2012 at 10:22 PM, David Eaves <id...@ya...> wrote:
> (html didn't post well before, re-posting both quantlib-dev and quantlib-users)
>
> I've been writing quant software for almost 20 years, and this is my first look at quantlib. It's very impressive, but I have two design questions that I wanted to float in the quantlib-dev list, and see what kind of thoughtful responses there might be. No need to respond instantly: I'd like to hear considered responses.
>
> This is all descended from the Observer design pattern, plus some other support. Which is nice, I did a bunch of event-driven systems back in the 1990s, very cool. And it scales reasonably well, within a single OS and machine.
>
> 1) Poll: How many users/developers have ever wanted to use this product without the Observer design pattern, which I find impedes distributed computing, general transparency, and audit?
>
> 2) Has anybody thought about how one might implement the subject matter independently, as Singleton, and embed it within a design pattern of ones own choosing? E.g. I'd like to be able to use these methods in a Command/Visitor context, but see a rewrite as codebase divergence, a big no-no for me.
>
> Thanks,
>
> Dave Eaves
>
>
> ------------------------------------------------------------------------------
> Live Security Virtual Conference
> Exclusive live event will cover all the ways today's security and
> threat landscape has changed and how IT managers can respond. Discussions
> will include endpoint security, mobile security and the latest in malware
> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

[Quantlib-dev] 答复: QuantLib XLL

[Cheng L. <scr...@gm...>]

No the xll works for Excel 2007, 2010 and so on very well. Do you add the
xll addin in the correct way?  The following page show the correct way to
add the Quantlib xll add-in.

 

http://quantlib.org/quantlibxl/installation.html

 

发件人: Mills, Tim [mailto:tim...@fi...] 
发送时间: 2012年9月19日 21:14
收件人: 'qua...@li...'
主题: [Quantlib-dev] QuantLib XLL

 

Hi,

 

I am assuming that this Addin is for a specific version of Microsoft Office
as it is an XLL not a XLM file as I have tried to load it in Office 2007 and
it does not work 

 

Tim Mills I Desktop Services  IM I 727 4299 I +44 (0)20 7961 4299

Fidelity Worldwide Investment I 25 Cannon St, London, EC4M 5TA  

The information transmitted is intended for the person or entity to which it
is addressed and may contain confidential, privileged or copyrighted
material. If you receive this in error, please contact the sender and delete
the material from any computer. Fidelity only gives information on products
and does not give investment advice to private clients based on individual
circumstances. Any comments or statements made are not necessarily those of
Fidelity. All e-mails may be monitored. FIL Investments International (Reg.
No.1448245), FIL Investment Services (UK) Limited (Reg. No. 2016555), FIL
Pensions Management (Reg. No. 2015142), FIL Life Insurance Limited (Reg No.
3406905) and Financial Administration Services Limited (Reg. No. 1629709)
are authorised and regulated in the UK by the Financial Services Authority
and have their registered offices at Oakhill House, 130 Tonbridge Road,
Hildenborough, Tonbridge, Kent TN11 9DZ 

 

[Quantlib-dev] QuantLib XLL

[Mills, T. <tim...@fi...>]

Hi,

I am assuming that this Addin is for a specific version of Microsoft Office as it is an XLL not a XLM file as I have tried to load it in Office 2007 and it does not work

Tim Mills I Desktop Services - IM I 727 4299 I +44 (0)20 7961 4299
Fidelity Worldwide Investment I 25 Cannon St, London, EC4M 5TA
The information transmitted is intended for the person or entity to which it is addressed and may contain confidential, privileged or copyrighted material. If you receive this in error, please contact the sender and delete the material from any computer. Fidelity only gives information on products and does not give investment advice to private clients based on individual circumstances. Any comments or statements made are not necessarily those of Fidelity. All e-mails may be monitored. FIL Investments International (Reg. No.1448245), FIL Investment Services (UK) Limited (Reg. No. 2016555), FIL Pensions Management (Reg. No. 2015142), FIL Life Insurance Limited (Reg No. 3406905) and Financial Administration Services Limited (Reg. No. 1629709) are authorised and regulated in the UK by the Financial Services Authority and have their registered offices at Oakhill House, 130 Tonbridge Road, Hildenborough, Tonbridge, Kent TN11 9DZ

[Quantlib-dev] [ quantlib-Patches-3568787 ] Cross currency rate helper

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

Patches item #3568787, was opened at 2012-09-18 00:04
Message generated for change (Tracker Item Submitted) made by miemiec
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3568787&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: Andre Miemiec (miemiec)
Assigned to: Nobody/Anonymous (nobody)
Summary: Cross currency rate helper

Initial Comment:
This file contributes new rate helpers to the QuantLib library in order to support the building of discount curves from cross currency swaps. 
Implemented are constant notional cross currency swaps. I've checked the code for the pair EUR/USD in two directions: Bootstrapping of the 
yield curve on the spread leg and on the flat leg. Both are checked against results from productive environments and seemed to work. 
There are two obvious things left to do:
- Implementation of the forward start feature
- based on the previous step, implementation of mtm cross currency swaps. 
Both extensions should be minor exercises. 

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

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

[Quantlib-dev] Cashflows accrued methods

[Peter C. <pca...@gm...>]

Hi Luigi, Nando,

the methods Cashflows::accruedPeriod(), accruedDays() and 
accruedAmount() default the settlementDate to Date(), which I guess 
should mean to take the evaluation date as the settlement date. However 
this does not work with the methods in Coupon invoked from here. As a 
result 0.0 is returned always, when no settlement date is specified.

I think therefore that

if (settlementDate == Date())
        settlementDate = Settings::instance().evaluationDate();

should be added to the methods mentioned above. I observe this in 1.1.

Regards
Peter

[Quantlib-dev] [ quantlib-Bugs-3568164 ] mistake in calendar?

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

Bugs item #3568164, was opened at 2012-09-16 07:19
Message generated for change (Comment added) made by sebgur
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3568164&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: Sebastien Gurrieri (sebgur)
Assigned to: Nobody/Anonymous (nobody)
Summary: mistake in calendar?

Initial Comment:
I think there is a mistake in your implementation of the holidays of the Japanese calendar. It seems to produce a different answer as to the "golden week" which is a series of holidays in the beginning of May in Japan. The results are inconsistent with other calculators such as Bloomberg. I also compared your code with legal Japanese websites and I believe there is a misunderstanding in your code as to what happens when one or more of the holidays fall in a week-end.

Best Regards,

Sebastien

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

Comment By: Sebastien Gurrieri (sebgur)
Date: 2012-09-17 11:31

Message:
On this link we can see that 07/05/2013 is a business day in Japan
 
http://portalseven.com/calendar/Holidays_Japan.jsp?year=2013
 
and this is consistent with what I see in Bloomberg. As you can see at the
bottom of this page, the “Greenery day”, on the 4th, falls on a
Saturday while the Children’s Day falls on the Sunday 5th. I checked the
QuantLib code, and it seems to consider that any day in the 3rd, 4th, and
5th, that falls on a week-end will be compensated by a holiday on the week
after that, and for example, when the 4th is a Saturday and the 5th is a
Sunday, 2 days will be compensated in QuantLib, yielding a holiday on the
7th. The QuantLib addin accordingly answers that the 7th is a holiday,
which does not seem to be in line with Japanese rules. Indeed, the rule is
that only when such a day falls on a Sunday will it be compensated for.
 
See the reference
 
http://www8.cao.go.jp/chosei/shukujitsu/gaiyou.html
 
Sorry for the Japanese, but here is the sentence saying it in the link
above
 
また、「国民の祝日」が日曜日に当たるときは、その日後においてその日に最も近い「国民の祝日」でない日を休日とすることになりました。
 
I’m not a Japanese native so I checked by asking around me to Japanese
people, and they confirmed the Sunday-only rule (I work in a Japanese
bank).
This rule is indeed consistent with what is observed in the first link for
2013. Currently the code is (I’m still on the 1.2.0)
 
            || (d == 3  && m == May)
            // Holiday for a Nation
            || (d == 4  && m == May)
            // Children's Day
            || (d == 5  && m == May)
            // any of the three above observed later if on Saturday or
Sunday
            || ((d == 6 || d == 7) && m == May
                && (w == Monday || w == Tuesday || w == Wednesday))
 
but I’m thinking that
 
            || (d == 3  && m == May)
            // Holiday for a Nation
            || (d == 4  && m == May)
            // Children's Day
            || (d == 5  && m == May)
            // any of the three above observed later if on Saturday or
Sunday
            || (d == 6 && m == May
                && (w == Monday || w == Tuesday || w == Wednesday))
 
would probably be more in line with what the official rule seems to be.
 
Best regards,
 
Sebastien

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-09-17 01:59

Message:
May you provide some examples of correct data?

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

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