quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] [ quantlib-Bugs-3579723 ] Epiphany missing from Polish holiday calendar

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: katastrofa (katastrofa)
>Assigned to: Luigi Ballabio (lballabio)
Summary: Epiphany missing from Polish holiday calendar

Initial Comment:
Since 2011, Poland has a new state holiday: Epiphany on 6 January (http://en.wikipedia.org/wiki/Epiphany_%28holiday%29#Poland). QuantLib holiday calendar for Poland does not have it: http://quantlib.svn.sourceforge.net/viewvc/quantlib/trunk/QuantLib/ql/time/calendars/poland.cpp?revision=18354&view=markup

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

Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-06 03:34

Message:
The bug is now fixed in the Subversion repository.
Thank you for the report.


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

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

[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 lballabio
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: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Sebastien Gurrieri (sebgur)
>Assigned to: Luigi Ballabio (lballabio)
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: Luigi Ballabio (lballabio)
Date: 2012-11-06 03:33

Message:
The patch was applied to the Subversion repository.
Thank you for the report and the fix.


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

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

[Quantlib-dev] [ quantlib-Patches-3582579 ] Differential Evolution improvement

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

Patches item #3582579, was opened at 2012-11-01 15:38
Message generated for change (Comment added) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3582579&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: Mateusz Kapturski (fenixcitizen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Differential Evolution improvement

Initial Comment:
Hi All,
I have come across the new implementation of Differential Evolution that appeared in QuantLib HEAD source code recently. I decided to improve it slightly. I took performance very seriously as the DE implementation should be light in order to avoid unnecessary time overhead. 

The most significant change is that I use DiffEvolConfiguration object that defines the behavior of the algorithm. The reason is that it makes the implementation more flexible. There are dozens of DE variants... I tried to be in line with current QuantLib optimization interface.

Important changes:
1) DE Optimizer consumes configuration object that defines its behavior - as I mentioned, the number of variations of the DE algorithm is huge. This approach makes it possible to extend the implementations in the future.
2) Constraints that define search space are not the part of the algorithm itself - this is why additional upperBound and lowerBound functions were added to Constraint object. NonhomogeneousBoundaryConstraint to define box constraints was added too. The other aspect is if the bounds are going to be valid for emerging populations - practical advise is that it should as for certain parameters, new populations seem to diverge. On the other hand, it adds some additional overhead. General observation is that it is always possible to improve performance for a given objective function. One needs to find appropriate DE configuration only.
3) I added three different crossover types: normal, binomial and exponential (the name for the first crossover type comes from the fact that assuming binomial crossover, the number of mutants taken into account in a given population converges in distribution to normal variable for growing problem size)
4) There are 6 methods available in this implementation. However, it is possible to go further and implement various base element types, differences of a given size, various weights distributions for the differences etc. Implemented approaches are the most common used in practice as the more complicated recombination procedure, the higher computation cost is.
5) For ModFourthDeJong objective function as I was able to find a point for which the objective function value is 8.86549 which is significantly lower than 12.3724219287 :
DE type:    bestMemberWithJitter
Crossover type:    normal
Apply Bounds:    true
CrossoverProb:    0.25
NumOfPopulationMembers:    500
PrintFullInfo:    false
StepsizeWeight:    0.2
MaxIterations
Point: [ 0.299015; 0.352861; -0.0306954; -0.349516; 0.202407; 0.111475; 0.0783742; -0.0640798; 0.284987; -0.00386122; 0.134481; -0.174184; -0.0188605; 0.217705; 0.0557937; 0.176954; -0.0757169; 0.219995; -0.079788; -0.142831; -0.129607; 0.135615; -0.152286; 0.0420379; -0.193061; 0.0582583; -0.0617313; -0.238126; -0.11224; -0.069721 ]
Objective function value: 8.86549
However, this is the best result only. Usually, the algorithm was stuck in several local minimas - most of them in [10;15] range. Further investigation is needed.
6) I have problem with Griewangk function too. I am not able to find fully successful method although the objective function value oscillated around 0.1 which is not bad. It needs to be verified.

I find the bestMemberWithJitter method the most successful and this is the only reason I set it as default method to be used. Hope it helps. I am happy to answer your questions. In case my patch does not work properly, please use changed files directly. 

Kind regards,
Mateusz Kapturski 

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2012-11-06 00:29

Message:
Mateusz,
    thanks for the contribution.  However, the patch is made practically
unreadable by the fact that you re-indented the files (for instance, the
Constraint class shows as completely changed, whereas you only actually
added the lowerBound and upperBound methods).

May you reformat the files so that they match the original indentation, and
therefore so that the patch only contains the actual differences?  This
might seem picky on my part, and I know I'm asking some work; but on the
one hand, as I said, the patch (and the diffs from version-control, once
your changes get in) would be made more clearly readable, and on the other
hand, having a consistent format in the library sources makes it easier to
see the context.

Thanks,
    Luigi


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

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

Re: [Quantlib-dev] quantlib-swig python compilation

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

running

./configure CXXFLAGS=-O2

should help (the default flags are -g -O2, which cause g++ to include
debug information in the generated library).

Luigi


