quantlib-users — QuantLib users discussion list

Re: [Quantlib-users] IMM rolls

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

Thanks!

On Tue, Jun 9, 2020 at 12:29 PM Tom Anderson <tw...@ur...> wrote:

> Done - i hope this is clear:
>
> https://github.com/lballabio/QuantLib/issues/833
>
> tom
>
> On Tue, 9 Jun 2020, Luigi Ballabio wrote:
>
> > Thanks, Tom.  If you think it would be useful to add code to calculate a
> > default termination date for the IMM case, may you open an issue on
> GitHub
> > so someone may eventually pick it up?
> >
> > Luigi
> >
> >
> > On Sun, Jun 7, 2020 at 10:25 PM Tom Anderson <tw...@ur...>
> wrote:
> >
> >> (following up mostly for the sake of anyone reading the archives!)
> >>
> >> I'm starting with an effective date and a tenor ("computer, what is the
> >> rate for the two year out of IMM, IMM rolls?"), so i don't have a
> >> termination date to begin with. I am using MakeVanillaSwap, which
> requires
> >> a tenor and index, but makes everything else optional and tries to work
> it
> >> out. If you use MakeVanillaSwap with a two-year tenor, an IMM effective
> >> date, and a ThirdWednesday date generation rule, you get a standard
> >> termination date, rather than an IMM one. Hence, i need to work out the
> >> right termination date, and explicitly give it to MakeVanillaSwap.
> >>
> >> tom
> >>
> >> On Tue, 2 Jun 2020, Mike DelMedico wrote:
> >>
> >>> Glad it worked.  When I build the schedules, the dates seem to flow
> fine,
> >>> so not sure why your end date wouldn't line up with the proper final
> IMM
> >>> date.  See below:
> >>>
> >>> floatSchedule = ql.Schedule(effectiveDate,
> >>>                            maturityDate,
> >>>                            ql.Period(3, ql.Months),
> >>>                            calendarUSD_FedFund,
> >>>                            ql.ModifiedFollowing,
> >>>                            ql.ModifiedFollowing,
> >>>                            ql.DateGeneration.ThirdWednesday,
> >>>                            False)
> >>>
> >>> for i in floatSchedule:
> >>>    print(i)
> >>>
> >>> June 17th, 2020
> >>> September 16th, 2020
> >>> December 16th, 2020
> >>> March 17th, 2021
> >>> June 16th, 2021
> >>> September 15th, 2021
> >>> December 15th, 2021
> >>> March 16th, 2022
> >>> June 15th, 2022
> >>> September 21st, 2022
> >>> December 21st, 2022
> >>> March 15th, 2023
> >>> June 21st, 2023
> >>>
> >>>
> >>> On Tue, Jun 2, 2020 at 2:50 PM Tom Anderson <tw...@ur...>
> >> wrote:
> >>>
> >>>> That mostly does it, thanks!
> >>>>
> >>>> For some reason, i had assumed that the accrual periods for each
> coupon
> >>>> were based directly on the frequency or index tenor, rather than
> running
> >>>> to the next date. Too much time spent looking at futures bundles
> >> probably.
> >>>>
> >>>> It seems like i also need to tweak the end date. ThirdWednesday
> >>>> specifically doesn't do that.
> >>>>
> >>>> tom
> >>>>
> >>>> On Fri, 29 May 2020, Mike DelMedico wrote:
> >>>>
> >>>>> I’m pretty sure you just flip the generator from ‘Backward” to
> >>>>> “ThirdWednesday” and you should be good to go.
> >>>>>
> >>>>> These are very common use now given everyone’s desire to minimize
> line
> >>>>> items. Much easier to compress a book of swaps that have all the
> >> cashflow
> >>>>> dates lined up instead of a book with dozens of different reset
> dates.
> >>>>>
> >>>>> The other popular flavor is IMM effective but with standard rolls.
> >>>>>
> >>>>> -Mike
> >>>>>
> >>>>>
> >>>>> On Fri, May 29, 2020 at 12:45 Tom Anderson <tw...@ur...>
> >> wrote:
> >>>>>
> >>>>>> Hello,
> >>>>>>
> >>>>>> There are some dreadful interest rate swaps which use "IMM rolls" -
> >> the
> >>>>>> cashflows are on quarterly IMM dates, and the cashflow reflects an
> >>>> accrual
> >>>>>> over the period from that IMM date to the next one.
> >>>>>>
> >>>>>> (I think. I can't find a precise definition of how these swaps work.
> >>>> They
> >>>>>> just exist.)
> >>>>>>
> >>>>>> Does QuantLib support such swaps?
> >>>>>>
> >>>>>> I can generate a custom Schedule where cashflows are on IMM dates,
> >> but i
> >>>>>> don't know of a way to tweak the accrual periods for each cashflow.
> >>>>>>
> >>>>>> Thanks,
> >>>>>> tom
> >>>>>>
> >>>>>> --
> >>>>>> 12:28 <@ashak> why wouldn't you run it as root? Yuo don't get
> >> permission
> >>>>>> denied's on things then ;)
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> QuantLib-users mailing list
> >>>>>> Qua...@li...
> >>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >>>>>>
> >>>>>
> >>>>
> >>>> --
> >>>> There are only two hard things in computer science: cache
> invalidation,
> >>>> naming things, and off-by-one errors. -- anonymous
> >>>
> >>
> >> --
> >> Wikipedia topics: lists of trains, Mortal Kombat characters, one-time
> >> villains from Mario games, road intersections, boring suburban schools,
> >> garage bands, cats, webcomics, Digimon, Bionicle characters, webforums,
> >> characters from English soap operas, and Mortal Kombat characters that
> >> don't exist --
> Uncyclopedia_______________________________________________
> >> QuantLib-users mailing list
> >> Qua...@li...
> >> https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >>
> >
>
> --
> X is for ... EXECUTION!

Re: [Quantlib-users] greeks with swaptionvolcube2

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

Hi Aleksis,  I am just guessing, but from SwaptionVolCube2 you get “sticky moneyness” deltas: If you shift the rates input, the ATM levels in the cube will change. Since the volatilities are set up relative to these ATM levels, the volatility for a given fixed strike (the one from the trade you price) changes under the rate shift as well. Since SwaptionVolCube2 uses a linear interpolation in strike direction, this might cause issues in particular at the points where the vol(strike) - function is non-differentiable.
Best Regards, Peter

> On 08 Jun 2020, at 21:22, Aleksis Ali Raza <ale...@go...> wrote:
> 
> Hi Peter. That’s correct - the delta (and vega,gamma, etc) all smoothen out to normal when I zero out the skew in the volcube.
> 
> Btw, the jags are still present when using ’Naive’ mode in the GSR calibration.
> 
> Moreover, what’s more relevant is that they are also present even when just using a simple BachelierSwaptionEngine for the vanilla swaption case so I don’t think it’s model related.
> 
> FYI, I’m using normal vols throughout (with skew definition essentially a simple +5 normal vols for each 25bp otm - both for payers and recs)
> 
> In any case, to answer your question reg gsr calibration, I think I'm doing both (a) and (b) - essentially I’ve added a modified NPV attribute to the below-mentioned swaption class. So it’s a simple 'bump up,calc NPV,bump down, calc NPV, take difference’ using this NPV attribute. Maybe i’m missing one of the steps (a) or (b) in this code?
> 
> def NPV(self):
>     engine = ql.Gaussian1dSwaptionEngine(self.model, 64, 7.0, True, False, self.discount_curve)
>     basket = self.nsswaption.calibrationBasket(self.swapbase, self.swvolcube, 'MaturityStrikeByDeltaGamma')
>     for basket_i in basket:
>         ql.as_black_helper(basket_i).setPricingEngine(engine)
>     method = ql.LevenbergMarquardt()
>     ec = ql.EndCriteria(1000, 10, 1e-8, 1e-8, 1e-8)
>     self.model.calibrateVolatilitiesIterative(basket, method, ec)
>     npv = self.nsswaption.NPV()*self.position
>     return npv
> 
> 
> 
>> On Jun 8, 2020, at 7:21 PM, Peter Caspers <pca...@gm... <mailto:pca...@gm...>> wrote:
>> 
>> Hi Aleksis,
>> 
>> do you get the jags only when using a smile, i.e. does the delta get smoother when you use an ATM matrix only?
>> 
>> Another question I have is a) whether you recalibrate the GSR model after each bump and b) whether you recalculate the calibration basket after each bump as well?
>> 
>> Thanks
>> Peter
>> 
>>> On 08 Jun 2020, at 17:31, Aleksis Ali Raza via QuantLib-users <qua...@li... <mailto:qua...@li...>> wrote:
>>> 
>>> Sure, essentially it’s run off this class:
>>> 
>>> class bermudanswaption():
>>> 
>>>     def __init__(self, calendar,settlement, used_model, swap, ratecurves, index, swvolcube_clean, swapbase,
>>>                  mean_reversion,position):
>>> 
>>>         discount_curve = ratecurves.loc['discountcurve', 'ratecurves']
>>>         self.swvolcube = swvolcube_clean
>>>         self.swapbase = swapbase
>>>         self.used_model = used_model
>>>         self.discount_curve = discount_curve
>>>         self.position=position
>>> 
>>>         fixed_schedule=swap.fixedSchedule()
>>>         exerciseDates = [calendar.advance(i, -ql.Period('2D')) for i in fixed_schedule][1:-1]
>>>         exercise = ql.BermudanExercise(exerciseDates)
>>>         stepDates = exerciseDates
>>>         self.exerciseDates=exerciseDates
>>>         sigmas = [ql.QuoteHandle(ql.SimpleQuote(0.01))]*(1+len(exerciseDates))
>>>         self.used_model = used_model
>>> 
>>>         if settlement == 'physical':
>>>             type = 0
>>>             method = 1
>>>         else:
>>>             type = 1
>>>             method = 3
>>> 
>>>         self.nsswaption = ql.NonstandardSwaption(swap, exercise, type, method)
>>>         gsr = ql.Gsr(ratecurves.loc[index, 'ratecurves'],
>>>                      stepDates, sigmas, [ql.QuoteHandle(ql.SimpleQuote(mean_reversion))])
>>>         engine = ql.Gaussian1dNonstandardSwaptionEngine(gsr, 64, 7.0, True, False,
>>>                                                         ql.QuoteHandle(ql.SimpleQuote(0)),
>>>                                                         discount_curve, 2)
>>>         self.engine = ql.Gaussian1dSwaptionEngine(gsr, 64, 7.0, True, False, discount_curve)
>>>         self.nsswaption.setPricingEngine(engine)
>>>         self.model = gsr
>>> 
>>> 
>>> 
>>> 
>>>> On 8 Jun 2020, at 15:50, Christofer Bogaso <bog...@gm... <mailto:bog...@gm...>> wrote:
>>>> 
>>>> Hi, could you please share your python code? Thanks,
>>>> 
>>>> On Mon, Jun 8, 2020 at 8:00 PM Aleksis Ali Raza via QuantLib-users <qua...@li... <mailto:qua...@li...>> wrote:
>>>> Hi. In case anyone has an explanation: I get a jagged behaviour in a my greeks when I define a (what is to my knowledge sensible) swaption smile using swaptionvolcube2.
>>>> 
>>>> The greeks are being calculated by source bumping (using a 1bp shift for the rate delta, shown below along with the NPV). The behaviour isn’t too sensitive to the bump size.
>>>> 
>>>> Portfolio 1 consists of a 1y4y otm payer swaption and Portfolio 2 of a same strike 5y otm bermudan swaption with annual calls (both valued using the Hull-White GSR model calibrated to the swaption vol cube with MaturityStrikeByDeltaGamma mode). 
>>>> 
>>>> The code is in Python.
>>>> 
>>>> Thanks, Aleksis
>>>>  
>>>> 
>>>> <optionanalysis_rate.png>
>>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li... <mailto:Qua...@li...>
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users <https://lists.sourceforge.net/lists/listinfo/quantlib-users>
>>> 
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li... <mailto:Qua...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users <https://lists.sourceforge.net/lists/listinfo/quantlib-users>
>> 
> 

Re: [Quantlib-users] IMM rolls

[Tom A. <tw...@ur...>]

Done - i hope this is clear:

https://github.com/lballabio/QuantLib/issues/833

tom

On Tue, 9 Jun 2020, Luigi Ballabio wrote:

> Thanks, Tom.  If you think it would be useful to add code to calculate a
> default termination date for the IMM case, may you open an issue on GitHub
> so someone may eventually pick it up?
>
> Luigi
>
>
> On Sun, Jun 7, 2020 at 10:25 PM Tom Anderson <tw...@ur...> wrote:
>
>> (following up mostly for the sake of anyone reading the archives!)
>>
>> I'm starting with an effective date and a tenor ("computer, what is the
>> rate for the two year out of IMM, IMM rolls?"), so i don't have a
>> termination date to begin with. I am using MakeVanillaSwap, which requires
>> a tenor and index, but makes everything else optional and tries to work it
>> out. If you use MakeVanillaSwap with a two-year tenor, an IMM effective
>> date, and a ThirdWednesday date generation rule, you get a standard
>> termination date, rather than an IMM one. Hence, i need to work out the
>> right termination date, and explicitly give it to MakeVanillaSwap.
>>
>> tom
>>
>> On Tue, 2 Jun 2020, Mike DelMedico wrote:
>>
>>> Glad it worked.  When I build the schedules, the dates seem to flow fine,
>>> so not sure why your end date wouldn't line up with the proper final IMM
>>> date.  See below:
>>>
>>> floatSchedule = ql.Schedule(effectiveDate,
>>>                            maturityDate,
>>>                            ql.Period(3, ql.Months),
>>>                            calendarUSD_FedFund,
>>>                            ql.ModifiedFollowing,
>>>                            ql.ModifiedFollowing,
>>>                            ql.DateGeneration.ThirdWednesday,
>>>                            False)
>>>
>>> for i in floatSchedule:
>>>    print(i)
>>>
>>> June 17th, 2020
>>> September 16th, 2020
>>> December 16th, 2020
>>> March 17th, 2021
>>> June 16th, 2021
>>> September 15th, 2021
>>> December 15th, 2021
>>> March 16th, 2022
>>> June 15th, 2022
>>> September 21st, 2022
>>> December 21st, 2022
>>> March 15th, 2023
>>> June 21st, 2023
>>>
>>>
>>> On Tue, Jun 2, 2020 at 2:50 PM Tom Anderson <tw...@ur...>
>> wrote:
>>>
>>>> That mostly does it, thanks!
>>>>
>>>> For some reason, i had assumed that the accrual periods for each coupon
>>>> were based directly on the frequency or index tenor, rather than running
>>>> to the next date. Too much time spent looking at futures bundles
>> probably.
>>>>
>>>> It seems like i also need to tweak the end date. ThirdWednesday
>>>> specifically doesn't do that.
>>>>
>>>> tom
>>>>
>>>> On Fri, 29 May 2020, Mike DelMedico wrote:
>>>>
>>>>> I’m pretty sure you just flip the generator from ‘Backward” to
>>>>> “ThirdWednesday” and you should be good to go.
>>>>>
>>>>> These are very common use now given everyone’s desire to minimize line
>>>>> items. Much easier to compress a book of swaps that have all the
>> cashflow
>>>>> dates lined up instead of a book with dozens of different reset dates.
>>>>>
>>>>> The other popular flavor is IMM effective but with standard rolls.
>>>>>
>>>>> -Mike
>>>>>
>>>>>
>>>>> On Fri, May 29, 2020 at 12:45 Tom Anderson <tw...@ur...>
>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> There are some dreadful interest rate swaps which use "IMM rolls" -
>> the
>>>>>> cashflows are on quarterly IMM dates, and the cashflow reflects an
>>>> accrual
>>>>>> over the period from that IMM date to the next one.
>>>>>>
>>>>>> (I think. I can't find a precise definition of how these swaps work.
>>>> They
>>>>>> just exist.)
>>>>>>
>>>>>> Does QuantLib support such swaps?
>>>>>>
>>>>>> I can generate a custom Schedule where cashflows are on IMM dates,
>> but i
>>>>>> don't know of a way to tweak the accrual periods for each cashflow.
>>>>>>
>>>>>> Thanks,
>>>>>> tom
>>>>>>
>>>>>> --
>>>>>> 12:28 <@ashak> why wouldn't you run it as root? Yuo don't get
>> permission
>>>>>> denied's on things then ;)
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> QuantLib-users mailing list
>>>>>> Qua...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>
>>>>>
>>>>
>>>> --
>>>> There are only two hard things in computer science: cache invalidation,
>>>> naming things, and off-by-one errors. -- anonymous
>>>
>>
>> --
>> Wikipedia topics: lists of trains, Mortal Kombat characters, one-time
>> villains from Mario games, road intersections, boring suburban schools,
>> garage bands, cats, webcomics, Digimon, Bionicle characters, webforums,
>> characters from English soap operas, and Mortal Kombat characters that
>> don't exist -- Uncyclopedia_______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

-- 
X is for ... EXECUTION!

Re: [Quantlib-users] IMM rolls

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

Thanks, Tom.  If you think it would be useful to add code to calculate a
default termination date for the IMM case, may you open an issue on GitHub
so someone may eventually pick it up?

Luigi


On Sun, Jun 7, 2020 at 10:25 PM Tom Anderson <tw...@ur...> wrote:

> (following up mostly for the sake of anyone reading the archives!)
>
> I'm starting with an effective date and a tenor ("computer, what is the
> rate for the two year out of IMM, IMM rolls?"), so i don't have a
> termination date to begin with. I am using MakeVanillaSwap, which requires
> a tenor and index, but makes everything else optional and tries to work it
> out. If you use MakeVanillaSwap with a two-year tenor, an IMM effective
> date, and a ThirdWednesday date generation rule, you get a standard
> termination date, rather than an IMM one. Hence, i need to work out the
> right termination date, and explicitly give it to MakeVanillaSwap.
>
> tom
>
> On Tue, 2 Jun 2020, Mike DelMedico wrote:
>
> > Glad it worked.  When I build the schedules, the dates seem to flow fine,
> > so not sure why your end date wouldn't line up with the proper final IMM
> > date.  See below:
> >
> > floatSchedule = ql.Schedule(effectiveDate,
> >                            maturityDate,
> >                            ql.Period(3, ql.Months),
> >                            calendarUSD_FedFund,
> >                            ql.ModifiedFollowing,
> >                            ql.ModifiedFollowing,
> >                            ql.DateGeneration.ThirdWednesday,
> >                            False)
> >
> > for i in floatSchedule:
> >    print(i)
> >
> > June 17th, 2020
> > September 16th, 2020
> > December 16th, 2020
> > March 17th, 2021
> > June 16th, 2021
> > September 15th, 2021
> > December 15th, 2021
> > March 16th, 2022
> > June 15th, 2022
> > September 21st, 2022
> > December 21st, 2022
> > March 15th, 2023
> > June 21st, 2023
> >
> >
> > On Tue, Jun 2, 2020 at 2:50 PM Tom Anderson <tw...@ur...>
> wrote:
> >
> >> That mostly does it, thanks!
> >>
> >> For some reason, i had assumed that the accrual periods for each coupon
> >> were based directly on the frequency or index tenor, rather than running
> >> to the next date. Too much time spent looking at futures bundles
> probably.
> >>
> >> It seems like i also need to tweak the end date. ThirdWednesday
> >> specifically doesn't do that.
> >>
> >> tom
> >>
> >> On Fri, 29 May 2020, Mike DelMedico wrote:
> >>
> >>> I’m pretty sure you just flip the generator from ‘Backward” to
> >>> “ThirdWednesday” and you should be good to go.
> >>>
> >>> These are very common use now given everyone’s desire to minimize line
> >>> items. Much easier to compress a book of swaps that have all the
> cashflow
> >>> dates lined up instead of a book with dozens of different reset dates.
> >>>
> >>> The other popular flavor is IMM effective but with standard rolls.
> >>>
> >>> -Mike
> >>>
> >>>
> >>> On Fri, May 29, 2020 at 12:45 Tom Anderson <tw...@ur...>
> wrote:
> >>>
> >>>> Hello,
> >>>>
> >>>> There are some dreadful interest rate swaps which use "IMM rolls" -
> the
> >>>> cashflows are on quarterly IMM dates, and the cashflow reflects an
> >> accrual
> >>>> over the period from that IMM date to the next one.
> >>>>
> >>>> (I think. I can't find a precise definition of how these swaps work.
> >> They
> >>>> just exist.)
> >>>>
> >>>> Does QuantLib support such swaps?
> >>>>
> >>>> I can generate a custom Schedule where cashflows are on IMM dates,
> but i
> >>>> don't know of a way to tweak the accrual periods for each cashflow.
> >>>>
> >>>> Thanks,
> >>>> tom
> >>>>
> >>>> --
> >>>> 12:28 <@ashak> why wouldn't you run it as root? Yuo don't get
> permission
> >>>> denied's on things then ;)
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> QuantLib-users mailing list
> >>>> Qua...@li...
> >>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >>>>
> >>>
> >>
> >> --
> >> There are only two hard things in computer science: cache invalidation,
> >> naming things, and off-by-one errors. -- anonymous
> >
>
> --
> Wikipedia topics: lists of trains, Mortal Kombat characters, one-time
> villains from Mario games, road intersections, boring suburban schools,
> garage bands, cats, webcomics, Digimon, Bionicle characters, webforums,
> characters from English soap operas, and Mortal Kombat characters that
> don't exist -- Uncyclopedia_______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] greeks with swaptionvolcube2

[Aleksis A. R. <ale...@go...>]

Hi Peter. That’s correct - the delta (and vega,gamma, etc) all smoothen out to normal when I zero out the skew in the volcube.

Btw, the jags are still present when using ’Naive’ mode in the GSR calibration.

Moreover, what’s more relevant is that they are also present even when just using a simple BachelierSwaptionEngine for the vanilla swaption case so I don’t think it’s model related.

FYI, I’m using normal vols throughout (with skew definition essentially a simple +5 normal vols for each 25bp otm - both for payers and recs)

In any case, to answer your question reg gsr calibration, I think I'm doing both (a) and (b) - essentially I’ve added a modified NPV attribute to the below-mentioned swaption class. So it’s a simple 'bump up,calc NPV,bump down, calc NPV, take difference’ using this NPV attribute. Maybe i’m missing one of the steps (a) or (b) in this code?

def NPV(self):
    engine = ql.Gaussian1dSwaptionEngine(self.model, 64, 7.0, True, False, self.discount_curve)
    basket = self.nsswaption.calibrationBasket(self.swapbase, self.swvolcube, 'MaturityStrikeByDeltaGamma')
    for basket_i in basket:
        ql.as_black_helper(basket_i).setPricingEngine(engine)
    method = ql.LevenbergMarquardt()
    ec = ql.EndCriteria(1000, 10, 1e-8, 1e-8, 1e-8)
    self.model.calibrateVolatilitiesIterative(basket, method, ec)
    npv = self.nsswaption.NPV()*self.position
    return npv



> On Jun 8, 2020, at 7:21 PM, Peter Caspers <pca...@gm...> wrote:
> 
> Hi Aleksis,
> 
> do you get the jags only when using a smile, i.e. does the delta get smoother when you use an ATM matrix only?
> 
> Another question I have is a) whether you recalibrate the GSR model after each bump and b) whether you recalculate the calibration basket after each bump as well?
> 
> Thanks
> Peter
> 
>> On 08 Jun 2020, at 17:31, Aleksis Ali Raza via QuantLib-users <qua...@li... <mailto:qua...@li...>> wrote:
>> 
>> Sure, essentially it’s run off this class:
>> 
>> class bermudanswaption():
>> 
>>     def __init__(self, calendar,settlement, used_model, swap, ratecurves, index, swvolcube_clean, swapbase,
>>                  mean_reversion,position):
>> 
>>         discount_curve = ratecurves.loc['discountcurve', 'ratecurves']
>>         self.swvolcube = swvolcube_clean
>>         self.swapbase = swapbase
>>         self.used_model = used_model
>>         self.discount_curve = discount_curve
>>         self.position=position
>> 
>>         fixed_schedule=swap.fixedSchedule()
>>         exerciseDates = [calendar.advance(i, -ql.Period('2D')) for i in fixed_schedule][1:-1]
>>         exercise = ql.BermudanExercise(exerciseDates)
>>         stepDates = exerciseDates
>>         self.exerciseDates=exerciseDates
>>         sigmas = [ql.QuoteHandle(ql.SimpleQuote(0.01))]*(1+len(exerciseDates))
>>         self.used_model = used_model
>> 
>>         if settlement == 'physical':
>>             type = 0
>>             method = 1
>>         else:
>>             type = 1
>>             method = 3
>> 
>>         self.nsswaption = ql.NonstandardSwaption(swap, exercise, type, method)
>>         gsr = ql.Gsr(ratecurves.loc[index, 'ratecurves'],
>>                      stepDates, sigmas, [ql.QuoteHandle(ql.SimpleQuote(mean_reversion))])
>>         engine = ql.Gaussian1dNonstandardSwaptionEngine(gsr, 64, 7.0, True, False,
>>                                                         ql.QuoteHandle(ql.SimpleQuote(0)),
>>                                                         discount_curve, 2)
>>         self.engine = ql.Gaussian1dSwaptionEngine(gsr, 64, 7.0, True, False, discount_curve)
>>         self.nsswaption.setPricingEngine(engine)
>>         self.model = gsr
>> 
>> 
>> 
>> 
>>> On 8 Jun 2020, at 15:50, Christofer Bogaso <bog...@gm... <mailto:bog...@gm...>> wrote:
>>> 
>>> Hi, could you please share your python code? Thanks,
>>> 
>>> On Mon, Jun 8, 2020 at 8:00 PM Aleksis Ali Raza via QuantLib-users <qua...@li... <mailto:qua...@li...>> wrote:
>>> Hi. In case anyone has an explanation: I get a jagged behaviour in a my greeks when I define a (what is to my knowledge sensible) swaption smile using swaptionvolcube2.
>>> 
>>> The greeks are being calculated by source bumping (using a 1bp shift for the rate delta, shown below along with the NPV). The behaviour isn’t too sensitive to the bump size.
>>> 
>>> Portfolio 1 consists of a 1y4y otm payer swaption and Portfolio 2 of a same strike 5y otm bermudan swaption with annual calls (both valued using the Hull-White GSR model calibrated to the swaption vol cube with MaturityStrikeByDeltaGamma mode). 
>>> 
>>> The code is in Python.
>>> 
>>> Thanks, Aleksis
>>>  
>>> 
>>> <optionanalysis_rate.png>
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li... <mailto:Qua...@li...>
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users <https://lists.sourceforge.net/lists/listinfo/quantlib-users>
>> 
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li... <mailto:Qua...@li...>
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
> 

Re: [Quantlib-users] greeks with swaptionvolcube2

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

Hi Aleksis,

do you get the jags only when using a smile, i.e. does the delta get smoother when you use an ATM matrix only?

Another question I have is a) whether you recalibrate the GSR model after each bump and b) whether you recalculate the calibration basket after each bump as well?

Thanks
Peter