On Sat, Nov 3, 2012 at 4:38 AM, alex belyakov <ale...@pi...> wrote:
>
> I compiled quantlib-swig (1.1) with quantlib (1.2)  for python on debian 6.04
> (more or less following instructions on
> http://blog.quantess.net/2012/09/26/quantlib-get-it-working-on-ubuntu/ )
>
> and the file size of the resulting _QuanLib.so file is about 27MB while in
> quantlib-python package this file has 8MB size
>
> does anybody know how to get it to 8MB ??  [maybe need some additional
> switches for ./configure? ]
>
>
>
>
>
> --
> View this message in context: http://old.nabble.com/quantlib-swig-python-compilation-tp34635613p34635613.html
> Sent from the quantlib-dev mailing list archive at Nabble.com.
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] In arrears adjustment

[pan z. <pan...@ga...>]

http://www.xfcbbs.com/plugin.php?id=dsu_paulpromotionpro:dsu_paulpromotionpro

On Sat, Nov 3, 2012 at 2:09 PM, Peter Caspers <pca...@gm...>wrote:

> Hi,
>
> I think the in arrears adjustment in couponpricer.cpp is computed
> slightly wrong. Shouldn't it be like in the adjusted code below?
>
> Thanks, Peter
>
> ql/cashflows/couponpricer.cpp
>
>               // see Hull, 4th ed., page 550
>               QL_REQUIRE(!capletVolatility().empty(),
>                          "missing optionlet volatility");
>               Date d1 = coupon_->fixingDate(),
> +                 d2 = coupon_->index()->valueDate(d1),
>                    referenceDate = capletVolatility()->referenceDate();
>               if (d1 <= referenceDate) {
>                   adjustement = 0.0;
>               } else {
> -                Date d2 = coupon_->index()->maturityDate(d1);
> -                Time tau =
> coupon_->index()->dayCounter().yearFraction(d1, d2);
> +                Date d3 = coupon_->index()->maturityDate(d2);
> +                Time tau =
> coupon_->index()->dayCounter().yearFraction(d2, d3);
>                   Real variance = capletVolatility()->blackVariance(d1,
> fixing);
>                   adjustement =
> fixing*fixing*variance*tau/(1.0+fixing*tau);
>               }
>
>
>
>
> ------------------------------------------------------------------------------
> LogMeIn Central: Instant, anywhere, Remote PC access and management.
> Stay in control, update software, and manage PCs from one command center
> Diagnose problems and improve visibility into emerging IT issues
> Automate, monitor and manage. Do more in less time with Central
> http://p.sf.net/sfu/logmein12331_d2d
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[Quantlib-dev] In arrears adjustment

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

Hi,

I think the in arrears adjustment in couponpricer.cpp is computed 
slightly wrong. Shouldn't it be like in the adjusted code below?

Thanks, Peter

ql/cashflows/couponpricer.cpp

              // see Hull, 4th ed., page 550
              QL_REQUIRE(!capletVolatility().empty(),
                         "missing optionlet volatility");
              Date d1 = coupon_->fixingDate(),
+                 d2 = coupon_->index()->valueDate(d1),
                   referenceDate = capletVolatility()->referenceDate();
              if (d1 <= referenceDate) {
                  adjustement = 0.0;
              } else {
-                Date d2 = coupon_->index()->maturityDate(d1);
-                Time tau = 
coupon_->index()->dayCounter().yearFraction(d1, d2);
+                Date d3 = coupon_->index()->maturityDate(d2);
+                Time tau = 
coupon_->index()->dayCounter().yearFraction(d2, d3);
                  Real variance = capletVolatility()->blackVariance(d1, 
fixing);
                  adjustement = fixing*fixing*variance*tau/(1.0+fixing*tau);
              }

[Quantlib-dev] quantlib-swig python compilation

[alex b. <ale...@pi...>]

I compiled quantlib-swig (1.1) with quantlib (1.2)  for python on debian 6.04 
(more or less following instructions on
http://blog.quantess.net/2012/09/26/quantlib-get-it-working-on-ubuntu/ )

and the file size of the resulting _QuanLib.so file is about 27MB while in
quantlib-python package this file has 8MB size  

does anybody know how to get it to 8MB ??  [maybe need some additional
switches for ./configure? ]





-- 
View this message in context: http://old.nabble.com/quantlib-swig-python-compilation-tp34635613p34635613.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] [ quantlib-Patches-3582579 ] Differential Evolution improvement

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

Patches item #3582579, was opened at 2012-11-01 15:38
Message generated for change (Tracker Item Submitted) made by fenixcitizen
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3582579&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: Mateusz Kapturski (fenixcitizen)
Assigned to: Nobody/Anonymous (nobody)
Summary: Differential Evolution improvement

Initial Comment:
Hi All,
I have come across the new implementation of Differential Evolution that appeared in QuantLib HEAD source code recently. I decided to improve it slightly. I took performance very seriously as the DE implementation should be light in order to avoid unnecessary time overhead. 

The most significant change is that I use DiffEvolConfiguration object that defines the behavior of the algorithm. The reason is that it makes the implementation more flexible. There are dozens of DE variants... I tried to be in line with current QuantLib optimization interface.

Important changes:
1) DE Optimizer consumes configuration object that defines its behavior - as I mentioned, the number of variations of the DE algorithm is huge. This approach makes it possible to extend the implementations in the future.
2) Constraints that define search space are not the part of the algorithm itself - this is why additional upperBound and lowerBound functions were added to Constraint object. NonhomogeneousBoundaryConstraint to define box constraints was added too. The other aspect is if the bounds are going to be valid for emerging populations - practical advise is that it should as for certain parameters, new populations seem to diverge. On the other hand, it adds some additional overhead. General observation is that it is always possible to improve performance for a given objective function. One needs to find appropriate DE configuration only.
3) I added three different crossover types: normal, binomial and exponential (the name for the first crossover type comes from the fact that assuming binomial crossover, the number of mutants taken into account in a given population converges in distribution to normal variable for growing problem size)
4) There are 6 methods available in this implementation. However, it is possible to go further and implement various base element types, differences of a given size, various weights distributions for the differences etc. Implemented approaches are the most common used in practice as the more complicated recombination procedure, the higher computation cost is.
5) For ModFourthDeJong objective function as I was able to find a point for which the objective function value is 8.86549 which is significantly lower than 12.3724219287 :
DE type:    bestMemberWithJitter
Crossover type:    normal
Apply Bounds:    true
CrossoverProb:    0.25
NumOfPopulationMembers:    500
PrintFullInfo:    false
StepsizeWeight:    0.2
MaxIterations
Point: [ 0.299015; 0.352861; -0.0306954; -0.349516; 0.202407; 0.111475; 0.0783742; -0.0640798; 0.284987; -0.00386122; 0.134481; -0.174184; -0.0188605; 0.217705; 0.0557937; 0.176954; -0.0757169; 0.219995; -0.079788; -0.142831; -0.129607; 0.135615; -0.152286; 0.0420379; -0.193061; 0.0582583; -0.0617313; -0.238126; -0.11224; -0.069721 ]
Objective function value: 8.86549
However, this is the best result only. Usually, the algorithm was stuck in several local minimas - most of them in [10;15] range. Further investigation is needed.
6) I have problem with Griewangk function too. I am not able to find fully successful method although the objective function value oscillated around 0.1 which is not bad. It needs to be verified.

I find the bestMemberWithJitter method the most successful and this is the only reason I set it as default method to be used. Hope it helps. I am happy to answer your questions. In case my patch does not work properly, please use changed files directly. 

Kind regards,
Mateusz Kapturski 

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

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

Re: [Quantlib-dev] CDS last period

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

Hi Peter,

Thank you again.
I never needed a clean helper, a conventional helper is yet another 
exotic possibility.

Give me a few days to have a look at the code pls.

Regards
Pepe

----- Mail original -----
De: "Peter Caspers" <pca...@gm...>
À: ja...@fr...
Cc: qua...@li..., "Luigi Ballabio" <lui...@gm...>
Envoyé: Jeudi 25 Octobre 2012 21:37:23
Objet: Re: [Quantlib-dev] CDS last period

Hi Pepe,

thanks a lot for your review and the testing. Sounds promising to me?

I added some more things to account for your test case below. The main 
idea is to identify standard cds by the date generation rule CDS and 
treat all other cases with the old code. I think your case should work 
now, I get exactly the same hazard rates in both termstructures. It 
would be great if you could do some more testing and review the new 
changes. I also corrected the sign typo in the engine.

I don't use CDS quotes with upfronts. Is the dirty upfront quoted or the 
clean upfront (or is both possible) ? In the latter cases we'd have to 
extend the upfront helper such that it can return the clean upfront in 
impliedQuote, right ? Do we need this ?

Kind regards
Peter