> On 08 Jun 2020, at 17:31, Aleksis Ali Raza via QuantLib-users <qua...@li...> wrote:
> 
> Sure, essentially it’s run off this class:
> 
> class bermudanswaption():
> 
>     def __init__(self, calendar,settlement, used_model, swap, ratecurves, index, swvolcube_clean, swapbase,
>                  mean_reversion,position):
> 
>         discount_curve = ratecurves.loc['discountcurve', 'ratecurves']
>         self.swvolcube = swvolcube_clean
>         self.swapbase = swapbase
>         self.used_model = used_model
>         self.discount_curve = discount_curve
>         self.position=position
> 
>         fixed_schedule=swap.fixedSchedule()
>         exerciseDates = [calendar.advance(i, -ql.Period('2D')) for i in fixed_schedule][1:-1]
>         exercise = ql.BermudanExercise(exerciseDates)
>         stepDates = exerciseDates
>         self.exerciseDates=exerciseDates
>         sigmas = [ql.QuoteHandle(ql.SimpleQuote(0.01))]*(1+len(exerciseDates))
>         self.used_model = used_model
> 
>         if settlement == 'physical':
>             type = 0
>             method = 1
>         else:
>             type = 1
>             method = 3
> 
>         self.nsswaption = ql.NonstandardSwaption(swap, exercise, type, method)
>         gsr = ql.Gsr(ratecurves.loc[index, 'ratecurves'],
>                      stepDates, sigmas, [ql.QuoteHandle(ql.SimpleQuote(mean_reversion))])
>         engine = ql.Gaussian1dNonstandardSwaptionEngine(gsr, 64, 7.0, True, False,
>                                                         ql.QuoteHandle(ql.SimpleQuote(0)),
>                                                         discount_curve, 2)
>         self.engine = ql.Gaussian1dSwaptionEngine(gsr, 64, 7.0, True, False, discount_curve)
>         self.nsswaption.setPricingEngine(engine)
>         self.model = gsr
> 
> 
> 
> 
>> On 8 Jun 2020, at 15:50, Christofer Bogaso <bog...@gm... <mailto:bog...@gm...>> wrote:
>> 
>> Hi, could you please share your python code? Thanks,
>> 
>> On Mon, Jun 8, 2020 at 8:00 PM Aleksis Ali Raza via QuantLib-users <qua...@li... <mailto:qua...@li...>> wrote:
>> Hi. In case anyone has an explanation: I get a jagged behaviour in a my greeks when I define a (what is to my knowledge sensible) swaption smile using swaptionvolcube2.
>> 
>> The greeks are being calculated by source bumping (using a 1bp shift for the rate delta, shown below along with the NPV). The behaviour isn’t too sensitive to the bump size.
>> 
>> Portfolio 1 consists of a 1y4y otm payer swaption and Portfolio 2 of a same strike 5y otm bermudan swaption with annual calls (both valued using the Hull-White GSR model calibrated to the swaption vol cube with MaturityStrikeByDeltaGamma mode). 
>> 
>> The code is in Python.
>> 
>> Thanks, Aleksis
>>  
>> 
>> <optionanalysis_rate.png>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li... <mailto:Qua...@li...>
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users <https://lists.sourceforge.net/lists/listinfo/quantlib-users>
> 
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] greeks with swaptionvolcube2

[Aleksis A. R. <ale...@go...>]

Sure, essentially it’s run off this class:

class bermudanswaption():

    def __init__(self, calendar,settlement, used_model, swap, ratecurves, index, swvolcube_clean, swapbase,
                 mean_reversion,position):

        discount_curve = ratecurves.loc['discountcurve', 'ratecurves']
        self.swvolcube = swvolcube_clean
        self.swapbase = swapbase
        self.used_model = used_model
        self.discount_curve = discount_curve
        self.position=position

        fixed_schedule=swap.fixedSchedule()
        exerciseDates = [calendar.advance(i, -ql.Period('2D')) for i in fixed_schedule][1:-1]
        exercise = ql.BermudanExercise(exerciseDates)
        stepDates = exerciseDates
        self.exerciseDates=exerciseDates
        sigmas = [ql.QuoteHandle(ql.SimpleQuote(0.01))]*(1+len(exerciseDates))
        self.used_model = used_model

        if settlement == 'physical':
            type = 0
            method = 1
        else:
            type = 1
            method = 3

        self.nsswaption = ql.NonstandardSwaption(swap, exercise, type, method)
        gsr = ql.Gsr(ratecurves.loc[index, 'ratecurves'],
                     stepDates, sigmas, [ql.QuoteHandle(ql.SimpleQuote(mean_reversion))])
        engine = ql.Gaussian1dNonstandardSwaptionEngine(gsr, 64, 7.0, True, False,
                                                        ql.QuoteHandle(ql.SimpleQuote(0)),
                                                        discount_curve, 2)
        self.engine = ql.Gaussian1dSwaptionEngine(gsr, 64, 7.0, True, False, discount_curve)
        self.nsswaption.setPricingEngine(engine)
        self.model = gsr




> On 8 Jun 2020, at 15:50, Christofer Bogaso <bog...@gm...> wrote:
> 
> Hi, could you please share your python code? Thanks,
> 
> On Mon, Jun 8, 2020 at 8:00 PM Aleksis Ali Raza via QuantLib-users <qua...@li... <mailto:qua...@li...>> wrote:
> Hi. In case anyone has an explanation: I get a jagged behaviour in a my greeks when I define a (what is to my knowledge sensible) swaption smile using swaptionvolcube2.
> 
> The greeks are being calculated by source bumping (using a 1bp shift for the rate delta, shown below along with the NPV). The behaviour isn’t too sensitive to the bump size.
> 
> Portfolio 1 consists of a 1y4y otm payer swaption and Portfolio 2 of a same strike 5y otm bermudan swaption with annual calls (both valued using the Hull-White GSR model calibrated to the swaption vol cube with MaturityStrikeByDeltaGamma mode). 
> 
> The code is in Python.
> 
> Thanks, Aleksis
>  
> 
> <optionanalysis_rate.png>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li... <mailto:Qua...@li...>
> https://lists.sourceforge.net/lists/listinfo/quantlib-users <https://lists.sourceforge.net/lists/listinfo/quantlib-users>

[Quantlib-users] greeks with swaptionvolcube2

[Aleksis A. R. <ale...@go...>]

Hi. In case anyone has an explanation: I get a jagged behaviour in a my greeks when I define a (what is to my knowledge sensible) swaption smile using swaptionvolcube2.

The greeks are being calculated by source bumping (using a 1bp shift for the rate delta, shown below along with the NPV). The behaviour isn’t too sensitive to the bump size.

Portfolio 1 consists of a 1y4y otm payer swaption and Portfolio 2 of a same strike 5y otm bermudan swaption with annual calls (both valued using the Hull-White GSR model calibrated to the swaption vol cube with MaturityStrikeByDeltaGamma mode). 

The code is in Python.

Thanks, Aleksis
 

Re: [Quantlib-users] bond helpers pricing on curve

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

Yes and yes.

Luigi


On Mon, Jun 8, 2020 at 11:44 AM Philippe Hatstadt <
phi...@ex...> wrote:

> Thanks Luigi.
> Two quick follow up questions;
> 1. Does dirryPrice() work for an amortizing bond where I set the cash
> flows myself, albeit as QL.Bond()?
> 2. Does dirtyPrice() have the lazy NPV property?
>
> Regards
>
> Philippe Hatstadt
> +1-203-252-0408
> pha...@ma...
> https://www.linkedin.com/in/philippe-hatstadt
>
>
> On Jun 8, 2020, at 2:43 AM, Luigi Ballabio <lui...@gm...>
> wrote:
>
> 
> Hello,
>     that's correct.  With the evaluation date set to the value date, the
> bonds will take care of calculating the settlement date (you can check that
> by calling bond.settlementDate() without arguments once you set the date).
> To avoid confusion, I suggest you ignore the NPV() method and use
> dirtyPrice() instead, which always discounts to the settlement date.
>
> Luigi
>
>
> On Sun, Jun 7, 2020 at 9:41 PM Philippe Hatstadt <
> phi...@ex...> wrote:
>
>> Thanks Mike.
>> In my calculations, I was blipping the cleanPrice of a bond by its dv01,
>> but I was unsure whether I had to set the evaluationDate() to settle_date
>> to make sure the bond helpers understood my quote to be as of the
>> settlement date. it appears that this is not impacted by the
>> evaluationDate(), which is the correct design. So going forward, I see no
>> reason to set the evaluationDate() to anything other than the trade date to
>> get the correct numerical partial dv01s.
>> Thanks
>>
>> Regards
>>
>> Philippe
>>
>>
>> On Sun, Jun 7, 2020 at 2:28 PM Mike DelMedico <mik...@gm...>
>> wrote:
>>
>>> Reference date = date which has discount factor of 1.0
>>>
>>> So if you build a curve say with data from Tokyo open tonight, which is
>>> for trade date Monday June 8, then 6/8/20 should be your reference date.
>>> The settlement date of any instruments can and usually will be a different
>>>  date.
>>>
>>> I would assume that all the NPV calculations are discounting back to
>>> reference date.
>>>
>>> - Mike
>>>
>>> On Sun, Jun 7, 2020 at 11:33 Philippe Hatstadt <
>>> phi...@ex...> wrote:
>>>
>>>> Luigi,
>>>> what do you mean by "reference date" of the curve?
>>>> The odd behavior I am observing is that if I build a curve with 2y, 3y,
>>>> 5y, 7y, 10y and 30y US treasuries, and then I manually blip the 2y point to
>>>> compute a key rate dv01, I would expect that only the 2y price is impacted.
>>>> This is by setting  as follows: ql.Settings.instance().evaluationDate =
>>>> settle_date. To be 100% clear, I am repricing the bonds used to build
>>>> the curve on the curve itself via a PricingEngine, not using bond math.
>>>> However, the behavior I observe is that all maturities are slightly
>>>> impacted by blipping the 2y price used to build the curve, whereas for
>>>> instance, the 5y is not impacted by blipping the 3y, and the 10y is not
>>>> impacted by clipping the 3y or the 5y. Furthermore, I set the yield on the
>>>> 2y to zero, in which case the impact was zero.
>>>> So my conclusion is that although I set the evaluationDate to settle
>>>> date, the NPV() method discounts to trade_date, and since the first
>>>> instrument I use to build my curve is the 2y, then the discount factor from
>>>> trade date to settle date is only impacted by the 2y yield.
>>>> Lastly, if I do  ql.Settings.instance().evaluationDate  = trade_date,
>>>> then everything works as expected. However, this is exactly the behavior I
>>>> would not expect, as I would only expect the 2y sensitivity to impact
>>>> valuation Date based on settle_date, in which case all discounting from
>>>> tared date to settle date is irrelevant.
>>>> So I am utterly confused by how to use evaluationDate to discount
>>>> properly to either trade or settle date with the NPV() method.
>>>> Data is below, i highlighted in yellow the "anomaly", which would be
>>>> expected if evaluationDate was set to trade date and not settle date.
>>>>
>>>> evaluationDate = settle date
>>>>   2y 3y 5y 7y 10y 30y
>>>> 2y -192.38 -0.27 -0.28 -0.28 -0.27 -0.27
>>>> 3y 0.00 -295.21 0.00 0.00 0.00 0.00
>>>> 5y 0.00 0.00 -488.57 0.00 0.00 0.00
>>>> 7y 0.00 0.00 0.00 -679.34 0.00 0.00
>>>> 10y 0.00 0.00 0.00 0.00 -960.92 0.00
>>>> 30y 0.00 0.00 0.00 0.00 0.00 -2,404.86
>>>>
>>>> evaluationDate = trade date
>>>>   2y 3y 5y 7y 10y 30y
>>>> 2y -191.12 0.00 0.00 0.00 0.00 0.00
>>>> 3y 1.26 -295.48 0.00 0.00 0.00 0.00
>>>> 5y 1.26 0.00 -488.85 0.00 0.00 0.00
>>>> 7y 1.26 0.00 0.00 -679.61 0.00 0.00
>>>> 10y 1.26 0.00 0.00 0.00 -961.17 0.00
>>>> 30y 1.26 0.00 0.00 0.00 0.00 -2,405.04
>>>>
>>>>
>>>> Philippe
>>>>
>>>>
>>>> On Fri, May 29, 2020 at 3:31 PM Luigi Ballabio <
>>>> lui...@gm...> wrote:
>>>>
>>>>> Philippe,
>>>>>     bond.NPV() discounts to the reference date of the discount curve.
>>>>> bond.dirtyPrice() discounts to the settlement, and thus it does hold that
>>>>> dirtyPrice() - accruedInterest() equals cleanPrice().  As you say, the same
>>>>> doesn't hold for NPV.
>>>>>
>>>>> Hope this helps,
>>>>>     Luigi
>>>>>
>>>>>
>>>>> On Fri, May 29, 2020 at 9:26 PM Philippe Hatstadt <
>>>>> phi...@ex...> wrote:
>>>>>
>>>>>> Peter & others,
>>>>>> Is it 100% a fact that NPV() discounts to today and not to settle
>>>>>> date? because I was trying to reconcile NPV() - accruedInterest() versus
>>>>>> cleanPrice() but that should not work if they don't have the same
>>>>>> settlement date
>>>>>>
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Philippe
>>>>>>
>>>>>>
>>>>>> On Fri, May 29, 2020 at 8:49 AM Peter Caspers <pca...@gm...>
>>>>>> wrote:
>>>>>>
>>>>>>> I believe helper.bond().cleanPrice() returns the (clean) price on
>>>>>>> the curve, but as of the bond’s settlement date, typically this is today +
>>>>>>> 2bd. NPV() returns the (dirty) price as of today on the other hand. Could
>>>>>>> that explain the difference you see?
>>>>>>> BR, Peter
>>>>>>>
>>>>>>> On 29 May 2020, at 03:34, Philippe Hatstadt <
>>>>>>> phi...@ex...> wrote:
>>>>>>>
>>>>>>> One unanswered question is whether helper.bond().cleanPrice() is
>>>>>>> supposed to return the clean price of the helper priced on the curve, or
>>>>>>> just the cleanPrice parameter that was used to build the helper?
>>>>>>> Given that it matches to 6 digits of precision the input quote
>>>>>>> clesan price, I assume it is not based on valuation on the curve,
>>>>>>> which should be equal to NPV(0 - accruedInterest but I would be keen to
>>>>>>> know.
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Philippe
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 28, 2020 at 5:06 PM Mike DelMedico <
>>>>>>> mik...@gm...> wrote:
>>>>>>>
>>>>>>>> Without looking at your code I would guess is a convention thing
>>>>>>>> when you pass instrument specs to the ratehelper. Day counter, calendar,
>>>>>>>> and coupon frequency come to mind?  Maybe try gathering the cash flows off
>>>>>>>> the bond object and see if they match what you expect?
>>>>>>>>
>>>>>>>> -Mike
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, May 28, 2020 at 15:34 Philippe Hatstadt <
>>>>>>>> phi...@ex...> wrote:
>>>>>>>>
>>>>>>>>> I am building a US treasury curve from on the run 2/3/5/7/10/30y
>>>>>>>>> US bonds, via tradition bond helper list and so on. How can I tell the
>>>>>>>>> quality of the fit of the curve? Since it's a straight bootstrapping with
>>>>>>>>> PiecewiseFlatForward, I would expect the repricing to be exact.
>>>>>>>>> In order to do that, I am doing first helper.bond().NPV(),
>>>>>>>>> which for the 30y bond gives me a price of 97.0322, whereas if I do
>>>>>>>>> helper.bond().cleanPrice(), I get 97.015625.
>>>>>>>>> Here is the issue: the latter price is *exactly* the input price
>>>>>>>>> that I entered, however, the difference between NPV() and cleanPrice() is
>>>>>>>>> not equal to the correct accrued interest of 0.03767 but equal to 0.01669.
>>>>>>>>> So either (a) helper.bond().cleanPrice() only returns the quote
>>>>>>>>> that was entered, but not the clean price of the bond calculated on the
>>>>>>>>> curve, or (b) the curve construction does not reprice the helper bond
>>>>>>>>> exactly, thence the incorrect value of 0.01699 above.
>>>>>>>>> So I am looking for some guidance on how to evaluate
>>>>>>>>> the exactitude of the curve building?
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> Philippe
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Brokerage services offered through Exos Securities LLC, member of
>>>>>>>>> SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For
>>>>>>>>> important disclosures, click here
>>>>>>>>> <https://www.exosfinancial.com/disclosures>.
>>>>>>>>> _______________________________________________
>>>>>>>>> QuantLib-users mailing list
>>>>>>>>> Qua...@li...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Brokerage services offered through Exos Securities LLC, member of
>>>>>>> SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For
>>>>>>> important disclosures, click here
>>>>>>> <https://www.exosfinancial.com/disclosures>.
>>>>>>> _______________________________________________
>>>>>>> QuantLib-users mailing list
>>>>>>> Qua...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Brokerage services offered through Exos Securities LLC, member of
>>>>>> SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For
>>>>>> important disclosures, click here
>>>>>> <https://www.exosfinancial.com/disclosures>.
>>>>>> _______________________________________________
>>>>>> QuantLib-users mailing list
>>>>>> Qua...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>
>>>>>
>>>>
>>>>
>>>> Brokerage services offered through Exos Securities LLC, member of SIPC
>>>> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
>>>> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>
>>>
>>
>>
>> Brokerage services offered through Exos Securities LLC, member of SIPC
>> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
>> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>>
>
>
>
> Brokerage services offered through Exos Securities LLC, member of SIPC
> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>

Re: [Quantlib-users] bond helpers pricing on curve

[Philippe H. <phi...@ex...>]

Thanks Luigi. 
Two quick follow up questions;
1. Does dirryPrice() work for an amortizing bond where I set the cash flows myself, albeit as QL.Bond()?
2. Does dirtyPrice() have the lazy NPV property?

Regards

Philippe Hatstadt
+1-203-252-0408
pha...@ma...
https://www.linkedin.com/in/philippe-hatstadt


> On Jun 8, 2020, at 2:43 AM, Luigi Ballabio <lui...@gm...> wrote:
> 
> 
> Hello,
>     that's correct.  With the evaluation date set to the value date, the bonds will take care of calculating the settlement date (you can check that by calling bond.settlementDate() without arguments once you set the date).  To avoid confusion, I suggest you ignore the NPV() method and use dirtyPrice() instead, which always discounts to the settlement date.
> 
> Luigi
> 
> 
>> On Sun, Jun 7, 2020 at 9:41 PM Philippe Hatstadt <phi...@ex...> wrote:
>> Thanks Mike. 
>> In my calculations, I was blipping the cleanPrice of a bond by its dv01, but I was unsure whether I had to set the evaluationDate() to settle_date to make sure the bond helpers understood my quote to be as of the settlement date. it appears that this is not impacted by the evaluationDate(), which is the correct design. So going forward, I see no reason to set the evaluationDate() to anything other than the trade date to get the correct numerical partial dv01s.
>> Thanks 
>> 
>> Regards
>> 
>> Philippe
>> 
>> 
>>> On Sun, Jun 7, 2020 at 2:28 PM Mike DelMedico <mik...@gm...> wrote:
>>> Reference date = date which has discount factor of 1.0
>>> 
>>> So if you build a curve say with data from Tokyo open tonight, which is for trade date Monday June 8, then 6/8/20 should be your reference date. The settlement date of any instruments can and usually will be a different  date.
>>> 
>>> I would assume that all the NPV calculations are discounting back to reference date. 
>>> 
>>> - Mike
>>> 
>>>> On Sun, Jun 7, 2020 at 11:33 Philippe Hatstadt <phi...@ex...> wrote:
>>>> Luigi,
>>>> what do you mean by "reference date" of the curve?
>>>> The odd behavior I am observing is that if I build a curve with 2y, 3y, 5y, 7y, 10y and 30y US treasuries, and then I manually blip the 2y point to compute a key rate dv01, I would expect that only the 2y price is impacted. This is by setting  as follows: ql.Settings.instance().evaluationDate = settle_date. To be 100% clear, I am repricing the bonds used to build the curve on the curve itself via a PricingEngine, not using bond math.
>>>> However, the behavior I observe is that all maturities are slightly impacted by blipping the 2y price used to build the curve, whereas for instance, the 5y is not impacted by blipping the 3y, and the 10y is not impacted by clipping the 3y or the 5y. Furthermore, I set the yield on the 2y to zero, in which case the impact was zero. 
>>>> So my conclusion is that although I set the evaluationDate to settle date, the NPV() method discounts to trade_date, and since the first instrument I use to build my curve is the 2y, then the discount factor from trade date to settle date is only impacted by the 2y yield.
>>>> Lastly, if I do  ql.Settings.instance().evaluationDate  = trade_date, then everything works as expected. However, this is exactly the behavior I would not expect, as I would only expect the 2y sensitivity to impact valuation Date based on settle_date, in which case all discounting from tared date to settle date is irrelevant.
>>>> So I am utterly confused by how to use evaluationDate to discount properly to either trade or settle date with the NPV() method.
>>>> Data is below, i highlighted in yellow the "anomaly", which would be expected if evaluationDate was set to trade date and not settle date.
>>>> 
>>>> evaluationDate = settle date	 	 	 	 
>>>>  	2y	3y	5y	7y	10y	30y
>>>> 2y	-192.38	-0.27	-0.28	-0.28	-0.27	-0.27
>>>> 3y	0.00	-295.21	0.00	0.00	0.00	0.00
>>>> 5y	0.00	0.00	-488.57	0.00	0.00	0.00
>>>> 7y	0.00	0.00	0.00	-679.34	0.00	0.00
>>>> 10y	0.00	0.00	0.00	0.00	-960.92	0.00
>>>> 30y	0.00	0.00	0.00	0.00	0.00	-2,404.86
>>>>  	 	 	 	 	 	 
>>>> evaluationDate = trade date	 	 	 	 
>>>>  	2y	3y	5y	7y	10y	30y
>>>> 2y	-191.12	0.00	0.00	0.00	0.00	0.00
>>>> 3y	1.26	-295.48	0.00	0.00	0.00	0.00
>>>> 5y	1.26	0.00	-488.85	0.00	0.00	0.00
>>>> 7y	1.26	0.00	0.00	-679.61	0.00	0.00
>>>> 10y	1.26	0.00	0.00	0.00	-961.17	0.00
>>>> 30y	1.26	0.00	0.00	0.00	0.00	-2,405.04
>>>> 
>>>> 
>>>> Philippe
>>>> 
>>>> 
>>>>> On Fri, May 29, 2020 at 3:31 PM Luigi Ballabio <lui...@gm...> wrote:
>>>>> Philippe,
>>>>>     bond.NPV() discounts to the reference date of the discount curve.  bond.dirtyPrice() discounts to the settlement, and thus it does hold that dirtyPrice() - accruedInterest() equals cleanPrice().  As you say, the same doesn't hold for NPV.
>>>>> 
>>>>> Hope this helps,
>>>>>     Luigi
>>>>> 
>>>>> 
>>>>>> On Fri, May 29, 2020 at 9:26 PM Philippe Hatstadt <phi...@ex...> wrote:
>>>>>> Peter & others,
>>>>>> Is it 100% a fact that NPV() discounts to today and not to settle date? because I was trying to reconcile NPV() - accruedInterest() versus cleanPrice() but that should not work if they don't have the same settlement date
>>>>>> 
>>>>>> 
>>>>>> Regards
>>>>>> 
>>>>>> Philippe
>>>>>> 
>>>>>> 
>>>>>>> On Fri, May 29, 2020 at 8:49 AM Peter Caspers <pca...@gm...> wrote:
>>>>>>> I believe helper.bond().cleanPrice() returns the (clean) price on the curve, but as of the bond’s settlement date, typically this is today + 2bd. NPV() returns the (dirty) price as of today on the other hand. Could that explain the difference you see?
>>>>>>> BR, Peter
>>>>>>> 
>>>>>>>> On 29 May 2020, at 03:34, Philippe Hatstadt <phi...@ex...> wrote:
>>>>>>>> 
>>>>>>>> One unanswered question is whether helper.bond().cleanPrice() is supposed to return the clean price of the helper priced on the curve, or just the cleanPrice parameter that was used to build the helper?
>>>>>>>> Given that it matches to 6 digits of precision the input quote clesan price, I assume it is not based on valuation on the curve, which should be equal to NPV(0 - accruedInterest but I would be keen to know.
>>>>>>>> 
>>>>>>>> Regards
>>>>>>>> 
>>>>>>>> Philippe
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> On Thu, May 28, 2020 at 5:06 PM Mike DelMedico <mik...@gm...> wrote:
>>>>>>>>> Without looking at your code I would guess is a convention thing when you pass instrument specs to the ratehelper. Day counter, calendar, and coupon frequency come to mind?  Maybe try gathering the cash flows off the bond object and see if they match what you expect?
>>>>>>>>> 
>>>>>>>>> -Mike
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> On Thu, May 28, 2020 at 15:34 Philippe Hatstadt <phi...@ex...> wrote:
>>>>>>>>>> I am building a US treasury curve from on the run 2/3/5/7/10/30y US bonds, via tradition bond helper list and so on. How can I tell the quality of the fit of the curve? Since it's a straight bootstrapping with PiecewiseFlatForward, I would expect the repricing to be exact.
>>>>>>>>>> In order to do that, I am doing first helper.bond().NPV(), which for the 30y bond gives me a price of 97.0322, whereas if I do helper.bond().cleanPrice(), I get 97.015625. 
>>>>>>>>>> Here is the issue: the latter price is *exactly* the input price that I entered, however, the difference between NPV() and cleanPrice() is not equal to the correct accrued interest of 0.03767 but equal to 0.01669.
>>>>>>>>>> So either (a) helper.bond().cleanPrice() only returns the quote that was entered, but not the clean price of the bond calculated on the curve, or (b) the curve construction does not reprice the helper bond exactly, thence the incorrect value of 0.01699 above.
>>>>>>>>>> So I am looking for some guidance on how to evaluate the exactitude of the curve building?
>>>>>>>>>> 
>>>>>>>>>> Regards
>>>>>>>>>> 
>>>>>>>>>> Philippe
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> Brokerage services offered through Exos Securities LLC, member of SIPC / FINRA.  For important disclosures, click here. 
>>>>>>>>>> _______________________________________________
>>>>>>>>>> QuantLib-users mailing list
>>>>>>>>>> Qua...@li...
>>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>> Brokerage services offered through Exos Securities LLC, member of SIPC / FINRA.  For important disclosures, click here. 
>>>>>>>> _______________________________________________
>>>>>>>> QuantLib-users mailing list
>>>>>>>> Qua...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> Brokerage services offered through Exos Securities LLC, member of SIPC / FINRA.  For important disclosures, click here. 
>>>>>> _______________________________________________
>>>>>> QuantLib-users mailing list
>>>>>> Qua...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>> 
>>>> 
>>>> 
>>>> Brokerage services offered through Exos Securities LLC, member of SIPC / FINRA.  For important disclosures, click here. 
>>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>> 
>> 
>> 
>> Brokerage services offered through Exos Securities LLC, member of SIPC / FINRA.  For important disclosures, click here. 

-- 








Brokerage services offered through Exos Securities LLC, member of 
SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>.  For important 
disclosures, click here <https://www.exosfinancial.com/disclosures>. 

Re: [Quantlib-users] bond helpers pricing on curve

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

Hello,
    that's correct.  With the evaluation date set to the value date, the
bonds will take care of calculating the settlement date (you can check that
by calling bond.settlementDate() without arguments once you set the date).
To avoid confusion, I suggest you ignore the NPV() method and use
dirtyPrice() instead, which always discounts to the settlement date.

Luigi


On Sun, Jun 7, 2020 at 9:41 PM Philippe Hatstadt <
phi...@ex...> wrote:

> Thanks Mike.
> In my calculations, I was blipping the cleanPrice of a bond by its dv01,
> but I was unsure whether I had to set the evaluationDate() to settle_date
> to make sure the bond helpers understood my quote to be as of the
> settlement date. it appears that this is not impacted by the
> evaluationDate(), which is the correct design. So going forward, I see no
> reason to set the evaluationDate() to anything other than the trade date to
> get the correct numerical partial dv01s.
> Thanks
>
> Regards
>
> Philippe
>
>
> On Sun, Jun 7, 2020 at 2:28 PM Mike DelMedico <mik...@gm...>
> wrote:
>
>> Reference date = date which has discount factor of 1.0
>>
>> So if you build a curve say with data from Tokyo open tonight, which is
>> for trade date Monday June 8, then 6/8/20 should be your reference date.
>> The settlement date of any instruments can and usually will be a different
>>  date.
>>
>> I would assume that all the NPV calculations are discounting back to
>> reference date.
>>
>> - Mike
>>
>> On Sun, Jun 7, 2020 at 11:33 Philippe Hatstadt <
>> phi...@ex...> wrote:
>>
>>> Luigi,
>>> what do you mean by "reference date" of the curve?
>>> The odd behavior I am observing is that if I build a curve with 2y, 3y,
>>> 5y, 7y, 10y and 30y US treasuries, and then I manually blip the 2y point to
>>> compute a key rate dv01, I would expect that only the 2y price is impacted.
>>> This is by setting  as follows: ql.Settings.instance().evaluationDate =
>>> settle_date. To be 100% clear, I am repricing the bonds used to build
>>> the curve on the curve itself via a PricingEngine, not using bond math.
>>> However, the behavior I observe is that all maturities are slightly
>>> impacted by blipping the 2y price used to build the curve, whereas for
>>> instance, the 5y is not impacted by blipping the 3y, and the 10y is not
>>> impacted by clipping the 3y or the 5y. Furthermore, I set the yield on the
>>> 2y to zero, in which case the impact was zero.
>>> So my conclusion is that although I set the evaluationDate to settle
>>> date, the NPV() method discounts to trade_date, and since the first
>>> instrument I use to build my curve is the 2y, then the discount factor from
>>> trade date to settle date is only impacted by the 2y yield.
>>> Lastly, if I do  ql.Settings.instance().evaluationDate  = trade_date,
>>> then everything works as expected. However, this is exactly the behavior I
>>> would not expect, as I would only expect the 2y sensitivity to impact
>>> valuation Date based on settle_date, in which case all discounting from
>>> tared date to settle date is irrelevant.
>>> So I am utterly confused by how to use evaluationDate to discount
>>> properly to either trade or settle date with the NPV() method.
>>> Data is below, i highlighted in yellow the "anomaly", which would be
>>> expected if evaluationDate was set to trade date and not settle date.
>>>
>>> evaluationDate = settle date
>>>   2y 3y 5y 7y 10y 30y
>>> 2y -192.38 -0.27 -0.28 -0.28 -0.27 -0.27
>>> 3y 0.00 -295.21 0.00 0.00 0.00 0.00
>>> 5y 0.00 0.00 -488.57 0.00 0.00 0.00
>>> 7y 0.00 0.00 0.00 -679.34 0.00 0.00
>>> 10y 0.00 0.00 0.00 0.00 -960.92 0.00
>>> 30y 0.00 0.00 0.00 0.00 0.00 -2,404.86
>>>
>>> evaluationDate = trade date
>>>   2y 3y 5y 7y 10y 30y
>>> 2y -191.12 0.00 0.00 0.00 0.00 0.00
>>> 3y 1.26 -295.48 0.00 0.00 0.00 0.00
>>> 5y 1.26 0.00 -488.85 0.00 0.00 0.00
>>> 7y 1.26 0.00 0.00 -679.61 0.00 0.00
>>> 10y 1.26 0.00 0.00 0.00 -961.17 0.00
>>> 30y 1.26 0.00 0.00 0.00 0.00 -2,405.04
>>>
>>>
>>> Philippe
>>>
>>>
>>> On Fri, May 29, 2020 at 3:31 PM Luigi Ballabio <lui...@gm...>
>>> wrote:
>>>
>>>> Philippe,
>>>>     bond.NPV() discounts to the reference date of the discount curve.
>>>> bond.dirtyPrice() discounts to the settlement, and thus it does hold that
>>>> dirtyPrice() - accruedInterest() equals cleanPrice().  As you say, the same
>>>> doesn't hold for NPV.
>>>>
>>>> Hope this helps,
>>>>     Luigi
>>>>
>>>>
>>>> On Fri, May 29, 2020 at 9:26 PM Philippe Hatstadt <
>>>> phi...@ex...> wrote:
>>>>
>>>>> Peter & others,
>>>>> Is it 100% a fact that NPV() discounts to today and not to settle
>>>>> date? because I was trying to reconcile NPV() - accruedInterest() versus
>>>>> cleanPrice() but that should not work if they don't have the same
>>>>> settlement date
>>>>>
>>>>>
>>>>> Regards
>>>>>
>>>>> Philippe
>>>>>
>>>>>
>>>>> On Fri, May 29, 2020 at 8:49 AM Peter Caspers <pca...@gm...>
>>>>> wrote:
>>>>>
>>>>>> I believe helper.bond().cleanPrice() returns the (clean) price on the
>>>>>> curve, but as of the bond’s settlement date, typically this is today + 2bd.
>>>>>> NPV() returns the (dirty) price as of today on the other hand. Could that
>>>>>> explain the difference you see?
>>>>>> BR, Peter
>>>>>>
>>>>>> On 29 May 2020, at 03:34, Philippe Hatstadt <
>>>>>> phi...@ex...> wrote:
>>>>>>
>>>>>> One unanswered question is whether helper.bond().cleanPrice() is
>>>>>> supposed to return the clean price of the helper priced on the curve, or
>>>>>> just the cleanPrice parameter that was used to build the helper?
>>>>>> Given that it matches to 6 digits of precision the input quote
>>>>>> clesan price, I assume it is not based on valuation on the curve,
>>>>>> which should be equal to NPV(0 - accruedInterest but I would be keen to
>>>>>> know.
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Philippe
>>>>>>
>>>>>>
>>>>>> On Thu, May 28, 2020 at 5:06 PM Mike DelMedico <
>>>>>> mik...@gm...> wrote:
>>>>>>
>>>>>>> Without looking at your code I would guess is a convention thing
>>>>>>> when you pass instrument specs to the ratehelper. Day counter, calendar,
>>>>>>> and coupon frequency come to mind?  Maybe try gathering the cash flows off
>>>>>>> the bond object and see if they match what you expect?
>>>>>>>
>>>>>>> -Mike
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, May 28, 2020 at 15:34 Philippe Hatstadt <
>>>>>>> phi...@ex...> wrote:
>>>>>>>
>>>>>>>> I am building a US treasury curve from on the run 2/3/5/7/10/30y US
>>>>>>>> bonds, via tradition bond helper list and so on. How can I tell the quality
>>>>>>>> of the fit of the curve? Since it's a straight bootstrapping with
>>>>>>>> PiecewiseFlatForward, I would expect the repricing to be exact.
>>>>>>>> In order to do that, I am doing first helper.bond().NPV(),
>>>>>>>> which for the 30y bond gives me a price of 97.0322, whereas if I do
>>>>>>>> helper.bond().cleanPrice(), I get 97.015625.
>>>>>>>> Here is the issue: the latter price is *exactly* the input price
>>>>>>>> that I entered, however, the difference between NPV() and cleanPrice() is
>>>>>>>> not equal to the correct accrued interest of 0.03767 but equal to 0.01669.
>>>>>>>> So either (a) helper.bond().cleanPrice() only returns the quote
>>>>>>>> that was entered, but not the clean price of the bond calculated on the
>>>>>>>> curve, or (b) the curve construction does not reprice the helper bond
>>>>>>>> exactly, thence the incorrect value of 0.01699 above.
>>>>>>>> So I am looking for some guidance on how to evaluate the exactitude
>>>>>>>> of the curve building?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> Philippe
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Brokerage services offered through Exos Securities LLC, member of
>>>>>>>> SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For
>>>>>>>> important disclosures, click here
>>>>>>>> <https://www.exosfinancial.com/disclosures>.
>>>>>>>> _______________________________________________
>>>>>>>> QuantLib-users mailing list
>>>>>>>> Qua...@li...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>> Brokerage services offered through Exos Securities LLC, member of
>>>>>> SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For
>>>>>> important disclosures, click here
>>>>>> <https://www.exosfinancial.com/disclosures>.
>>>>>> _______________________________________________
>>>>>> QuantLib-users mailing list
>>>>>> Qua...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> Brokerage services offered through Exos Securities LLC, member of SIPC
>>>>> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
>>>>> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>>>>> _______________________________________________
>>>>> QuantLib-users mailing list
>>>>> Qua...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>
>>>>
>>>
>>>
>>> Brokerage services offered through Exos Securities LLC, member of SIPC
>>> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
>>> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>
>
>
> Brokerage services offered through Exos Securities LLC, member of SIPC
> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>

Re: [Quantlib-users] IMM rolls

[Tom A. <tw...@ur...>]

(following up mostly for the sake of anyone reading the archives!)

I'm starting with an effective date and a tenor ("computer, what is the 
rate for the two year out of IMM, IMM rolls?"), so i don't have a 
termination date to begin with. I am using MakeVanillaSwap, which requires 
a tenor and index, but makes everything else optional and tries to work it 
out. If you use MakeVanillaSwap with a two-year tenor, an IMM effective 
date, and a ThirdWednesday date generation rule, you get a standard 
termination date, rather than an IMM one. Hence, i need to work out the 
right termination date, and explicitly give it to MakeVanillaSwap.

tom

On Tue, 2 Jun 2020, Mike DelMedico wrote:

> Glad it worked.  When I build the schedules, the dates seem to flow fine,
> so not sure why your end date wouldn't line up with the proper final IMM
> date.  See below:
>
> floatSchedule = ql.Schedule(effectiveDate,
>                            maturityDate,
>                            ql.Period(3, ql.Months),
>                            calendarUSD_FedFund,
>                            ql.ModifiedFollowing,
>                            ql.ModifiedFollowing,
>                            ql.DateGeneration.ThirdWednesday,
>                            False)
>
> for i in floatSchedule:
>    print(i)
>
> June 17th, 2020
> September 16th, 2020
> December 16th, 2020
> March 17th, 2021
> June 16th, 2021
> September 15th, 2021
> December 15th, 2021
> March 16th, 2022
> June 15th, 2022
> September 21st, 2022
> December 21st, 2022
> March 15th, 2023
> June 21st, 2023
>
>
> On Tue, Jun 2, 2020 at 2:50 PM Tom Anderson <tw...@ur...> wrote:
>
>> That mostly does it, thanks!
>>
>> For some reason, i had assumed that the accrual periods for each coupon
>> were based directly on the frequency or index tenor, rather than running
>> to the next date. Too much time spent looking at futures bundles probably.
>>
>> It seems like i also need to tweak the end date. ThirdWednesday
>> specifically doesn't do that.
>>
>> tom
>>
>> On Fri, 29 May 2020, Mike DelMedico wrote:
>>
>>> I’m pretty sure you just flip the generator from ‘Backward” to
>>> “ThirdWednesday” and you should be good to go.
>>>
>>> These are very common use now given everyone’s desire to minimize line
>>> items. Much easier to compress a book of swaps that have all the cashflow
>>> dates lined up instead of a book with dozens of different reset dates.
>>>
>>> The other popular flavor is IMM effective but with standard rolls.
>>>
>>> -Mike
>>>
>>>
>>> On Fri, May 29, 2020 at 12:45 Tom Anderson <tw...@ur...> wrote:
>>>
>>>> Hello,
>>>>
>>>> There are some dreadful interest rate swaps which use "IMM rolls" - the
>>>> cashflows are on quarterly IMM dates, and the cashflow reflects an
>> accrual
>>>> over the period from that IMM date to the next one.
>>>>
>>>> (I think. I can't find a precise definition of how these swaps work.
>> They
>>>> just exist.)
>>>>
>>>> Does QuantLib support such swaps?
>>>>
>>>> I can generate a custom Schedule where cashflows are on IMM dates, but i
>>>> don't know of a way to tweak the accrual periods for each cashflow.
>>>>
>>>> Thanks,
>>>> tom
>>>>
>>>> --
>>>> 12:28 <@ashak> why wouldn't you run it as root? Yuo don't get permission
>>>> denied's on things then ;)
>>>>
>>>>
>>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>
>>>
>>
>> --
>> There are only two hard things in computer science: cache invalidation,
>> naming things, and off-by-one errors. -- anonymous
>

-- 
Wikipedia topics: lists of trains, Mortal Kombat characters, one-time
villains from Mario games, road intersections, boring suburban schools,
garage bands, cats, webcomics, Digimon, Bionicle characters, webforums,
characters from English soap operas, and Mortal Kombat characters that
don't exist -- Uncyclopedia

Re: [Quantlib-users] bond helpers pricing on curve

[Philippe H. <phi...@ex...>]

Thanks Mike.
In my calculations, I was blipping the cleanPrice of a bond by its dv01,
but I was unsure whether I had to set the evaluationDate() to settle_date
to make sure the bond helpers understood my quote to be as of the
settlement date. it appears that this is not impacted by the
evaluationDate(), which is the correct design. So going forward, I see no
reason to set the evaluationDate() to anything other than the trade date to
get the correct numerical partial dv01s.
Thanks

Regards

Philippe


On Sun, Jun 7, 2020 at 2:28 PM Mike DelMedico <mik...@gm...>
wrote:

> Reference date = date which has discount factor of 1.0
>
> So if you build a curve say with data from Tokyo open tonight, which is
> for trade date Monday June 8, then 6/8/20 should be your reference date.
> The settlement date of any instruments can and usually will be a different
>  date.
>
> I would assume that all the NPV calculations are discounting back to
> reference date.
>
> - Mike
>
> On Sun, Jun 7, 2020 at 11:33 Philippe Hatstadt <
> phi...@ex...> wrote:
>
>> Luigi,
>> what do you mean by "reference date" of the curve?
>> The odd behavior I am observing is that if I build a curve with 2y, 3y,
>> 5y, 7y, 10y and 30y US treasuries, and then I manually blip the 2y point to
>> compute a key rate dv01, I would expect that only the 2y price is impacted.
>> This is by setting  as follows: ql.Settings.instance().evaluationDate =
>> settle_date. To be 100% clear, I am repricing the bonds used to build
>> the curve on the curve itself via a PricingEngine, not using bond math.
>> However, the behavior I observe is that all maturities are slightly
>> impacted by blipping the 2y price used to build the curve, whereas for
>> instance, the 5y is not impacted by blipping the 3y, and the 10y is not
>> impacted by clipping the 3y or the 5y. Furthermore, I set the yield on the
>> 2y to zero, in which case the impact was zero.
>> So my conclusion is that although I set the evaluationDate to settle
>> date, the NPV() method discounts to trade_date, and since the first
>> instrument I use to build my curve is the 2y, then the discount factor from
>> trade date to settle date is only impacted by the 2y yield.
>> Lastly, if I do  ql.Settings.instance().evaluationDate  = trade_date,
>> then everything works as expected. However, this is exactly the behavior I
>> would not expect, as I would only expect the 2y sensitivity to impact
>> valuation Date based on settle_date, in which case all discounting from
>> tared date to settle date is irrelevant.
>> So I am utterly confused by how to use evaluationDate to discount
>> properly to either trade or settle date with the NPV() method.
>> Data is below, i highlighted in yellow the "anomaly", which would be
>> expected if evaluationDate was set to trade date and not settle date.
>>
>> evaluationDate = settle date
>>   2y 3y 5y 7y 10y 30y
>> 2y -192.38 -0.27 -0.28 -0.28 -0.27 -0.27
>> 3y 0.00 -295.21 0.00 0.00 0.00 0.00
>> 5y 0.00 0.00 -488.57 0.00 0.00 0.00
>> 7y 0.00 0.00 0.00 -679.34 0.00 0.00
>> 10y 0.00 0.00 0.00 0.00 -960.92 0.00
>> 30y 0.00 0.00 0.00 0.00 0.00 -2,404.86
>>
>> evaluationDate = trade date
>>   2y 3y 5y 7y 10y 30y
>> 2y -191.12 0.00 0.00 0.00 0.00 0.00
>> 3y 1.26 -295.48 0.00 0.00 0.00 0.00
>> 5y 1.26 0.00 -488.85 0.00 0.00 0.00
>> 7y 1.26 0.00 0.00 -679.61 0.00 0.00
>> 10y 1.26 0.00 0.00 0.00 -961.17 0.00
>> 30y 1.26 0.00 0.00 0.00 0.00 -2,405.04
>>
>>
>> Philippe
>>
>>
>> On Fri, May 29, 2020 at 3:31 PM Luigi Ballabio <lui...@gm...>
>> wrote:
>>
>>> Philippe,
>>>     bond.NPV() discounts to the reference date of the discount curve.
>>> bond.dirtyPrice() discounts to the settlement, and thus it does hold that
>>> dirtyPrice() - accruedInterest() equals cleanPrice().  As you say, the same
>>> doesn't hold for NPV.
>>>
>>> Hope this helps,
>>>     Luigi
>>>
>>>
>>> On Fri, May 29, 2020 at 9:26 PM Philippe Hatstadt <
>>> phi...@ex...> wrote:
>>>
>>>> Peter & others,
>>>> Is it 100% a fact that NPV() discounts to today and not to settle date?
>>>> because I was trying to reconcile NPV() - accruedInterest() versus
>>>> cleanPrice() but that should not work if they don't have the same
>>>> settlement date
>>>>
>>>>
>>>> Regards
>>>>
>>>> Philippe
>>>>
>>>>
>>>> On Fri, May 29, 2020 at 8:49 AM Peter Caspers <pca...@gm...>
>>>> wrote:
>>>>
>>>>> I believe helper.bond().cleanPrice() returns the (clean) price on the
>>>>> curve, but as of the bond’s settlement date, typically this is today + 2bd.
>>>>> NPV() returns the (dirty) price as of today on the other hand. Could that
>>>>> explain the difference you see?
>>>>> BR, Peter
>>>>>
>>>>> On 29 May 2020, at 03:34, Philippe Hatstadt <
>>>>> phi...@ex...> wrote:
>>>>>
>>>>> One unanswered question is whether helper.bond().cleanPrice() is
>>>>> supposed to return the clean price of the helper priced on the curve, or
>>>>> just the cleanPrice parameter that was used to build the helper?
>>>>> Given that it matches to 6 digits of precision the input quote
>>>>> clesan price, I assume it is not based on valuation on the curve,
>>>>> which should be equal to NPV(0 - accruedInterest but I would be keen to
>>>>> know.
>>>>>
>>>>> Regards
>>>>>
>>>>> Philippe
>>>>>
>>>>>
>>>>> On Thu, May 28, 2020 at 5:06 PM Mike DelMedico <
>>>>> mik...@gm...> wrote:
>>>>>
>>>>>> Without looking at your code I would guess is a convention thing when
>>>>>> you pass instrument specs to the ratehelper. Day counter, calendar, and
>>>>>> coupon frequency come to mind?  Maybe try gathering the cash flows off the
>>>>>> bond object and see if they match what you expect?
>>>>>>
>>>>>> -Mike
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Thu, May 28, 2020 at 15:34 Philippe Hatstadt <
>>>>>> phi...@ex...> wrote:
>>>>>>
>>>>>>> I am building a US treasury curve from on the run 2/3/5/7/10/30y US
>>>>>>> bonds, via tradition bond helper list and so on. How can I tell the quality
>>>>>>> of the fit of the curve? Since it's a straight bootstrapping with
>>>>>>> PiecewiseFlatForward, I would expect the repricing to be exact.
>>>>>>> In order to do that, I am doing first helper.bond().NPV(), which for
>>>>>>> the 30y bond gives me a price of 97.0322, whereas if I do
>>>>>>> helper.bond().cleanPrice(), I get 97.015625.
>>>>>>> Here is the issue: the latter price is *exactly* the input price
>>>>>>> that I entered, however, the difference between NPV() and cleanPrice() is
>>>>>>> not equal to the correct accrued interest of 0.03767 but equal to 0.01669.
>>>>>>> So either (a) helper.bond().cleanPrice() only returns the quote that
>>>>>>> was entered, but not the clean price of the bond calculated on the curve,
>>>>>>> or (b) the curve construction does not reprice the helper bond exactly,
>>>>>>> thence the incorrect value of 0.01699 above.
>>>>>>> So I am looking for some guidance on how to evaluate the exactitude
>>>>>>> of the curve building?
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Philippe
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Brokerage services offered through Exos Securities LLC, member of
>>>>>>> SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For
>>>>>>> important disclosures, click here
>>>>>>> <https://www.exosfinancial.com/disclosures>.
>>>>>>> _______________________________________________
>>>>>>> QuantLib-users mailing list
>>>>>>> Qua...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>> Brokerage services offered through Exos Securities LLC, member of SIPC
>>>>> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
>>>>> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>>>>> _______________________________________________
>>>>> QuantLib-users mailing list
>>>>> Qua...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> Brokerage services offered through Exos Securities LLC, member of SIPC
>>>> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
>>>> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>
>>>
>>
>>
>> Brokerage services offered through Exos Securities LLC, member of SIPC
>> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
>> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

-- 








Brokerage services offered through Exos Securities LLC, member of 
SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>.  For important 
disclosures, click here <https://www.exosfinancial.com/disclosures>. 

Re: [Quantlib-users] bond helpers pricing on curve

[Mike D. <mik...@gm...>]

Reference date = date which has discount factor of 1.0

So if you build a curve say with data from Tokyo open tonight, which is for
trade date Monday June 8, then 6/8/20 should be your reference date. The
settlement date of any instruments can and usually will be a different
 date.

I would assume that all the NPV calculations are discounting back to
reference date.

- Mike

On Sun, Jun 7, 2020 at 11:33 Philippe Hatstadt <
phi...@ex...> wrote:

> Luigi,
> what do you mean by "reference date" of the curve?
> The odd behavior I am observing is that if I build a curve with 2y, 3y,
> 5y, 7y, 10y and 30y US treasuries, and then I manually blip the 2y point to
> compute a key rate dv01, I would expect that only the 2y price is impacted.
> This is by setting  as follows: ql.Settings.instance().evaluationDate =
> settle_date. To be 100% clear, I am repricing the bonds used to build
> the curve on the curve itself via a PricingEngine, not using bond math.
> However, the behavior I observe is that all maturities are slightly
> impacted by blipping the 2y price used to build the curve, whereas for
> instance, the 5y is not impacted by blipping the 3y, and the 10y is not
> impacted by clipping the 3y or the 5y. Furthermore, I set the yield on the
> 2y to zero, in which case the impact was zero.
> So my conclusion is that although I set the evaluationDate to settle date,
> the NPV() method discounts to trade_date, and since the first instrument I
> use to build my curve is the 2y, then the discount factor from trade date
> to settle date is only impacted by the 2y yield.
> Lastly, if I do  ql.Settings.instance().evaluationDate  = trade_date, then
> everything works as expected. However, this is exactly the behavior I would
> not expect, as I would only expect the 2y sensitivity to impact valuation
> Date based on settle_date, in which case all discounting from tared date to
> settle date is irrelevant.
> So I am utterly confused by how to use evaluationDate to discount properly
> to either trade or settle date with the NPV() method.
> Data is below, i highlighted in yellow the "anomaly", which would be
> expected if evaluationDate was set to trade date and not settle date.
>
> evaluationDate = settle date
>   2y 3y 5y 7y 10y 30y
> 2y -192.38 -0.27 -0.28 -0.28 -0.27 -0.27
> 3y 0.00 -295.21 0.00 0.00 0.00 0.00
> 5y 0.00 0.00 -488.57 0.00 0.00 0.00
> 7y 0.00 0.00 0.00 -679.34 0.00 0.00
> 10y 0.00 0.00 0.00 0.00 -960.92 0.00
> 30y 0.00 0.00 0.00 0.00 0.00 -2,404.86
>
> evaluationDate = trade date
>   2y 3y 5y 7y 10y 30y
> 2y -191.12 0.00 0.00 0.00 0.00 0.00
> 3y 1.26 -295.48 0.00 0.00 0.00 0.00
> 5y 1.26 0.00 -488.85 0.00 0.00 0.00
> 7y 1.26 0.00 0.00 -679.61 0.00 0.00
> 10y 1.26 0.00 0.00 0.00 -961.17 0.00
> 30y 1.26 0.00 0.00 0.00 0.00 -2,405.04
>
>
> Philippe
>
>
> On Fri, May 29, 2020 at 3:31 PM Luigi Ballabio <lui...@gm...>
> wrote:
>
>> Philippe,
>>     bond.NPV() discounts to the reference date of the discount curve.
>> bond.dirtyPrice() discounts to the settlement, and thus it does hold that
>> dirtyPrice() - accruedInterest() equals cleanPrice().  As you say, the same
>> doesn't hold for NPV.
>>
>> Hope this helps,
>>     Luigi
>>
>>
>> On Fri, May 29, 2020 at 9:26 PM Philippe Hatstadt <
>> phi...@ex...> wrote:
>>
>>> Peter & others,
>>> Is it 100% a fact that NPV() discounts to today and not to settle date?
>>> because I was trying to reconcile NPV() - accruedInterest() versus
>>> cleanPrice() but that should not work if they don't have the same
>>> settlement date
>>>
>>>
>>> Regards
>>>
>>> Philippe
>>>
>>>
>>> On Fri, May 29, 2020 at 8:49 AM Peter Caspers <pca...@gm...>
>>> wrote:
>>>
>>>> I believe helper.bond().cleanPrice() returns the (clean) price on the
>>>> curve, but as of the bond’s settlement date, typically this is today + 2bd.
>>>> NPV() returns the (dirty) price as of today on the other hand. Could that
>>>> explain the difference you see?
>>>> BR, Peter
>>>>
>>>> On 29 May 2020, at 03:34, Philippe Hatstadt <
>>>> phi...@ex...> wrote:
>>>>
>>>> One unanswered question is whether helper.bond().cleanPrice() is
>>>> supposed to return the clean price of the helper priced on the curve, or
>>>> just the cleanPrice parameter that was used to build the helper?
>>>> Given that it matches to 6 digits of precision the input quote
>>>> clesan price, I assume it is not based on valuation on the curve,
>>>> which should be equal to NPV(0 - accruedInterest but I would be keen to
>>>> know.
>>>>
>>>> Regards
>>>>
>>>> Philippe
>>>>
>>>>
>>>> On Thu, May 28, 2020 at 5:06 PM Mike DelMedico <
>>>> mik...@gm...> wrote:
>>>>
>>>>> Without looking at your code I would guess is a convention thing when
>>>>> you pass instrument specs to the ratehelper. Day counter, calendar, and
>>>>> coupon frequency come to mind?  Maybe try gathering the cash flows off the
>>>>> bond object and see if they match what you expect?
>>>>>
>>>>> -Mike
>>>>>
>>>>>
>>>>>
>>>>> On Thu, May 28, 2020 at 15:34 Philippe Hatstadt <
>>>>> phi...@ex...> wrote:
>>>>>
>>>>>> I am building a US treasury curve from on the run 2/3/5/7/10/30y US
>>>>>> bonds, via tradition bond helper list and so on. How can I tell the quality
>>>>>> of the fit of the curve? Since it's a straight bootstrapping with
>>>>>> PiecewiseFlatForward, I would expect the repricing to be exact.
>>>>>> In order to do that, I am doing first helper.bond().NPV(), which for
>>>>>> the 30y bond gives me a price of 97.0322, whereas if I do
>>>>>> helper.bond().cleanPrice(), I get 97.015625.
>>>>>> Here is the issue: the latter price is *exactly* the input price that
>>>>>> I entered, however, the difference between NPV() and cleanPrice() is not
>>>>>> equal to the correct accrued interest of 0.03767 but equal to 0.01669.
>>>>>> So either (a) helper.bond().cleanPrice() only returns the quote that
>>>>>> was entered, but not the clean price of the bond calculated on the curve,
>>>>>> or (b) the curve construction does not reprice the helper bond exactly,
>>>>>> thence the incorrect value of 0.01699 above.
>>>>>> So I am looking for some guidance on how to evaluate the exactitude
>>>>>> of the curve building?
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Philippe
>>>>>>
>>>>>>
>>>>>>
>>>>>> Brokerage services offered through Exos Securities LLC, member of
>>>>>> SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For
>>>>>> important disclosures, click here
>>>>>> <https://www.exosfinancial.com/disclosures>.
>>>>>> _______________________________________________
>>>>>> QuantLib-users mailing list
>>>>>> Qua...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>>
>>>>>
>>>>
>>>>
>>>> Brokerage services offered through Exos Securities LLC, member of SIPC
>>>> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
>>>> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>>>> _______________________________________________
>>>> QuantLib-users mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>
>>>>
>>>>
>>>
>>>
>>> Brokerage services offered through Exos Securities LLC, member of SIPC
>>> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
>>> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>
>
>
> Brokerage services offered through Exos Securities LLC, member of SIPC
> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
> disclosures, click here <https://www.exosfinancial.com/disclosures>.
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] bond helpers pricing on curve

[philippe h. <pha...@ma...>]

Correction: 
Instead of:
> “as I would only expect the 2y sensitivity to impact valuation Date based on settle_date“
I should have said:
> 
> “as I would only expect the 2y sensitivity to impact valuation Date based on trade_date”
> 
Regards

Philippe Hatstadt
+1-203-252-0408
pha...@ma...
https://www.linkedin.com/in/philippe-hatstadt


> On Jun 7, 2020, at 12:30 PM, Philippe Hatstadt <Phi...@ex...> wrote:
> 
> 
> Luigi,
> what do you mean by "reference date" of the curve?
> The odd behavior I am observing is that if I build a curve with 2y, 3y, 5y, 7y, 10y and 30y US treasuries, and then I manually blip the 2y point to compute a key rate dv01, I would expect that only the 2y price is impacted. This is by setting  as follows: ql.Settings.instance().evaluationDate = settle_date. To be 100% clear, I am repricing the bonds used to build the curve on the curve itself via a PricingEngine, not using bond math.
> However, the behavior I observe is that all maturities are slightly impacted by blipping the 2y price used to build the curve, whereas for instance, the 5y is not impacted by blipping the 3y, and the 10y is not impacted by clipping the 3y or the 5y. Furthermore, I set the yield on the 2y to zero, in which case the impact was zero. 
> So my conclusion is that although I set the evaluationDate to settle date, the NPV() method discounts to trade_date, and since the first instrument I use to build my curve is the 2y, then the discount factor from trade date to settle date is only impacted by the 2y yield.
> Lastly, if I do  ql.Settings.instance().evaluationDate  = trade_date, then everything works as expected. However, this is exactly the behavior I would not expect, as I would only expect the 2y sensitivity to impact valuation Date based on settle_date, in which case all discounting from tared date to settle date is irrelevant.
> So I am utterly confused by how to use evaluationDate to discount properly to either trade or settle date with the NPV() method.
> Data is below, i highlighted in yellow the "anomaly", which would be expected if evaluationDate was set to trade date and not settle date.
> 
> evaluationDate = settle date	 	 	 	 
>  	2y	3y	5y	7y	10y	30y
> 2y	-192.38	-0.27	-0.28	-0.28	-0.27	-0.27
> 3y	0.00	-295.21	0.00	0.00	0.00	0.00
> 5y	0.00	0.00	-488.57	0.00	0.00	0.00
> 7y	0.00	0.00	0.00	-679.34	0.00	0.00
> 10y	0.00	0.00	0.00	0.00	-960.92	0.00
> 30y	0.00	0.00	0.00	0.00	0.00	-2,404.86
>  	 	 	 	 	 	 
> evaluationDate = trade date	 	 	 	 
>  	2y	3y	5y	7y	10y	30y
> 2y	-191.12	0.00	0.00	0.00	0.00	0.00
> 3y	1.26	-295.48	0.00	0.00	0.00	0.00
> 5y	1.26	0.00	-488.85	0.00	0.00	0.00
> 7y	1.26	0.00	0.00	-679.61	0.00	0.00
> 10y	1.26	0.00	0.00	0.00	-961.17	0.00
> 30y	1.26	0.00	0.00	0.00	0.00	-2,405.04
> 
> 
> Philippe
> 
> 
>> On Fri, May 29, 2020 at 3:31 PM Luigi Ballabio <lui...@gm...> wrote:
>> Philippe,
>>     bond.NPV() discounts to the reference date of the discount curve.  bond.dirtyPrice() discounts to the settlement, and thus it does hold that dirtyPrice() - accruedInterest() equals cleanPrice().  As you say, the same doesn't hold for NPV.
>> 
>> Hope this helps,
>>     Luigi
>> 
>> 
>>> On Fri, May 29, 2020 at 9:26 PM Philippe Hatstadt <phi...@ex...> wrote:
>>> Peter & others,
>>> Is it 100% a fact that NPV() discounts to today and not to settle date? because I was trying to reconcile NPV() - accruedInterest() versus cleanPrice() but that should not work if they don't have the same settlement date
>>> 
>>> 
>>> Regards
>>> 
>>> Philippe
>>> 
>>> 
>>>> On Fri, May 29, 2020 at 8:49 AM Peter Caspers <pca...@gm...> wrote:
>>>> I believe helper.bond().cleanPrice() returns the (clean) price on the curve, but as of the bond’s settlement date, typically this is today + 2bd. NPV() returns the (dirty) price as of today on the other hand. Could that explain the difference you see?
>>>> BR, Peter
>>>> 
>>>>> On 29 May 2020, at 03:34, Philippe Hatstadt <phi...@ex...> wrote:
>>>>> 
>>>>> One unanswered question is whether helper.bond().cleanPrice() is supposed to return the clean price of the helper priced on the curve, or just the cleanPrice parameter that was used to build the helper?
>>>>> Given that it matches to 6 digits of precision the input quote clesan price, I assume it is not based on valuation on the curve, which should be equal to NPV(0 - accruedInterest but I would be keen to know.
>>>>> 
>>>>> Regards
>>>>> 
>>>>> Philippe
>>>>> 
>>>>> 
>>>>>> On Thu, May 28, 2020 at 5:06 PM Mike DelMedico <mik...@gm...> wrote:
>>>>>> Without looking at your code I would guess is a convention thing when you pass instrument specs to the ratehelper. Day counter, calendar, and coupon frequency come to mind?  Maybe try gathering the cash flows off the bond object and see if they match what you expect?
>>>>>> 
>>>>>> -Mike
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> On Thu, May 28, 2020 at 15:34 Philippe Hatstadt <phi...@ex...> wrote:
>>>>>>> I am building a US treasury curve from on the run 2/3/5/7/10/30y US bonds, via tradition bond helper list and so on. How can I tell the quality of the fit of the curve? Since it's a straight bootstrapping with PiecewiseFlatForward, I would expect the repricing to be exact.
>>>>>>> In order to do that, I am doing first helper.bond().NPV(), which for the 30y bond gives me a price of 97.0322, whereas if I do helper.bond().cleanPrice(), I get 97.015625. 
>>>>>>> Here is the issue: the latter price is *exactly* the input price that I entered, however, the difference between NPV() and cleanPrice() is not equal to the correct accrued interest of 0.03767 but equal to 0.01669.
>>>>>>> So either (a) helper.bond().cleanPrice() only returns the quote that was entered, but not the clean price of the bond calculated on the curve, or (b) the curve construction does not reprice the helper bond exactly, thence the incorrect value of 0.01699 above.
>>>>>>> So I am looking for some guidance on how to evaluate the exactitude of the curve building?
>>>>>>> 
>>>>>>> Regards
>>>>>>> 
>>>>>>> Philippe
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> Brokerage services offered through Exos Securities LLC, member of SIPC / FINRA.  For important disclosures, click here. 
>>>>>>> _______________________________________________
>>>>>>> QuantLib-users mailing list
>>>>>>> Qua...@li...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>> 
>>>>> 
>>>>> 
>>>>> Brokerage services offered through Exos Securities LLC, member of SIPC / FINRA.  For important disclosures, click here. 
>>>>> _______________________________________________
>>>>> QuantLib-users mailing list
>>>>> Qua...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>> 
>>> 
>>> 
>>> 
>>> Brokerage services offered through Exos Securities LLC, member of SIPC / FINRA.  For important disclosures, click here. 
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
> 
> 
> 
> Brokerage services offered through Exos Securities LLC, member of SIPC / FINRA.  For important disclosures, click here. 
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] bond helpers pricing on curve

[Philippe H. <phi...@ex...>]

Luigi,
what do you mean by "reference date" of the curve?
The odd behavior I am observing is that if I build a curve with 2y, 3y, 5y,
7y, 10y and 30y US treasuries, and then I manually blip the 2y point to
compute a key rate dv01, I would expect that only the 2y price is impacted.
This is by setting  as follows: ql.Settings.instance().evaluationDate =
settle_date. To be 100% clear, I am repricing the bonds used to build
the curve on the curve itself via a PricingEngine, not using bond math.
However, the behavior I observe is that all maturities are slightly
impacted by blipping the 2y price used to build the curve, whereas for
instance, the 5y is not impacted by blipping the 3y, and the 10y is not
impacted by clipping the 3y or the 5y. Furthermore, I set the yield on the
2y to zero, in which case the impact was zero.
So my conclusion is that although I set the evaluationDate to settle date,
the NPV() method discounts to trade_date, and since the first instrument I
use to build my curve is the 2y, then the discount factor from trade date
to settle date is only impacted by the 2y yield.
Lastly, if I do  ql.Settings.instance().evaluationDate  = trade_date, then
everything works as expected. However, this is exactly the behavior I would
not expect, as I would only expect the 2y sensitivity to impact valuation
Date based on settle_date, in which case all discounting from tared date to
settle date is irrelevant.
So I am utterly confused by how to use evaluationDate to discount properly
to either trade or settle date with the NPV() method.
Data is below, i highlighted in yellow the "anomaly", which would be
expected if evaluationDate was set to trade date and not settle date.

evaluationDate = settle date
  2y 3y 5y 7y 10y 30y
2y -192.38 -0.27 -0.28 -0.28 -0.27 -0.27
3y 0.00 -295.21 0.00 0.00 0.00 0.00
5y 0.00 0.00 -488.57 0.00 0.00 0.00
7y 0.00 0.00 0.00 -679.34 0.00 0.00
10y 0.00 0.00 0.00 0.00 -960.92 0.00
30y 0.00 0.00 0.00 0.00 0.00 -2,404.86

evaluationDate = trade date
  2y 3y 5y 7y 10y 30y
2y -191.12 0.00 0.00 0.00 0.00 0.00
3y 1.26 -295.48 0.00 0.00 0.00 0.00
5y 1.26 0.00 -488.85 0.00 0.00 0.00
7y 1.26 0.00 0.00 -679.61 0.00 0.00
10y 1.26 0.00 0.00 0.00 -961.17 0.00
30y 1.26 0.00 0.00 0.00 0.00 -2,405.04


Philippe


On Fri, May 29, 2020 at 3:31 PM Luigi Ballabio <lui...@gm...>
wrote:

> Philippe,
>     bond.NPV() discounts to the reference date of the discount curve.
> bond.dirtyPrice() discounts to the settlement, and thus it does hold that
> dirtyPrice() - accruedInterest() equals cleanPrice().  As you say, the same
> doesn't hold for NPV.
>
> Hope this helps,
>     Luigi
>
>
> On Fri, May 29, 2020 at 9:26 PM Philippe Hatstadt <
> phi...@ex...> wrote:
>
>> Peter & others,
>> Is it 100% a fact that NPV() discounts to today and not to settle date?
>> because I was trying to reconcile NPV() - accruedInterest() versus
>> cleanPrice() but that should not work if they don't have the same
>> settlement date
>>
>>
>> Regards
>>
>> Philippe
>>
>>
>> On Fri, May 29, 2020 at 8:49 AM Peter Caspers <pca...@gm...>
>> wrote:
>>
>>> I believe helper.bond().cleanPrice() returns the (clean) price on the
>>> curve, but as of the bond’s settlement date, typically this is today + 2bd.
>>> NPV() returns the (dirty) price as of today on the other hand. Could that
>>> explain the difference you see?
>>> BR, Peter
>>>
>>> On 29 May 2020, at 03:34, Philippe Hatstadt <
>>> phi...@ex...> wrote:
>>>
>>> One unanswered question is whether helper.bond().cleanPrice() is
>>> supposed to return the clean price of the helper priced on the curve, or
>>> just the cleanPrice parameter that was used to build the helper?
>>> Given that it matches to 6 digits of precision the input quote
>>> clesan price, I assume it is not based on valuation on the curve,
>>> which should be equal to NPV(0 - accruedInterest but I would be keen to
>>> know.
>>>
>>> Regards
>>>
>>> Philippe
>>>
>>>
>>> On Thu, May 28, 2020 at 5:06 PM Mike DelMedico <mik...@gm...>
>>> wrote:
>>>
>>>> Without looking at your code I would guess is a convention thing when
>>>> you pass instrument specs to the ratehelper. Day counter, calendar, and
>>>> coupon frequency come to mind?  Maybe try gathering the cash flows off the
>>>> bond object and see if they match what you expect?
>>>>
>>>> -Mike
>>>>
>>>>
>>>>
>>>> On Thu, May 28, 2020 at 15:34 Philippe Hatstadt <
>>>> phi...@ex...> wrote:
>>>>
>>>>> I am building a US treasury curve from on the run 2/3/5/7/10/30y US
>>>>> bonds, via tradition bond helper list and so on. How can I tell the quality
>>>>> of the fit of the curve? Since it's a straight bootstrapping with
>>>>> PiecewiseFlatForward, I would expect the repricing to be exact.
>>>>> In order to do that, I am doing first helper.bond().NPV(), which for
>>>>> the 30y bond gives me a price of 97.0322, whereas if I do
>>>>> helper.bond().cleanPrice(), I get 97.015625.
>>>>> Here is the issue: the latter price is *exactly* the input price that
>>>>> I entered, however, the difference between NPV() and cleanPrice() is not
>>>>> equal to the correct accrued interest of 0.03767 but equal to 0.01669.
>>>>> So either (a) helper.bond().cleanPrice() only returns the quote that
>>>>> was entered, but not the clean price of the bond calculated on the curve,
>>>>> or (b) the curve construction does not reprice the helper bond exactly,
>>>>> thence the incorrect value of 0.01699 above.
>>>>> So I am looking for some guidance on how to evaluate the exactitude of
>>>>> the curve building?
>>>>>
>>>>> Regards
>>>>>
>>>>> Philippe
>>>>>
>>>>>
>>>>>
>>>>> Brokerage services offered through Exos Securities LLC, member of SIPC
>>>>> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
>>>>> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>>>>> _______________________________________________
>>>>> QuantLib-users mailing list
>>>>> Qua...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>>>
>>>>
>>>
>>>
>>> Brokerage services offered through Exos Securities LLC, member of SIPC
>>> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
>>> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>>
>>>
>>
>>
>> Brokerage services offered through Exos Securities LLC, member of SIPC
>> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
>> disclosures, click here <https://www.exosfinancial.com/disclosures>.
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

-- 








Brokerage services offered through Exos Securities LLC, member of 
SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>.  For important 
disclosures, click here <https://www.exosfinancial.com/disclosures>. 

Re: [Quantlib-users] RelinkableHandle<> and impact on run time for multi-step Monte Carlo

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

Hello Amine,
    you're using C++, not Python, is that correct?  (Just to rule out <
https://github.com/lballabio/QuantLib-SWIG/issues/212>).

Luigi


On Fri, Jun 5, 2020 at 6:12 PM Amine Ifri <ami...@gm...> wrote:

> Hi Luigi, all,
>
> I have been working on leveraging QL to create a small multi-step Monte
> Carlo framework which simulates market data at each future time step and
> calls discounting swap engine on vanilla swaps.  A full Monte Carlo run
> with 1000 scenarios and 350 time points takes about 4min to run. I run my
> application through the time profiler and noticed that quite a bit of time
> is spent in the scenario loop where I continuously relink the yield curve
> handle to the appropriately simulated curve.
>
> Are there any ways/tips one could provide on where I could look for extra
> time savings? I found out that by using the discount(Time ) instead of the
> discount(Date&) variant of the method for example, one can save on the year
> fraction calculation, which improves the time a bit. I also de-activated a
> check on MaxTime() in TermStructure::checkRange() which is continuously
> called at each scenario.
>
> In particular, I would like to know if I could switch off the notify
> observers() in the Handle::linkTo() method without affecting the inner
> workings, as I am not interested at this stage in using the
> observable/observer pattern.
>
> Thanks and Regards,
> Amine

[Quantlib-users] Gaussian short rate model + calibration

[<mat...@gm...>]

Dear QL users,

I cannot say I have great familiarity with short-rate or market models, so please bear with me on this one:

Trying to value a multi-callable swaption and bond using a Hull-White model with (piecewise) time-dependent volatility.
As I understand, <ql/models/shortrate/onefactormodels/hullwhite.hpp> does not satisfy this condition:

	This class implements the standard single-factor Hull-White model defined by
	        \f[
	            dr_t = (\theta(t) - \alpha r_t)dt + \sigma dW_t
	        \f]
	where \f$ \alpha \f$ and \f$ \sigma \f$ are constants.

I believe it was this ML's archive where I picked up Gsr as a recommended alternative and it looks fine (for some definition of "fine") for swaption pricing.
There are two questions, however:

1) It is apparently not possible to calibrate both volatilities and reversion(s).

While Gsr implements CalibratedModel, performing "joint" calibration like this

	// vector<bool> fixedParms = gsr->FixedReversions();
	vector<Real> modelVols(voldates.size() + 1, 0.01);         
	 fixedParms = vector<bool>(modelVols.size() + 1, false);
	gsr->calibrate(calibSet, lm, ec, NoConstraint{}, vector<Real>{}, fixedParms);

would not work, because only the first modelVols.size() number of calibration instruments are acknowledged, leaving the optimizer with an under-determined function.

Likely there is a good reason for this. Market practice to have mean reversion as a given model parameter? Or that is just the way the model is supposed to work?

2) There is no pricing engine for callable bonds that can consume Gsr, if I am not mistaken. Gsr does not seem to implement ShortRateModel:

	Gsr <- {Gaussian1dModel, CalibratedModel, ...} <- {TermStructureConsistentModel, ...}

Likely to do with the tree(const TimeGrid&) method in that interface. Alternatively, there is <ql/experimental/shortrate/generalizedhullwhite.hpp>. It sits in the "experimental" folder, but so does everything callable bond related. So I wonder whether the latter is more suitable for instrument/bond pricing while Gsr might be more model of choice for scenario generation purposes?


Again, apologies for any incorrect terminology or confusing remarks. Happy to clarify further, if necessary (and possible for me).


Thank you,

Matthias

[Quantlib-users] RelinkableHandle<> and impact on run time for multi-step Monte Carlo

[Amine I. <ami...@gm...>]

Hi Luigi, all,

I have been working on leveraging QL to create a small multi-step Monte Carlo framework which simulates market data at each future time step and calls discounting swap engine on vanilla swaps.  A full Monte Carlo run with 1000 scenarios and 350 time points takes about 4min to run. I run my application through the time profiler and noticed that quite a bit of time is spent in the scenario loop where I continuously relink the yield curve handle to the appropriately simulated curve.

Are there any ways/tips one could provide on where I could look for extra time savings? I found out that by using the discount(Time ) instead of the discount(Date&) variant of the method for example, one can save on the year fraction calculation, which improves the time a bit. I also de-activated a check on MaxTime() in TermStructure::checkRange() which is continuously called at each scenario.

In particular, I would like to know if I could switch off the notify observers() in the Handle::linkTo() method without affecting the inner workings, as I am not interested at this stage in using the observable/observer pattern.

Thanks and Regards,
Amine

Re: [Quantlib-users] How to get information on parameters of typical Python-quantlib function

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

Thanks a lot for the links, Aleksis.  I would also add the reference for
the C++ library at <https://www.quantlib.org/reference/>, which is more up
to date than the "annotated source" page you linked.  That one seems to be
a copy of the reference for version 1.12.

Luigi


On Sat, May 16, 2020 at 8:25 PM Aleksis Ali Raza via QuantLib-users <
qua...@li...> wrote:

> I think this is something that one needs to get used to when starting out
> - there doesn’t appear to be an official “quantlib python manual” to my
> knowledge. However, here are a few resources that are quite useful:
>
> David Duarte has this project:
> https://quantlib-python-docs.readthedocs.io/en/latest/index.html
>
> Also there’s Ballabio & Balaraman’s:
> https://leanpub.com/quantlibpythoncookbook/
>
> There’s a GitHub page for the quantlib C++ library (brace yourself for the
> several methods not in quantlib python):
> https://rkapl123.github.io/QLAnnotatedSource/index.html
>
> QuantlibXL has a useful manual for the quantlib xll addin:
> https://www.quantlib.org/quantlibxl/categories.html
>
> Finally, the debugging window within your python IDE itself gives pretty
> useful information on class arguments etc when coding.
>
> On 16 May 2020, at 18:59, Christofer Bogaso <bog...@gm...>
> wrote:
>
> Hi,
>
> I am new to Quantlib and started using it through python library. A
> typical start may be -
>
> import QuantLib as ql
>
> schedule = ql.Schedule(date1, date2, tenor, calendar, ql.Following,
>                           ql.Following, ql.DateGeneration.Forward, False)
>
> How can I know about all the input parameters of ql.Schedule like
> underlying classes, what they actually mean etc in a systematic way?
>
> Sorry if my question is too simple, but appreciate your help.
>
> Thanks,
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] cir process/ quantlib python

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

Hello,
    the CIR process has been added recently (
https://github.com/lballabio/QuantLib/pull/824) but it's not yet in a
release.  It will be in version 1.19.  In the meantime, you can check out
the development version from git master and compile it.

Hope this helps,
    Luigi


On Tue, May 19, 2020 at 8:40 PM stefano pignataro via QuantLib-users <
qua...@li...> wrote:

> hello,
>
> is it possible to simulate the CIR (cox ingersoll ross) model (given that
> i have the 3 parameters and initial value of the process) using some of the
> quantlib/python function in a similar way as i can for example simulate the
> geometric brownian motion by using the quantlib constructor
> "Quantlib.GeometricBrownianMotionProcess"?
>
> i can create a function that simulate the CIR with python, but i would
> like to use it then into the quantlib function GaussianMultiPathGenerator
> therefore i need a "quantlib process".
>
> i believe quantlib c++ has the CIR process. maybe i can build the process
> in quantlib python by starting from StochasticProcess1D? not much
> documentation on that, though
>
> Inviato da Yahoo Mail su Android
> <https://go.onelink.me/107872968?pid=InProduct&c=Global_Internal_YGrowth_AndroidEmailSig__AndroidUsers&af_wl=ym&af_sub1=Internal&af_sub2=Global_YGrowth&af_sub3=EmailSignature>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] IMM rolls

[Mike D. <mik...@gm...>]

Glad it worked.  When I build the schedules, the dates seem to flow fine,
so not sure why your end date wouldn't line up with the proper final IMM
date.  See below:

floatSchedule = ql.Schedule(effectiveDate,
                            maturityDate,
                            ql.Period(3, ql.Months),
                            calendarUSD_FedFund,
                            ql.ModifiedFollowing,
                            ql.ModifiedFollowing,
                            ql.DateGeneration.ThirdWednesday,
                            False)

for i in floatSchedule:
    print(i)

June 17th, 2020
September 16th, 2020
December 16th, 2020
March 17th, 2021
June 16th, 2021
September 15th, 2021
December 15th, 2021
March 16th, 2022
June 15th, 2022
September 21st, 2022
December 21st, 2022
March 15th, 2023
June 21st, 2023


On Tue, Jun 2, 2020 at 2:50 PM Tom Anderson <tw...@ur...> wrote:

> That mostly does it, thanks!
>
> For some reason, i had assumed that the accrual periods for each coupon
> were based directly on the frequency or index tenor, rather than running
> to the next date. Too much time spent looking at futures bundles probably.
>
> It seems like i also need to tweak the end date. ThirdWednesday
> specifically doesn't do that.
>
> tom
>
> On Fri, 29 May 2020, Mike DelMedico wrote:
>
> > I’m pretty sure you just flip the generator from ‘Backward” to
> > “ThirdWednesday” and you should be good to go.
> >
> > These are very common use now given everyone’s desire to minimize line
> > items. Much easier to compress a book of swaps that have all the cashflow
> > dates lined up instead of a book with dozens of different reset dates.
> >
> > The other popular flavor is IMM effective but with standard rolls.
> >
> > -Mike
> >
> >
> > On Fri, May 29, 2020 at 12:45 Tom Anderson <tw...@ur...> wrote:
> >
> >> Hello,
> >>
> >> There are some dreadful interest rate swaps which use "IMM rolls" - the
> >> cashflows are on quarterly IMM dates, and the cashflow reflects an
> accrual
> >> over the period from that IMM date to the next one.
> >>
> >> (I think. I can't find a precise definition of how these swaps work.
> They
> >> just exist.)
> >>
> >> Does QuantLib support such swaps?
> >>
> >> I can generate a custom Schedule where cashflows are on IMM dates, but i
> >> don't know of a way to tweak the accrual periods for each cashflow.
> >>
> >> Thanks,
> >> tom
> >>
> >> --
> >> 12:28 <@ashak> why wouldn't you run it as root? Yuo don't get permission
> >> denied's on things then ;)
> >>
> >>
> >> _______________________________________________
> >> QuantLib-users mailing list
> >> Qua...@li...
> >> https://lists.sourceforge.net/lists/listinfo/quantlib-users
> >>
> >
>
> --
> There are only two hard things in computer science: cache invalidation,
> naming things, and off-by-one errors. -- anonymous

Re: [Quantlib-users] IMM rolls

[Tom A. <tw...@ur...>]

That mostly does it, thanks!

For some reason, i had assumed that the accrual periods for each coupon 
were based directly on the frequency or index tenor, rather than running 
to the next date. Too much time spent looking at futures bundles probably.

It seems like i also need to tweak the end date. ThirdWednesday 
specifically doesn't do that.

tom

On Fri, 29 May 2020, Mike DelMedico wrote:

> I’m pretty sure you just flip the generator from ‘Backward” to
> “ThirdWednesday” and you should be good to go.
>
> These are very common use now given everyone’s desire to minimize line
> items. Much easier to compress a book of swaps that have all the cashflow
> dates lined up instead of a book with dozens of different reset dates.
>
> The other popular flavor is IMM effective but with standard rolls.
>
> -Mike
>
>
> On Fri, May 29, 2020 at 12:45 Tom Anderson <tw...@ur...> wrote:
>
>> Hello,
>>
>> There are some dreadful interest rate swaps which use "IMM rolls" - the
>> cashflows are on quarterly IMM dates, and the cashflow reflects an accrual
>> over the period from that IMM date to the next one.
>>
>> (I think. I can't find a precise definition of how these swaps work. They
>> just exist.)
>>
>> Does QuantLib support such swaps?
>>
>> I can generate a custom Schedule where cashflows are on IMM dates, but i
>> don't know of a way to tweak the accrual periods for each cashflow.
>>
>> Thanks,
>> tom
>>
>> --
>> 12:28 <@ashak> why wouldn't you run it as root? Yuo don't get permission
>> denied's on things then ;)
>>
>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

-- 
There are only two hard things in computer science: cache invalidation,
naming things, and off-by-one errors. -- anonymous

[Quantlib-users] Key Rate 01 of corporate bond

[Philippe H. <phi...@ex...>]

I am pricing a corporate bond from a US treasury curve shifted by a credit
z-spread with the following steps:
1. Build a US Treasury curve via traditional helpers based on 6 UST bond
clean prices (2/3/5/7/10/30y), with ql.QuoteHandle() for each bond price
input

ust_crv = ql.PiecewiseFlatForward(settle_date, helpers, day_count)

2. Build a shifted curve handle as follows:

corp_spread = ql.SimpleQuote(shift)
corp_spreadh = ql.QuoteHandle(corp_spread)
ust_crvh = ql.RelinkableYieldTermStructureHandle(ust_crv)
corp_crv = ql.ZeroSpreadedTermStructure(ust_crvh, corp_spreadh)
corp_crv_handle = ql.RelinkableYieldTermStructureHandle(corp_crv)

3. Create a corporate fixed rate bond corp_bond via ql.Bond() and set its
pricing engine as follows:

transEngine = ql.DiscountingBondEngine(corp_crv_handle)
corp_bond.setPricingEngine(transEngine)

4. get the base dirty price of the bond via corp_bond.NPV(), acknowledging
that since the UST curve ust_crv is built from helpers that have US
treasury bond price inputs based on ql.QuoteHandle() then corp_bond.NPV()
should inherit lazy NPV property from the base ust_crv. in other words,
when I change any US treasury bond input price, corp_bond.NPV() should
change. The latter behavior is satisfied.

Here is my problem:
I am trying to write a module to compute the key rate 01 (KR01) to the UST
curve, keeping the corporate spread constant, whereby I shift each of the 6
bond inputs by a price shift corresponding to one yield basis point
converted to a price shift via the bond's respective dv01. My approach is
therefore to use the lazy NPv() whereby via the curve dependencies,
perturbing one input in the UST curve would propagate to the shifter
corporate curve, thence impact the corporate bond price via lazy NPV.
So I do a loop as follows:

def key_rate_dv01(corp_bond, helpers):
    base_npv = corp_bond.NPV()
    for helper in helpers:
        helper_base_value = helper.bond().cleanPrice()
        quote = helper.quote
        '''here I do some bond math to compute the dv01 of the helper
based on ql bond math
        but didn't include code to simplify'''
        quote.setValue(helper_base_value + helper_dv01)
        deal_dv01 = corp_bond.NPV() - base_npv
        print(f'{helper}:{deal_dv01}')
        quote.setValue(helper_base_value)

The code above does "something", because for each iteration, I get a
non-zero deal_dv01. However, the results are not correct, when compared to
a "brute force" approach whereby I simply rebuild the base curve by
perturbing the bond price input to the curve directly. the results differ
by about 10% relative, which is clearly wrong.

So I am wondering if there is any flaw in my logic above?

Regards

Philippe

-- 








Brokerage services offered through Exos Securities LLC, member of 
SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/>.  For important 
disclosures, click here <https://www.exosfinancial.com/disclosures>. 

Re: [Quantlib-users] bond() to bond helper

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

Hello,
    the constructor of the BondHelper class takes a shared_ptr to a bond
instance.

Luigi


On Fri, May 22, 2020 at 12:45 AM Philippe Hatstadt <
phi...@ex...> wrote:

> Hi.
> Is there a function to convert a ql.bond() to a bond helper that would
> keep all the parameters? I have a number of US treasury bond instances that
> I use and I'd like to build a curve from them.
>
>
> Regards
>
> Philippe
>
>
>
> Brokerage services offered through Exos Securities LLC, member of SIPC
> <http://www.sipc.org/> / FINRA <http://www.finra.org/>. For important
> disclosures, click here <https://www.exosfinancial.com/disclosures>.
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>