Am 24.10.2012 19:13, schrieb ja...@fr...:
> Hi,
> sorry I took a holiday break and ignored email.
>
> Thank you for the code, it works as we wanted. The agreement with the markit converter I get is always within 1bp for different spreads levels. Also i tested for two different dates (small and large rebates).
> Theres only one problem I had not thought of, and it is comning from what we are doing in the constructor of a run only quoted CDS:
> As a result if one bootstraps from market upfront cds and then reconstructs the run only cds helpers through the fair spreads of the cds-s (not the conventional of course) and rebootstrap with the new helpers... instead of obtaining the same hazard rates one gets differences in probabilities over 5%. This is because the run only CDS sets a fictitious upfront payment of zero amount on the schedule[0] date so the RPV01 of the upfront is zero since it lies in the past. The rebate amount uses this date and it is now multiplied by zero and therefore unaccounted for.
> I have changed line 58 of 'creditdefaultswap.cpp' to
>          upfrontPayment_.reset(new SimpleCashFlow(0.0, protectionStart_));
> another option might have to use the protection start for the RPV01 of the rebate since this solution is still wrong because the forward case has non zero probability of knocking out the cds (and then the rebate). Even better might be to have a separate cashflow meber for the rebate, maybe of boost::optional type (and possibly the upfront too should be optional).
>
> Other minor comments: looks like theres a typo on the directionality sign of the rebate in 'integralcdsengine.cpp' and would it be better for performance to have the rebate accrual called within the upfPV01 calculation braces?
>
> Pls, tell me what you think
> Best
> Pepe
>
>
>
> ----- Mail original -----
> De: "Peter Caspers"<pca...@gm...>
> À: "Luigi Ballabio"<lui...@gm...>
> Cc:ja...@fr...,qua...@li...
> Envoyé: Lundi 22 Octobre 2012 21:17:28
> Objet: Re: [Quantlib-dev] CDS last period
>
> Yes. In fact I forgot to commit the adjusted curve calibration helpers
> which I did now to make the picture complete.
>
> https://github.com/pcaspers/quantlib/commit/3d92da52262599d2b0f158ff2488988b75a1b168
>
> Also I should mention that the extensions are defensive in the sense
> that existing code will not change its behaviour. This is at the cost of
> usability though since the arguments are not really in a logical order
> any more. Also the default values will not represent the usual market
> conventions. Both could be changed easily and should be done in my
> opinion, but I leave this decision to Luigi and the other admins.
>
> Thank you, Peter
>
> Am 20.10.2012 23:20, schrieb Luigi Ballabio:
>> Great.  For those not familiar with github, Peter's changes are at
>> <https://github.com/pcaspers/quantlib/commit/878a76d610a451239e2ebf70f808f4629175f557>.
>>   From the link above, it's also possible to add notes to the changes.
>> As Peter says, it would be great if someone could have a look.
>>
>> Luigi
>>
>> On Sat, Oct 20, 2012 at 6:15 PM, Peter Caspers<pca...@gm...>  wrote:
>>> Hi Luigi, Pepe, Roland,
>>>
>>> I put my changes on a github (pcaspers) forked from Luigis. Following Pepes
>>> case below I added a test case comparing the conventional spread computed
>>> with ql and the traded spread in the Bloomberg (yielding 431.6945 bp in ql
>>> versus 431.6329 bp in BBG which seems quite good). The testsuite runs
>>> without errors under the changes.
>>>
>>> I am neither a CDS nor a quantlib expert, so it would be great if someone
>>> could have a look ...
>>>
>>> Peter
>>>
>>> Am 17.10.2012 10:59, schrieb Luigi Ballabio:
>>>
>>>> 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, sch...@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, sch...@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,

thanks a lot for your review and the testing. Sounds promising to me?

I added some more things to account for your test case below. The main 
idea is to identify standard cds by the date generation rule CDS and 
treat all other cases with the old code. I think your case should work 
now, I get exactly the same hazard rates in both termstructures. It 
would be great if you could do some more testing and review the new 
changes. I also corrected the sign typo in the engine.

I don't use CDS quotes with upfronts. Is the dirty upfront quoted or the 
clean upfront (or is both possible) ? In the latter cases we'd have to 
extend the upfront helper such that it can return the clean upfront in 
impliedQuote, right ? Do we need this ?

Kind regards
Peter

Am 24.10.2012 19:13, schrieb ja...@fr...:
> Hi,
> sorry I took a holiday break and ignored email.
>
> Thank you for the code, it works as we wanted. The agreement with the markit converter I get is always within 1bp for different spreads levels. Also i tested for two different dates (small and large rebates).
> Theres only one problem I had not thought of, and it is comning from what we are doing in the constructor of a run only quoted CDS:
> As a result if one bootstraps from market upfront cds and then reconstructs the run only cds helpers through the fair spreads of the cds-s (not the conventional of course) and rebootstrap with the new helpers... instead of obtaining the same hazard rates one gets differences in probabilities over 5%. This is because the run only CDS sets a fictitious upfront payment of zero amount on the schedule[0] date so the RPV01 of the upfront is zero since it lies in the past. The rebate amount uses this date and it is now multiplied by zero and therefore unaccounted for.
> I have changed line 58 of 'creditdefaultswap.cpp' to
>          upfrontPayment_.reset(new SimpleCashFlow(0.0, protectionStart_));
> another option might have to use the protection start for the RPV01 of the rebate since this solution is still wrong because the forward case has non zero probability of knocking out the cds (and then the rebate). Even better might be to have a separate cashflow meber for the rebate, maybe of boost::optional type (and possibly the upfront too should be optional).
>
> Other minor comments: looks like theres a typo on the directionality sign of the rebate in 'integralcdsengine.cpp' and would it be better for performance to have the rebate accrual called within the upfPV01 calculation braces?
>
> Pls, tell me what you think
> Best
> Pepe
>
>
>
> ----- Mail original -----
> De: "Peter Caspers"<pca...@gm...>
> À: "Luigi Ballabio"<lui...@gm...>
> Cc:ja...@fr...,qua...@li...
> Envoyé: Lundi 22 Octobre 2012 21:17:28
> Objet: Re: [Quantlib-dev] CDS last period
>
> Yes. In fact I forgot to commit the adjusted curve calibration helpers
> which I did now to make the picture complete.
>
> https://github.com/pcaspers/quantlib/commit/3d92da52262599d2b0f158ff2488988b75a1b168
>
> Also I should mention that the extensions are defensive in the sense
> that existing code will not change its behaviour. This is at the cost of
> usability though since the arguments are not really in a logical order
> any more. Also the default values will not represent the usual market
> conventions. Both could be changed easily and should be done in my
> opinion, but I leave this decision to Luigi and the other admins.
>
> Thank you, Peter
>
> Am 20.10.2012 23:20, schrieb Luigi Ballabio:
>> Great.  For those not familiar with github, Peter's changes are at
>> <https://github.com/pcaspers/quantlib/commit/878a76d610a451239e2ebf70f808f4629175f557>.
>>   From the link above, it's also possible to add notes to the changes.
>> As Peter says, it would be great if someone could have a look.
>>
>> Luigi
>>
>> On Sat, Oct 20, 2012 at 6:15 PM, Peter Caspers<pca...@gm...>  wrote:
>>> Hi Luigi, Pepe, Roland,
>>>
>>> I put my changes on a github (pcaspers) forked from Luigis. Following Pepes
>>> case below I added a test case comparing the conventional spread computed
>>> with ql and the traded spread in the Bloomberg (yielding 431.6945 bp in ql
>>> versus 431.6329 bp in BBG which seems quite good). The testsuite runs
>>> without errors under the changes.
>>>
>>> I am neither a CDS nor a quantlib expert, so it would be great if someone
>>> could have a look ...
>>>
>>> Peter
>>>
>>> Am 17.10.2012 10:59, schrieb Luigi Ballabio:
>>>
>>>> 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, sch...@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, sch...@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

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

Hi,
sorry I took a holiday break and ignored email.

Thank you for the code, it works as we wanted. The agreement with the markit converter I get is always within 1bp for different spreads levels. Also i tested for two different dates (small and large rebates).
Theres only one problem I had not thought of, and it is comning from what we are doing in the constructor of a run only quoted CDS:
As a result if one bootstraps from market upfront cds and then reconstructs the run only cds helpers through the fair spreads of the cds-s (not the conventional of course) and rebootstrap with the new helpers... instead of obtaining the same hazard rates one gets differences in probabilities over 5%. This is because the run only CDS sets a fictitious upfront payment of zero amount on the schedule[0] date so the RPV01 of the upfront is zero since it lies in the past. The rebate amount uses this date and it is now multiplied by zero and therefore unaccounted for.
I have changed line 58 of 'creditdefaultswap.cpp' to 
        upfrontPayment_.reset(new SimpleCashFlow(0.0, protectionStart_));
another option might have to use the protection start for the RPV01 of the rebate since this solution is still wrong because the forward case has non zero probability of knocking out the cds (and then the rebate). Even better might be to have a separate cashflow meber for the rebate, maybe of boost::optional type (and possibly the upfront too should be optional).

Other minor comments: looks like theres a typo on the directionality sign of the rebate in 'integralcdsengine.cpp' and would it be better for performance to have the rebate accrual called within the upfPV01 calculation braces?

Pls, tell me what you think
Best
Pepe



----- Mail original -----
De: "Peter Caspers" <pca...@gm...>
À: "Luigi Ballabio" <lui...@gm...>
Cc: ja...@fr..., qua...@li...
Envoyé: Lundi 22 Octobre 2012 21:17:28
Objet: Re: [Quantlib-dev] CDS last period

Yes. In fact I forgot to commit the adjusted curve calibration helpers 
which I did now to make the picture complete.

https://github.com/pcaspers/quantlib/commit/3d92da52262599d2b0f158ff2488988b75a1b168

Also I should mention that the extensions are defensive in the sense 
that existing code will not change its behaviour. This is at the cost of 
usability though since the arguments are not really in a logical order 
any more. Also the default values will not represent the usual market 
conventions. Both could be changed easily and should be done in my 
opinion, but I leave this decision to Luigi and the other admins.

Thank you, Peter

Am 20.10.2012 23:20, schrieb Luigi Ballabio:
> Great.  For those not familiar with github, Peter's changes are at
> <https://github.com/pcaspers/quantlib/commit/878a76d610a451239e2ebf70f808f4629175f557>.
>  From the link above, it's also possible to add notes to the changes.
> As Peter says, it would be great if someone could have a look.
>
> Luigi
>
> On Sat, Oct 20, 2012 at 6:15 PM, Peter Caspers <pca...@gm...> wrote:
>> Hi Luigi, Pepe, Roland,
>>
>> I put my changes on a github (pcaspers) forked from Luigis. Following Pepes
>> case below I added a test case comparing the conventional spread computed
>> with ql and the traded spread in the Bloomberg (yielding 431.6945 bp in ql
>> versus 431.6329 bp in BBG which seems quite good). The testsuite runs
>> without errors under the changes.
>>
>> I am neither a CDS nor a quantlib expert, so it would be great if someone
>> could have a look ...
>>
>> Peter
>>
>> Am 17.10.2012 10:59, schrieb Luigi Ballabio:
>>
>>> 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] Marketmodel AbcdVol

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

I've added the fix and the tests, thanks.

Luigi

On Sat, Sep 8, 2012 at 3:38 PM, Peter Caspers <pca...@gm...> wrote:
> Hi Nando,
>
> I added a test case to the marketmodel suite.
>
> In fact while doing this I noticed that AbcdFunction::primitive(...) fails
> when c is zero. I fixed that and added another test case covering this.
>
> Peter
>
>
>> Hi Peter
>>
>>> [...] the particular choice of the evolutionTimes grid being
>>> strictly finer than the rateTimes grid (which is equal to the correlation
>>> times grid coming from a TimeHomogeneousForwardCorrelation). This case is
>>> in
>>> my opinion not handled correctly when computing the covariance matrices
>>> for
>>> the evolution steps in the constructor of AbcdVol.
>>
>> yes, you're right: I've just committed your bug-fix to both AbcdVol
>> and FlatVol (which was affected too).
>> Thank you and sorry it took so long.
>>
>> Any chance you might contribute a unit test to avoid regressions? I am
>> thinking about a simple flat vol (and degenerate abcd vol with
>> a=b=c=0.0) test case where for N evolution times there are 1, N, 2N,
>> 2N+1 correlation matrices, checking that total variances are correct
>>
>> ciao -- Nando
>
>
>
> ------------------------------------------------------------------------------
> 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-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[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 (Comment added) made by lballabio
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. 

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

>Comment By: Luigi Ballabio (lballabio)
Date: 2012-10-24 07:12

Message:
May you contribute a test case for these?

Thanks,
    Luigi


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

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

[Quantlib-dev] [ quantlib-Bugs-3579723 ] Epiphany missing from Polish holiday calendar

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

Bugs item #3579723, was opened at 2012-10-24 04:29
Message generated for change (Tracker Item Submitted) made by katastrofa
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3579723&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: katastrofa (katastrofa)
Assigned to: Nobody/Anonymous (nobody)
Summary: Epiphany missing from Polish holiday calendar

Initial Comment:
Since 2011, Poland has a new state holiday: Epiphany on 6 January (http://en.wikipedia.org/wiki/Epiphany_%28holiday%29#Poland). QuantLib holiday calendar for Poland does not have it: http://quantlib.svn.sourceforge.net/viewvc/quantlib/trunk/QuantLib/ql/time/calendars/poland.cpp?revision=18354&view=markup

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

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

Re: [Quantlib-dev] ODE

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

Hi Peter,
    I've added your code to the ql/experimental/math folder.

Thanks,
    Luigi


On Fri, Sep 14, 2012 at 9:47 PM, Peter Caspers <pca...@gm...> wrote:
> Hi Luigi,
> here are some tests. I hope they are sufficient for the moment.
> Thank you, have a nice weekend
> Peter
>
> Am 12.09.2012 14:17, schrieb Luigi Ballabio:
>
>> Hi Peter,
>>      no, there's no support in the library.  And yes, a unit test would
>> be nice :)
>>
>> Thanks,
>>      Luigi
>>
>> On Sat, Sep 8, 2012 at 7:20 PM, Peter Caspers<pca...@gm...>
>> wrote:
>>>
>>> Hi Luigi, Nando,
>>> is there support for ODE integration in QuantLib ? I think I looked for
>>> it
>>> several times but did not find anything obvious.
>>> I have translated the Runge Kutta method from the numerical recipes to
>>> QuantLib style (or my perception of it ;-) ) with support for real and
>>> complex valued ODEs. If you want, you can add it to the lib. Also, if you
>>> want I can provide a unit test.
>>> with regards
>>> Peter
>>>
>>>
>

Re: [Quantlib-dev] thread safe session handling via TSS

[Riccardo G. <rg...@la...>]

Not directly, no.
I've looked at mortoray patch. Unfortunately that scheme is not 
compatible with thread storage;  having a per-thread instance makes all 
the sessionId/sessionIdFunc machinery useless.  In a way, is implicitly 
handled.  Likewise for the instances_ map.

On the other hand, perhaps I can rework the tss patch to avoid including 
boost thread headers in singleton.hpp, if we don't want to force 
quantlib users to compile with boost:thread.
That should preserve the main qualities of the above patch, i.e. being 
thread-safe and not requiring libboost_thread, plus the added safety, 
simplicity and performance of tss.

it might be a reasonable solution ?
Ciao,
R


-------- Original Message --------
Subject: Re: [Quantlib-dev] thread safe session handling via TSS
From: Luigi Ballabio <lui...@gm...>
To: Riccardo Ghetta <rg...@la...>
CC: qua...@li..., Ferdinando Ametrano 
<na...@am...>
Date: Tuesday, October 23, 2012 12:10:59
> Riccardo,
>     I just had a look at your patch.  Is there any chance that it can
> be made to work together with the pending patch at
> <https://github.com/mortoray/quantlib/commit/dbf6b23429b21cccb0982d6f3e5c13f5860842e1>?
>   (Yes, we have stuff all over the place and it's not easy to find it.
> Our bad.)
>
> About the contributor agreement: in the past we used something like
> the document I'm attaching.  You can scan the signed document and send
> it to me and Ferdinando (whose address is in cc).
>
> Thanks,
>      Luigi
>
>
> On Fri, Oct 19, 2012 at 3:22 PM, Riccardo Ghetta <rg...@la...> wrote:
>> Hi,
>> I've just posted a patch to enable thread safe session handling.  It
>> should also solve bug 3441748.
>> The company I work for, Thema Consulting SA (www.themaconsulting.ch),
>> uses QuantLib in its MasterFinance product and has other patches we like
>> to contribute back (as soon they're cleared by management/legal).
>>
>> BTW, is the contributor agreement needed ? Where should be sent ?
>> I searched the mailing list, but without luck.
>>
>> Ciao,
>> Riccardo Ghetta
>> Thema Consulting SA
>>
>> ------------------------------------------------------------------------------
>> Everyone hates slow websites. So do we.
>> Make your web apps faster with AppDynamics
>> Download AppDynamics Lite for free today:
>> http://p.sf.net/sfu/appdyn_sfd2d_oct
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] thread safe session handling via TSS

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

Riccardo,
   I just had a look at your patch.  Is there any chance that it can
be made to work together with the pending patch at
<https://github.com/mortoray/quantlib/commit/dbf6b23429b21cccb0982d6f3e5c13f5860842e1>?
 (Yes, we have stuff all over the place and it's not easy to find it.
Our bad.)

About the contributor agreement: in the past we used something like
the document I'm attaching.  You can scan the signed document and send
it to me and Ferdinando (whose address is in cc).

Thanks,
    Luigi


On Fri, Oct 19, 2012 at 3:22 PM, Riccardo Ghetta <rg...@la...> wrote:
> Hi,
> I've just posted a patch to enable thread safe session handling.  It
> should also solve bug 3441748.
> The company I work for, Thema Consulting SA (www.themaconsulting.ch),
> uses QuantLib in its MasterFinance product and has other patches we like
> to contribute back (as soon they're cleared by management/legal).
>
> BTW, is the contributor agreement needed ? Where should be sent ?
> I searched the mailing list, but without luck.
>
> Ciao,
> Riccardo Ghetta
> Thema Consulting SA
>
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_sfd2d_oct
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] [ quantlib-Bugs-3578423 ] undeclared identifier

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

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

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: https://www.google.com/accounts ()
>Assigned to: Luigi Ballabio (lballabio)
Summary: undeclared identifier

Initial Comment:
When I try to compile the example function provided in the 2nd part of the PDF by Dimitri Reiswich on slide 92, I get the following error in my Visual Studio 2010  : 

error C2065: 'InterpolatedDiscountCurve' : undeclared identifier	

How do I get around this?

thanks


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

>Comment By: Luigi Ballabio (lballabio)
Date: 2012-10-23 01:29

Message:
The code in the PDF is for illustration sake and is not complete.
To compile it, download the ZIP archive of the code samples from
<http://quantlib.org/docs.shtml>.


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

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

Re: [Quantlib-dev] CDS last period

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

Yes. In fact I forgot to commit the adjusted curve calibration helpers 
which I did now to make the picture complete.

https://github.com/pcaspers/quantlib/commit/3d92da52262599d2b0f158ff2488988b75a1b168

Also I should mention that the extensions are defensive in the sense 
that existing code will not change its behaviour. This is at the cost of 
usability though since the arguments are not really in a logical order 
any more. Also the default values will not represent the usual market 
conventions. Both could be changed easily and should be done in my 
opinion, but I leave this decision to Luigi and the other admins.

Thank you, Peter

Am 20.10.2012 23:20, schrieb Luigi Ballabio:
> Great.  For those not familiar with github, Peter's changes are at
> <https://github.com/pcaspers/quantlib/commit/878a76d610a451239e2ebf70f808f4629175f557>.
>  From the link above, it's also possible to add notes to the changes.
> As Peter says, it would be great if someone could have a look.
>
> Luigi
>
> On Sat, Oct 20, 2012 at 6:15 PM, Peter Caspers <pca...@gm...> wrote:
>> Hi Luigi, Pepe, Roland,
>>
>> I put my changes on a github (pcaspers) forked from Luigis. Following Pepes
>> case below I added a test case comparing the conventional spread computed
>> with ql and the traded spread in the Bloomberg (yielding 431.6945 bp in ql
>> versus 431.6329 bp in BBG which seems quite good). The testsuite runs
>> without errors under the changes.
>>
>> I am neither a CDS nor a quantlib expert, so it would be great if someone
>> could have a look ...
>>
>> Peter
>>
>> Am 17.10.2012 10:59, schrieb Luigi Ballabio:
>>
>>> 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

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

Great.  For those not familiar with github, Peter's changes are at
<https://github.com/pcaspers/quantlib/commit/878a76d610a451239e2ebf70f808f4629175f557>.
>From the link above, it's also possible to add notes to the changes.
As Peter says, it would be great if someone could have a look.

Luigi

On Sat, Oct 20, 2012 at 6:15 PM, Peter Caspers <pca...@gm...> wrote:
> Hi Luigi, Pepe, Roland,
>
> I put my changes on a github (pcaspers) forked from Luigis. Following Pepes
> case below I added a test case comparing the conventional spread computed
> with ql and the traded spread in the Bloomberg (yielding 431.6945 bp in ql
> versus 431.6329 bp in BBG which seems quite good). The testsuite runs
> without errors under the changes.
>
> I am neither a CDS nor a quantlib expert, so it would be great if someone
> could have a look ...
>
> Peter
>
> Am 17.10.2012 10:59, schrieb Luigi Ballabio:
>
>> 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 Luigi, Pepe, Roland,

I put my changes on a github (pcaspers) forked from Luigis. Following 
Pepes case below I added a test case comparing the conventional spread 
computed with ql and the traded spread in the Bloomberg (yielding 
431.6945 bp in ql versus 431.6329 bp in BBG which seems quite good). The 
testsuite runs without errors under the changes.

I am neither a CDS nor a quantlib expert, so it would be great if 
someone could have a look ...

Peter

Am 17.10.2012 10:59, schrieb Luigi Ballabio:
> 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

[Quantlib-dev] [ quantlib-Bugs-3578423 ] undeclared identifier

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

Bugs item #3578423, was opened at 2012-10-19 12:15
Message generated for change (Tracker Item Submitted) made by 
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=3578423&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: https://www.google.com/accounts ()
Assigned to: Nobody/Anonymous (nobody)
Summary: undeclared identifier

Initial Comment:
When I try to compile the example function provided in the 2nd part of the PDF by Dimitri Reiswich on slide 92, I get the following error in my Visual Studio 2010  : 

error C2065: 'InterpolatedDiscountCurve' : undeclared identifier	

How do I get around this?

thanks


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

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

[Quantlib-dev] Small error in QuantLibXL (leg.xml)

[Sebastian P. <Seb...@gm...>]

Hi,

I do not know if this is the right place to report small errors/typos in the
quantlib environment. Given that I don't know any other place I will post it
here this time.

In the QuantLibAddin\gensrc\metadata\functions\leg.xml the static function
QuantLib::CashFlows::startDate is called for qlLegStartDate and
qlLegMaturityDate. I suppose the latter is not the expected behaviour:
  <!-- Leg Date functions -->

    <Procedure name='qlLegStartDate'>
      <description>Returns the start (i.e. first accrual) date for the given
Leg object.</description>
      <alias>QuantLib::CashFlows::startDate</alias>    
<<-------------------------------------------
      <SupportedPlatforms>
        <SupportedPlatform name='Excel'/>
        <!--SupportedPlatform name='Cpp'/-->
      </SupportedPlatforms>
      <ParameterList>
        <Parameters>
          <Parameter name='ObjectId'>
            <type>QuantLib::Leg</type>
            <superType>underlyingClass</superType>
            <tensorRank>scalar</tensorRank>
            <description>id of existing QuantLib::Leg object</description>
          </Parameter>
        </Parameters>
      </ParameterList>
      <ReturnValue>
        <type>QuantLib::Date</type>
        <tensorRank>scalar</tensorRank>
      </ReturnValue>
    </Procedure>

    <Procedure name='qlLegMaturityDate'>
      <description>Returns the maturity (i.e. last payment) date for the
given Leg object.</description>
      <alias>QuantLib::CashFlows::startDate</alias> 
<<----------------------------------------------
      <SupportedPlatforms>
        <SupportedPlatform name='Excel'/>
        <!--SupportedPlatform name='Cpp'/-->
      </SupportedPlatforms>
      <ParameterList>
        <Parameters>
          <Parameter name='ObjectId'>
            <type>QuantLib::Leg</type>
            <superType>underlyingClass</superType>
            <tensorRank>scalar</tensorRank>
            <description>id of existing QuantLib::Leg object</description>
          </Parameter>
        </Parameters>
      </ParameterList>
      <ReturnValue>
        <type>QuantLib::Date</type>
        <tensorRank>scalar</tensorRank>
      </ReturnValue>
    </Procedure>

Regards,

Sebastian
 
-- 
View this message in context: http://old.nabble.com/Small-error-in-QuantLibXL-%28leg.xml%29-tp34576796p34576796.html
Sent from the quantlib-dev mailing list archive at Nabble.com.

[Quantlib-dev] thread safe session handling via TSS

[Riccardo G. <rg...@la...>]

Hi,
I've just posted a patch to enable thread safe session handling.  It 
should also solve bug 3441748.
The company I work for, Thema Consulting SA (www.themaconsulting.ch), 
uses QuantLib in its MasterFinance product and has other patches we like 
to contribute back (as soon they're cleared by management/legal).

BTW, is the contributor agreement needed ? Where should be sent ?
I searched the mailing list, but without luck.

Ciao,
Riccardo Ghetta
Thema Consulting SA

[Quantlib-dev] [ quantlib-Patches-3578375 ] thread-safe session handling using tss

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

Patches item #3578375, was opened at 2012-10-19 05:48
Message generated for change (Tracker Item Submitted) made by rglarix
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=3578375&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: Riccardo Ghetta (rglarix)
Assigned to: Nobody/Anonymous (nobody)
Summary: thread-safe session handling using tss

Initial Comment:
QuantLib default session handling is thread safe only if you allocate all sessions beforehand, otherwise adding/removing a session id changes the map object potentially corrupting other thread iterators.
This patch uses boost::thread_specific_ptr to have a per-thread session id. Since the variable used is thread-private and inherently linked to the thread, no sessionId() method is needed.
The patch is enabled by defining QL_ENABLE_SESSIONS_TSS in config.hpp
Without the define QuantLib uses the old code.

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

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