quantlib-users — QuantLib users discussion list

Re: [Quantlib-users] Estimating sensitivities of a Swap contract

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

You will have to bump the 2y spot rate and revalue your swap, then diff the
npvs. As an alternative you can also shift the entire zero curve (using
ql.ZeroSpreadedTermStructure) and price the swap on that curve and then
diff the npvs.  I believe this is detailed in the quantlib cookbook if you
want examples.

Personally, I’ve always kept two separate curve objects (original and
shifted), even though I know the code is supposed to support changing
quotes on the fly etc. For some reason I’ve always encountered memory leaks
when using relinkable term structure handles, but it’s probably an
implementation error or my end if I had to guess.

Hope that helps.

-Mike


On Sun, Nov 13, 2022 at 12:32 Christofer Bogaso <bog...@gm...>
wrote:

> Hi,
>
> I have below interest rate swap contract
>
> from QuantLib import *
> calc_date = Date(31, 12, 2013)
> Settings.instance().evaluationDate = calc_date
> spot_dates = [calc_date + Period("1d"), calc_date + Period("1w"),
> calc_date + Period("1m"), calc_date + Period("2m"), calc_date +
> Period("3m"), calc_date + Period("6m"),
>                 calc_date + Period("1y"), calc_date + Period("2y"),
> calc_date + Period("3y"), calc_date + Period("4y"), calc_date +
> Period("5y"),
>                 calc_date + Period("7y"), calc_date + Period("10y"),
> calc_date + Period("30y")]
> spot_rates = [0.1/100, 0.13/100, 0.17/100, 0.21/100, 0.2461/100,
> 0.35/100, 0.31/100, 0.49/100, 0.87/100, 1.33/100, 1.78/100, 2.47/100,
> 3.09/100, 3.91/100]
> us_calendar = UnitedStates()
> zero_curve = ZeroCurve(spot_dates, spot_rates, Actual365Fixed(),
> us_calendar, Linear(), Compounded, Annual)
> termStructure = YieldTermStructureHandle(zero_curve)
> swap = VanillaSwap(VanillaSwap.Payer,
>                       100,
>                       Schedule(Date(1, 12, 2014) + Period("6m"),
> Date(1, 12, 2019), Period(6, Months), us_calendar, Unadjusted,
> Unadjusted, DateGeneration.Forward, False),
>                       3/100,
>                       Thirty360(Thirty360.BondBasis),
>                       Schedule(Date(1, 12, 2014) + Period("6m"),
> Date(1, 12, 2019), Period(6, Months), us_calendar, Unadjusted,
> Unadjusted, DateGeneration.Forward, False),
>                       USDLibor(Period(6, Months), termStructure),
>                       0.0,
>                       USDLibor(Period(6, Months),
> termStructure).dayCounter()
>                     )
> swap.setPricingEngine(DiscountingSwapEngine(termStructure))
>
> I am wondering if there is any method available to calculate the Delta
> sensitivity of this Swap contract w.r.t. different sopt rate e.g. let
> say 2 year spot rate that was used to constract the term structure.
>
> Any pointer will be very helpful.
>
> Many thanks for your time.
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Estimating sensitivities of a Swap contract

[Christofer B. <bog...@gm...>]

Hi,

I have below interest rate swap contract

from QuantLib import *
calc_date = Date(31, 12, 2013)
Settings.instance().evaluationDate = calc_date
spot_dates = [calc_date + Period("1d"), calc_date + Period("1w"),
calc_date + Period("1m"), calc_date + Period("2m"), calc_date +
Period("3m"), calc_date + Period("6m"),
                calc_date + Period("1y"), calc_date + Period("2y"),
calc_date + Period("3y"), calc_date + Period("4y"), calc_date +
Period("5y"),
                calc_date + Period("7y"), calc_date + Period("10y"),
calc_date + Period("30y")]
spot_rates = [0.1/100, 0.13/100, 0.17/100, 0.21/100, 0.2461/100,
0.35/100, 0.31/100, 0.49/100, 0.87/100, 1.33/100, 1.78/100, 2.47/100,
3.09/100, 3.91/100]
us_calendar = UnitedStates()
zero_curve = ZeroCurve(spot_dates, spot_rates, Actual365Fixed(),
us_calendar, Linear(), Compounded, Annual)
termStructure = YieldTermStructureHandle(zero_curve)
swap = VanillaSwap(VanillaSwap.Payer,
                      100,
                      Schedule(Date(1, 12, 2014) + Period("6m"),
Date(1, 12, 2019), Period(6, Months), us_calendar, Unadjusted,
Unadjusted, DateGeneration.Forward, False),
                      3/100,
                      Thirty360(Thirty360.BondBasis),
                      Schedule(Date(1, 12, 2014) + Period("6m"),
Date(1, 12, 2019), Period(6, Months), us_calendar, Unadjusted,
Unadjusted, DateGeneration.Forward, False),
                      USDLibor(Period(6, Months), termStructure),
                      0.0,
                      USDLibor(Period(6, Months), termStructure).dayCounter()
                    )
swap.setPricingEngine(DiscountingSwapEngine(termStructure))

I am wondering if there is any method available to calculate the Delta
sensitivity of this Swap contract w.r.t. different sopt rate e.g. let
say 2 year spot rate that was used to constract the term structure.

Any pointer will be very helpful.

Many thanks for your time.

[Quantlib-users] difference between Gaussian1dSwaptionEngine and Gaussian1dJamshidianSwaptionEngine

[<log...@se...>]

Hello, 
I'm pricing a swaption where the underlying swap's floating leg is based on 
curve1.

Then I have another curve, say curve2, which I use in GSR like this

model = ql.Gsr(curve2, volStepDates, volatilities, reversions)





When I use in the swaption pricing:

A) engine = ql.Gaussian1dSwaptionEngine(model)

B) engine = ql.Gaussian1dJamshidianSwaptionEngine(model)


I'm getting quite a significant difference between NPV A) and NPV B), is not
due to technical nature of the pricer.





It feels like Gaussian1dJamshidianSwaptionEngine ignores the floating leg's 
curve1 (and usese curve2 everywhere), while the Gaussian1dSwaptionEngine 
takes into account curve1 for the floating leg. Can someone please explain 
how curves are treated in these pricers? 




Thanks, 

M.

Re: [Quantlib-users] QuantLib query

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

Hello,
    SwapRateHelper creates the swap schedule (and the swap itself)
internally, and during the bootstrap it calculates the fair swap rate
according to the curve being bootstrapped and reports the difference to the
bootstrapping algorithm so that it can adjust the curve accordingly.  If
you want more details on the implementation of the bootstrapping process,
you can have a look at <
https://www.implementingquantlib.com/2013/10/chapter-3-part-3-of-n-bootstrapping.html>.
An example of usage is in the Examples/MulticurveBootstrapping folder in
the QuantLib C++ sources.

The swap helper, of course, needs to be given conventions to build the
swap.  Some of its constructors take those conventions explicitly (e.g.,
the one at <
https://github.com/lballabio/QuantLib/blob/QuantLib-v1.28/ql/termstructures/yield/ratehelpers.hpp#L272>.
Some others take a SwapIndex object that provides a predetermined set of
conventions; for instance, UsdLiborSwapIsdaFixAm defines the conventions
for what used to be called the ISDAFIX swap rates.  Given that ISDAFIX has
been discontinued and transitioned to ICE swap rates, though, I'm no longer
sure that the conventions are up to date, so you might be better off using
the other SwapRateHelper constructor and passing the correct conventions
yourself.

Hope this helps,
    Luigi



On Fri, Nov 4, 2022 at 1:13 AM Lydia Anderson <and...@gm...>
wrote:

> Dear Dr. Luigi Ballabio,
>
> I am a new user to QuantLib and I have some basic questions that I'd like
> to ask. I am looking to build a zero-rate curve from observed swap rates --
> could you please explain what does SwapRateHelper do? Is it something
> that handles the date scheduling internally? Also, what is UsdLiborSwapIsdaFixAm
> -- is it an object that specifies the date convention of the USD swap? I
> tried to find resource online that explains this but no success.
>
> Thanks for your time in this 🙂.
>
> Best,
> Lydia
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] QuantLib query

[Lydia A. <and...@gm...>]

Dear Dr. Luigi Ballabio,

I am a new user to QuantLib and I have some basic questions that I'd like
to ask. I am looking to build a zero-rate curve from observed swap rates --
could you please explain what does SwapRateHelper do? Is it something that
handles the date scheduling internally? Also, what is UsdLiborSwapIsdaFixAm
-- is it an object that specifies the date convention of the USD swap? I
tried to find resource online that explains this but no success.

Thanks for your time in this 🙂.

Best,
Lydia

Re: [Quantlib-users] AverageONIndexedCoupon vs OvernightIndexedCoupon in ORE

[Ioannis R. <qua...@de...>]

If you allow me to comment on the type of "relationship" between 
QuantLib and ORE as it has evolved over the years, the crucial time 
point was when it was decided that ORE would be set up as a distinct 
project on a different repository.

The rationale back then was clear and was based on gaining speed of new 
code development unhampered by the legacy constraints of a widely used 
QuantLib.

The present success of ORE has proven that this was a good decision at 
least from the perspective of the initial goals, which were about 
putting together as quickly as possible code capable for pricing 
specific exotics and - mainly - calculating XVA.

On the other hand, it seems to me that the long term cost of that 
decision starts appearing now. In reality, ongoing natural and almost 
inescapable forces point to the direction of a wider separation rather 
than consolidation of the two libraries.

On the long term this trend could prove detrimental for ORE since the 
main pool of open source developers seem to be focusing on QuantLib.

 From my perspective as a user of both libraries, the optimal future 
path would be in the direction where ORE would be brought inside 
QuantLib, but I realize this might be technically way too difficult at 
this point.

Ioannis

On 10/30/2022 9:28 AM, Peter Caspers wrote:
> Well you are still right - QuantLib::OvernightIndexedCoupon does
> support arithmetic averaging (for 2 years now) while we built a
> separate coupon class for this (ages ago). So this is another
> opportunity for consolidation.
> Thank you
> Peter
>
> On Sat, 29 Oct 2022 at 15:58, Ioannis Rigopoulos <qua...@de...> wrote:
>> I am sorry. Please ignore below. The AverageONIndexedCoupon obviously
>> deals with the arithmetic average accrual calculation versus the more
>> common compounding average.
>>
>> On 10/29/2022 3:44 PM, Ioannis Rigopoulos wrote:
>>> Hi Peter,
>>>
>>> I am struggling to understand the reason for introducing the
>>> AverageONIndexedCoupon   given the existence of the ORE version of
>>> OvernightIndexedCoupon which has extended the same named QuantLib
>>> class to deal with rate cutoff, lookback etc.
>>>
>>> As a matter of fact, the OvernightIndexedCoupon had a wider scope as
>>> one can see from its constructor that contains the same parameters as
>>> AverageONIndexedCoupon, but also the additional optional three below:
>>>
>>> refPeriodStart
>>> refPeriodEnd
>>> includeSpread
>>>
>>> The current situation is confusing as some classes link to
>>> AverageONIndexedCoupon  and others to OvernightIndexedCoupon
>>>
>>> Ioannis
>>>
>> --
>> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
>> www.avast.com

-- 
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com

Re: [Quantlib-users] AverageONIndexedCoupon vs OvernightIndexedCoupon in ORE

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

Well you are still right - QuantLib::OvernightIndexedCoupon does
support arithmetic averaging (for 2 years now) while we built a
separate coupon class for this (ages ago). So this is another
opportunity for consolidation.
Thank you
Peter

On Sat, 29 Oct 2022 at 15:58, Ioannis Rigopoulos <qua...@de...> wrote:
>
> I am sorry. Please ignore below. The AverageONIndexedCoupon obviously
> deals with the arithmetic average accrual calculation versus the more
> common compounding average.
>
> On 10/29/2022 3:44 PM, Ioannis Rigopoulos wrote:
> > Hi Peter,
> >
> > I am struggling to understand the reason for introducing the
> > AverageONIndexedCoupon   given the existence of the ORE version of
> > OvernightIndexedCoupon which has extended the same named QuantLib
> > class to deal with rate cutoff, lookback etc.
> >
> > As a matter of fact, the OvernightIndexedCoupon had a wider scope as
> > one can see from its constructor that contains the same parameters as
> > AverageONIndexedCoupon, but also the additional optional three below:
> >
> > refPeriodStart
> > refPeriodEnd
> > includeSpread
> >
> > The current situation is confusing as some classes link to
> > AverageONIndexedCoupon  and others to OvernightIndexedCoupon
> >
> > Ioannis
> >
>
> --
> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
> www.avast.com

Re: [Quantlib-users] AverageONIndexedCoupon vs OvernightIndexedCoupon in ORE

[Ioannis R. <qua...@de...>]

I am sorry. Please ignore below. The AverageONIndexedCoupon obviously 
deals with the arithmetic average accrual calculation versus the more 
common compounding average.

On 10/29/2022 3:44 PM, Ioannis Rigopoulos wrote:
> Hi Peter,
>
> I am struggling to understand the reason for introducing the 
> AverageONIndexedCoupon   given the existence of the ORE version of 
> OvernightIndexedCoupon which has extended the same named QuantLib 
> class to deal with rate cutoff, lookback etc.
>
> As a matter of fact, the OvernightIndexedCoupon had a wider scope as 
> one can see from its constructor that contains the same parameters as 
> AverageONIndexedCoupon, but also the additional optional three below:
>
> refPeriodStart
> refPeriodEnd
> includeSpread
>
> The current situation is confusing as some classes link to 
> AverageONIndexedCoupon  and others to OvernightIndexedCoupon
>
> Ioannis
>

-- 
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com

[Quantlib-users] AverageONIndexedCoupon vs OvernightIndexedCoupon in ORE

[Ioannis R. <qua...@de...>]

Hi Peter,

I am struggling to understand the reason for introducing the 
AverageONIndexedCoupon   given the existence of the ORE version of 
OvernightIndexedCoupon which has extended the same named QuantLib class 
to deal with rate cutoff, lookback etc.

As a matter of fact, the OvernightIndexedCoupon had a wider scope as one 
can see from its constructor that contains the same parameters as 
AverageONIndexedCoupon, but also the additional optional three below:

refPeriodStart
refPeriodEnd
includeSpread

The current situation is confusing as some classes link to 
AverageONIndexedCoupon  and others to OvernightIndexedCoupon

Ioannis


-- 
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com

Re: [Quantlib-users] Wrong interpretation of the lookback period in AverageONIndexedCoupon

[Ioannis R. <qua...@de...>]

Hi Peter,

First of all, thank you for asking me for my opinion on your suggested 
course of action even though I do not currently contribute to the ORE 
code base.

But since you asked, my view is that it would be sensible to at least 
change the parameter name "lookback" to something like "obsLag" or 
"obsShift" in the constructor and also all other instances that pass 
this parameter around so that it is clear to developers what is what.

Now regarding the ORE XML there is the serious issue of backward 
compatibility since the text tokens there interface directly with the 
client apps. The decision is then up to you whether you want to carry 
out the change or not. But even if you keep the XML token as "lookback", 
it should nevertheless map to "obs..." in the c++ interfaces. This would 
enhance code clarity and maintenance.

Ioannis

On 10/28/2022 3:02 PM, Peter Caspers wrote:
> Hi Ioannis
>
> thanks. When we implemented this stuff the terminology was not as
> cut-and-dried as it is today. However it is not easy to change the
> names now since they are linked to the ORE trade XML schema on which
> many of our clients depend. I will update the documentation of the C++
> constructors and the description in the user guide though so that it
> is clear how the parameters map to the ISDA definitions. Does that
> make sense?
>
> Thank you
> Peter
>
> On Thu, 27 Oct 2022 at 19:52, Ioannis Rigopoulos <qua...@de...> wrote:
>> Hi Peter and Roland,
>>
>> Optimally I would have added my correction in the ORE repository rather
>> than sending this email, but I will rather wait until ORE has been
>> brought back to the usual link with QuantLib, which is within your plans
>> away.
>>
>> But I do send this email because I think the lookback feature of OIS is
>> quite important as OIS are ubiquitous these days due to Libor cessation.
>>
>> It is clearly documented in various sites that a lookback period has no
>> effect on the accrual period of the floating leg. It only changes the
>> way the applicable overnight rate is calculated. Documentation examples are:
>>
>> https://www.isda.org/a/alEgE/A40393158-v18.0-ISDA_Memorandum_Compounding-RFRs-under-2006-Definitions.pdf
>>
>> https://www.newyorkfed.org/medialibrary/Microsites/arrc/files/2021/users-guide-to-sofr2021-update.pdf
>>
>> But the AverageONIndexedCoupon constructor has the two lines:
>>
>>           valueStart =
>> overnightIndex->fixingCalendar().advance(valueStart, -lookback, bdc);
>>           valueEnd = overnightIndex->fixingCalendar().advance(valueEnd,
>> -lookback, bdc);
>>
>> that lead to a modification of the accrual period [valueStart  , valueEnd]
>>
>> It turns out that the current ORE implementation treats the formal
>> constructor parameter lookback as if it were what the market understands
>> as "observation shift" or "observation lag". I prefer the "lag" over
>> "shift" because it makes more clear the time direction associated with a
>> positive value.
>>
>> Further on, the above constructor takes an argument called fixingDays,
>> which is treated as if it were what the market understands as "lookback".
>>
>> As you see, technically speaking, this situation is not wrong per se, as
>> the constructor does its job correctly, provided one feeds it with the
>> correctly interpreted input, in the sense that one must supply the
>> "observation lag" market value for the formal lookback parameter and the
>> "lookback" market value for the formal fixingDays parameter.
>>
>> Nevertheless, it would be better if the formal parameter names are
>> changed to reflect their actual meaning in order to avoid unintended
>> wrong usage.
>>
>> regards,
>>
>> Ioannis
>>
>>
>> --
>> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
>> www.avast.com

-- 
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com

Re: [Quantlib-users] Wrong interpretation of the lookback period in AverageONIndexedCoupon

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

The ORE forum would of course be best, but they're at least
QuantLib-adjacent :)


On Fri, Oct 28, 2022 at 3:07 PM Peter Caspers <pca...@gm...>
wrote:

> Oh and Luigi, is it okay that we keep hijacking your list for
> questions on ORE ... :-) ?
>
> On Fri, 28 Oct 2022 at 15:02, Peter Caspers <pca...@gm...>
> wrote:
> >
> > Hi Ioannis
> >
> > thanks. When we implemented this stuff the terminology was not as
> > cut-and-dried as it is today. However it is not easy to change the
> > names now since they are linked to the ORE trade XML schema on which
> > many of our clients depend. I will update the documentation of the C++
> > constructors and the description in the user guide though so that it
> > is clear how the parameters map to the ISDA definitions. Does that
> > make sense?
> >
> > Thank you
> > Peter
> >
> > On Thu, 27 Oct 2022 at 19:52, Ioannis Rigopoulos <qua...@de...>
> wrote:
> > >
> > > Hi Peter and Roland,
> > >
> > > Optimally I would have added my correction in the ORE repository rather
> > > than sending this email, but I will rather wait until ORE has been
> > > brought back to the usual link with QuantLib, which is within your
> plans
> > > away.
> > >
> > > But I do send this email because I think the lookback feature of OIS is
> > > quite important as OIS are ubiquitous these days due to Libor
> cessation.
> > >
> > > It is clearly documented in various sites that a lookback period has no
> > > effect on the accrual period of the floating leg. It only changes the
> > > way the applicable overnight rate is calculated. Documentation
> examples are:
> > >
> > >
> https://www.isda.org/a/alEgE/A40393158-v18.0-ISDA_Memorandum_Compounding-RFRs-under-2006-Definitions.pdf
> > >
> > >
> https://www.newyorkfed.org/medialibrary/Microsites/arrc/files/2021/users-guide-to-sofr2021-update.pdf
> > >
> > > But the AverageONIndexedCoupon constructor has the two lines:
> > >
> > >          valueStart =
> > > overnightIndex->fixingCalendar().advance(valueStart, -lookback, bdc);
> > >          valueEnd = overnightIndex->fixingCalendar().advance(valueEnd,
> > > -lookback, bdc);
> > >
> > > that lead to a modification of the accrual period [valueStart  ,
> valueEnd]
> > >
> > > It turns out that the current ORE implementation treats the formal
> > > constructor parameter lookback as if it were what the market
> understands
> > > as "observation shift" or "observation lag". I prefer the "lag" over
> > > "shift" because it makes more clear the time direction associated with
> a
> > > positive value.
> > >
> > > Further on, the above constructor takes an argument called fixingDays,
> > > which is treated as if it were what the market understands as
> "lookback".
> > >
> > > As you see, technically speaking, this situation is not wrong per se,
> as
> > > the constructor does its job correctly, provided one feeds it with the
> > > correctly interpreted input, in the sense that one must supply the
> > > "observation lag" market value for the formal lookback parameter and
> the
> > > "lookback" market value for the formal fixingDays parameter.
> > >
> > > Nevertheless, it would be better if the formal parameter names are
> > > changed to reflect their actual meaning in order to avoid unintended
> > > wrong usage.
> > >
> > > regards,
> > >
> > > Ioannis
> > >
> > >
> > > --
> > > Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
> > > www.avast.com
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] Wrong interpretation of the lookback period in AverageONIndexedCoupon

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

Oh and Luigi, is it okay that we keep hijacking your list for
questions on ORE ... :-) ?

On Fri, 28 Oct 2022 at 15:02, Peter Caspers <pca...@gm...> wrote:
>
> Hi Ioannis
>
> thanks. When we implemented this stuff the terminology was not as
> cut-and-dried as it is today. However it is not easy to change the
> names now since they are linked to the ORE trade XML schema on which
> many of our clients depend. I will update the documentation of the C++
> constructors and the description in the user guide though so that it
> is clear how the parameters map to the ISDA definitions. Does that
> make sense?
>
> Thank you
> Peter
>
> On Thu, 27 Oct 2022 at 19:52, Ioannis Rigopoulos <qua...@de...> wrote:
> >
> > Hi Peter and Roland,
> >
> > Optimally I would have added my correction in the ORE repository rather
> > than sending this email, but I will rather wait until ORE has been
> > brought back to the usual link with QuantLib, which is within your plans
> > away.
> >
> > But I do send this email because I think the lookback feature of OIS is
> > quite important as OIS are ubiquitous these days due to Libor cessation.
> >
> > It is clearly documented in various sites that a lookback period has no
> > effect on the accrual period of the floating leg. It only changes the
> > way the applicable overnight rate is calculated. Documentation examples are:
> >
> > https://www.isda.org/a/alEgE/A40393158-v18.0-ISDA_Memorandum_Compounding-RFRs-under-2006-Definitions.pdf
> >
> > https://www.newyorkfed.org/medialibrary/Microsites/arrc/files/2021/users-guide-to-sofr2021-update.pdf
> >
> > But the AverageONIndexedCoupon constructor has the two lines:
> >
> >          valueStart =
> > overnightIndex->fixingCalendar().advance(valueStart, -lookback, bdc);
> >          valueEnd = overnightIndex->fixingCalendar().advance(valueEnd,
> > -lookback, bdc);
> >
> > that lead to a modification of the accrual period [valueStart  , valueEnd]
> >
> > It turns out that the current ORE implementation treats the formal
> > constructor parameter lookback as if it were what the market understands
> > as "observation shift" or "observation lag". I prefer the "lag" over
> > "shift" because it makes more clear the time direction associated with a
> > positive value.
> >
> > Further on, the above constructor takes an argument called fixingDays,
> > which is treated as if it were what the market understands as "lookback".
> >
> > As you see, technically speaking, this situation is not wrong per se, as
> > the constructor does its job correctly, provided one feeds it with the
> > correctly interpreted input, in the sense that one must supply the
> > "observation lag" market value for the formal lookback parameter and the
> > "lookback" market value for the formal fixingDays parameter.
> >
> > Nevertheless, it would be better if the formal parameter names are
> > changed to reflect their actual meaning in order to avoid unintended
> > wrong usage.
> >
> > regards,
> >
> > Ioannis
> >
> >
> > --
> > Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
> > www.avast.com

Re: [Quantlib-users] Wrong interpretation of the lookback period in AverageONIndexedCoupon

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

Hi Ioannis

thanks. When we implemented this stuff the terminology was not as
cut-and-dried as it is today. However it is not easy to change the
names now since they are linked to the ORE trade XML schema on which
many of our clients depend. I will update the documentation of the C++
constructors and the description in the user guide though so that it
is clear how the parameters map to the ISDA definitions. Does that
make sense?

Thank you
Peter

On Thu, 27 Oct 2022 at 19:52, Ioannis Rigopoulos <qua...@de...> wrote:
>
> Hi Peter and Roland,
>
> Optimally I would have added my correction in the ORE repository rather
> than sending this email, but I will rather wait until ORE has been
> brought back to the usual link with QuantLib, which is within your plans
> away.
>
> But I do send this email because I think the lookback feature of OIS is
> quite important as OIS are ubiquitous these days due to Libor cessation.
>
> It is clearly documented in various sites that a lookback period has no
> effect on the accrual period of the floating leg. It only changes the
> way the applicable overnight rate is calculated. Documentation examples are:
>
> https://www.isda.org/a/alEgE/A40393158-v18.0-ISDA_Memorandum_Compounding-RFRs-under-2006-Definitions.pdf
>
> https://www.newyorkfed.org/medialibrary/Microsites/arrc/files/2021/users-guide-to-sofr2021-update.pdf
>
> But the AverageONIndexedCoupon constructor has the two lines:
>
>          valueStart =
> overnightIndex->fixingCalendar().advance(valueStart, -lookback, bdc);
>          valueEnd = overnightIndex->fixingCalendar().advance(valueEnd,
> -lookback, bdc);
>
> that lead to a modification of the accrual period [valueStart  , valueEnd]
>
> It turns out that the current ORE implementation treats the formal
> constructor parameter lookback as if it were what the market understands
> as "observation shift" or "observation lag". I prefer the "lag" over
> "shift" because it makes more clear the time direction associated with a
> positive value.
>
> Further on, the above constructor takes an argument called fixingDays,
> which is treated as if it were what the market understands as "lookback".
>
> As you see, technically speaking, this situation is not wrong per se, as
> the constructor does its job correctly, provided one feeds it with the
> correctly interpreted input, in the sense that one must supply the
> "observation lag" market value for the formal lookback parameter and the
> "lookback" market value for the formal fixingDays parameter.
>
> Nevertheless, it would be better if the formal parameter names are
> changed to reflect their actual meaning in order to avoid unintended
> wrong usage.
>
> regards,
>
> Ioannis
>
>
> --
> Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
> www.avast.com

[Quantlib-users] Wrong interpretation of the lookback period in AverageONIndexedCoupon

[Ioannis R. <qua...@de...>]

Hi Peter and Roland,

Optimally I would have added my correction in the ORE repository rather 
than sending this email, but I will rather wait until ORE has been 
brought back to the usual link with QuantLib, which is within your plans 
away.

But I do send this email because I think the lookback feature of OIS is 
quite important as OIS are ubiquitous these days due to Libor cessation.

It is clearly documented in various sites that a lookback period has no 
effect on the accrual period of the floating leg. It only changes the 
way the applicable overnight rate is calculated. Documentation examples are:

https://www.isda.org/a/alEgE/A40393158-v18.0-ISDA_Memorandum_Compounding-RFRs-under-2006-Definitions.pdf

https://www.newyorkfed.org/medialibrary/Microsites/arrc/files/2021/users-guide-to-sofr2021-update.pdf

But the AverageONIndexedCoupon constructor has the two lines:

         valueStart = 
overnightIndex->fixingCalendar().advance(valueStart, -lookback, bdc);
         valueEnd = overnightIndex->fixingCalendar().advance(valueEnd, 
-lookback, bdc);

that lead to a modification of the accrual period [valueStart  , valueEnd]

It turns out that the current ORE implementation treats the formal 
constructor parameter lookback as if it were what the market understands 
as "observation shift" or "observation lag". I prefer the "lag" over 
"shift" because it makes more clear the time direction associated with a 
positive value.

Further on, the above constructor takes an argument called fixingDays, 
which is treated as if it were what the market understands as "lookback".

As you see, technically speaking, this situation is not wrong per se, as 
the constructor does its job correctly, provided one feeds it with the 
correctly interpreted input, in the sense that one must supply the 
"observation lag" market value for the formal lookback parameter and the 
"lookback" market value for the formal fixingDays parameter.

Nevertheless, it would be better if the formal parameter names are 
changed to reflect their actual meaning in order to avoid unintended 
wrong usage.

regards,

Ioannis


-- 
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com

Re: [Quantlib-users] Release candidate for 1.28

[Roland L. <rol...@ac...>]

Hi Ioannis,

Yes, our aim is consolidating the changes in ORE’s QuantLib fork into QuantLib, so that ORE builds with QuantLib releases again.
On the other hand, we need to make sure that ORE and its extensions satisfy performance constraints which have motivated some of Peter’s deeper changes.
So we may have to live with the current situation for now (the next ORE release end of year will be based on a QuantLib 1.28 fork again), but we are making an effort to reduce the discrepancy with 1.29 onwards.

Best regards,
Roland

From: Ioannis Rigopoulos <qua...@de...>
Date: Wednesday, 26 October 2022 at 17:49
To: qua...@li... <qua...@li...>
Subject: Re: [Quantlib-users] Release candidate for 1.28
CAUTION: External email warning. This email originated from outside acadia.inc. Beware of phishing attempts. Comply with all acadia.inc policy to confirm sender identity before responding, forwarding, and especially clicking links or opening attachments.


Is there anyone affiliated with ORE or Acadia who could perhaps answer the question below?
On 10/18/2022 7:08 PM, Ioannis Rigopoulos wrote:

Hi Roland,

One little question that I think is of interest to all ORE users:

Is it within your plans to move in a direction where future ORE releases will relate to QuantLib in a fashion similar to that prevailing until ORE release 6, in the sense that the referenced QuantLib code will be identical with a given (not forked) official QuantLib release?

Thank you.

Ioannis
On 10/17/2022 9:41 AM, Roland Lichters via QuantLib-users wrote:
Hi Luigi,
this works for ORE with some amendments because of the breaking change in ql/experimental.
We are aiming at upgrading ORE on github soon after QL and QL SWIG is out, within a month.
Regards,
Roland

From: Luigi Ballabio <lui...@gm...><mailto:lui...@gm...>
Date: Tuesday, 11 October 2022 at 19:02
To: QuantLib users <qua...@li...><mailto:qua...@li...>
Subject: Re: [Quantlib-users] Release candidate for 1.28
CAUTION: External email warning. This email originated from outside acadia.inc. Beware of phishing attempts. Comply with all acadia.inc policy to confirm sender identity before responding, forwarding, and especially clicking links or opening attachments.

Ok, the ones now at <https://github.com/lballabio/QuantLib/releases/tag/1.28-rc<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flballabio%2FQuantLib%2Freleases%2Ftag%2F1.28-rc&data=05%7C01%7Croland.lichters%40acadia.inc%7C2ed85f91eb1d4b1a648508dab769acdf%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638023961774375413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Fx5cii26qykBnosZCaP9YL6c4eoV6gadhRPhfrdE0UQ%3D&reserved=0>> should be viable.  Thanks!

Luigi


On Tue, Oct 11, 2022 at 1:50 PM Luigi Ballabio <lui...@gm...<mailto:lui...@gm...>> wrote:
Please belay that — I discovered a problem with some non-standard configurations right after I posted.  I'll update the RC shortly.

Luigi


On Tue, Oct 11, 2022 at 11:53 AM Luigi Ballabio <lui...@gm...<mailto:lui...@gm...>> wrote:
Hello everybody,
    I just published a RC for version 1.28 at <https://github.com/lballabio/QuantLib/releases/tag/1.28-rc<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flballabio%2FQuantLib%2Freleases%2Ftag%2F1.28-rc&data=05%7C01%7Croland.lichters%40acadia.inc%7C2ed85f91eb1d4b1a648508dab769acdf%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638023961774375413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Fx5cii26qykBnosZCaP9YL6c4eoV6gadhRPhfrdE0UQ%3D&reserved=0>>.  If you have some time, please give it a spin and report any problems here on the mailing list.  Thanks!

Luigi


The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not the intended recipient please return the e-mail to the sender and delete it from your computer. The acadia.inc privacy policy is available on our website.



_______________________________________________

QuantLib-users mailing list

Qua...@li...<mailto:Qua...@li...>

https://lists.sourceforge.net/lists/listinfo/quantlib-users<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fquantlib-users&data=05%7C01%7Croland.lichters%40acadia.inc%7C2ed85f91eb1d4b1a648508dab769acdf%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638023961774375413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bMiiAtjOSv4KRhIfyssOHz9Ep7aRfi%2FsW2MT%2Bd5KqbI%3D&reserved=0>

[https://s-install.avcdn.net/ipm/preview/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Demailclient&data=05%7C01%7Croland.lichters%40acadia.inc%7C2ed85f91eb1d4b1a648508dab769acdf%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638023961774375413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ecPurlEGdY4wjmir%2BOyJ3fyF6kg%2ByLb7%2Fm0joMhmOkk%3D&reserved=0>
Virenfrei.www.avast.com<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Demailclient&data=05%7C01%7Croland.lichters%40acadia.inc%7C2ed85f91eb1d4b1a648508dab769acdf%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638023961774375413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ecPurlEGdY4wjmir%2BOyJ3fyF6kg%2ByLb7%2Fm0joMhmOkk%3D&reserved=0>




_______________________________________________

QuantLib-users mailing list

Qua...@li...<mailto:Qua...@li...>

https://lists.sourceforge.net/lists/listinfo/quantlib-users<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fquantlib-users&data=05%7C01%7Croland.lichters%40acadia.inc%7C2ed85f91eb1d4b1a648508dab769acdf%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638023961774375413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bMiiAtjOSv4KRhIfyssOHz9Ep7aRfi%2FsW2MT%2Bd5KqbI%3D&reserved=0>

The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not the intended recipient please return the e-mail to the sender and delete it from your computer. The acadia.inc privacy policy is available on our website.

Re: [Quantlib-users] Release candidate for 1.28

[Ioannis R. <qua...@de...>]

Thank you Roland for this important piece of information. It is nice to 
know that the current situation is temporary.

On 10/26/2022 9:16 PM, Roland Lichters wrote:
>
> Hi Ioannis,
>
> Yes, our aim is consolidating the changes in ORE’s QuantLib fork into 
> QuantLib, so that ORE builds with QuantLib releases again.
>
> On the other hand, we need to make sure that ORE and its extensions 
> satisfy performance constraints which have motivated some of Peter’s 
> deeper changes.
>
> So we may have to live with the current situation for now (the next 
> ORE release end of year will be based on a QuantLib 1.28 fork again), 
> but we are making an effort to reduce the discrepancy with 1.29 onwards.
>
> Best regards,
>
> Roland
>
> *From: *Ioannis Rigopoulos <qua...@de...>
> *Date: *Wednesday, 26 October 2022 at 17:49
> *To: *qua...@li... 
> <qua...@li...>
> *Subject: *Re: [Quantlib-users] Release candidate for 1.28
>
> CAUTION:External email warning. This email originated from outside 
> acadia.inc. Beware of phishing attempts. Comply with all acadia.inc 
> policy to confirm sender identity before responding, forwarding, and 
> especially clicking links or opening attachments.
>
> Is there anyone affiliated with ORE or Acadia who could perhaps answer 
> the question below?
>
> On 10/18/2022 7:08 PM, Ioannis Rigopoulos wrote:
>
>     Hi Roland,
>
>     One little question that I think is of interest to all ORE users:
>
>     Is it within your plans to move in a direction where future ORE
>     releases will relate to QuantLib in a fashion similar to that
>     prevailing until ORE release 6, in the sense that the referenced
>     QuantLib code will be identical with a given (not forked) official
>     QuantLib release?
>
>     Thank you.
>
>     Ioannis
>
>     On 10/17/2022 9:41 AM, Roland Lichters via QuantLib-users wrote:
>
>         Hi Luigi,
>
>         this works for ORE with some amendments because of the
>         breaking change in ql/experimental.
>
>         We are aiming at upgrading ORE on github soon after QL and QL
>         SWIG is out, within a month.
>
>         Regards,
>
>         Roland
>
>         *From: *Luigi Ballabio <lui...@gm...>
>         <mailto:lui...@gm...>
>         *Date: *Tuesday, 11 October 2022 at 19:02
>         *To: *QuantLib users <qua...@li...>
>         <mailto:qua...@li...>
>         *Subject: *Re: [Quantlib-users] Release candidate for 1.28
>
>         CAUTION:External email warning. This email originated from
>         outside acadia.inc. Beware of phishing attempts. Comply with
>         all acadia.inc policy to confirm sender identity before
>         responding, forwarding, and especially clicking links or
>         opening attachments.
>
>         Ok, the ones now at
>         <https://github.com/lballabio/QuantLib/releases/tag/1.28-rc
>         <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flballabio%2FQuantLib%2Freleases%2Ftag%2F1.28-rc&data=05%7C01%7Croland.lichters%40acadia.inc%7C2ed85f91eb1d4b1a648508dab769acdf%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638023961774375413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Fx5cii26qykBnosZCaP9YL6c4eoV6gadhRPhfrdE0UQ%3D&reserved=0>>
>         should be viable.  Thanks!
>
>         Luigi
>
>         On Tue, Oct 11, 2022 at 1:50 PM Luigi Ballabio
>         <lui...@gm...> wrote:
>
>             Please belay that — I discovered a problem with some
>             non-standard configurations right after I posted.  I'll
>             update the RC shortly.
>
>             Luigi
>
>             On Tue, Oct 11, 2022 at 11:53 AM Luigi Ballabio
>             <lui...@gm...> wrote:
>
>                 Hello everybody,
>
>                     I just published a RC for version 1.28 at
>                 <https://github.com/lballabio/QuantLib/releases/tag/1.28-rc
>                 <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flballabio%2FQuantLib%2Freleases%2Ftag%2F1.28-rc&data=05%7C01%7Croland.lichters%40acadia.inc%7C2ed85f91eb1d4b1a648508dab769acdf%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638023961774375413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Fx5cii26qykBnosZCaP9YL6c4eoV6gadhRPhfrdE0UQ%3D&reserved=0>>.
>                 If you have some time, please give it a spin and
>                 report any problems here on the mailing list.  Thanks!
>
>                 Luigi
>
>
>         /The information contained in this e-mail, and any attachment,
>         is confidential and is intended solely for the use of the
>         intended recipient. Access, copying or re-use of the e-mail or
>         any attachment, or any information contained therein, by any
>         other person is not authorized. If you are not the intended
>         recipient please return the e-mail to the sender and delete it
>         from your computer. The acadia.inc privacy policy is available
>         on our website. /
>
>
>         _______________________________________________
>
>         QuantLib-users mailing list
>
>         Qua...@li...
>
>         https://lists.sourceforge.net/lists/listinfo/quantlib-users  <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fquantlib-users&data=05%7C01%7Croland.lichters%40acadia.inc%7C2ed85f91eb1d4b1a648508dab769acdf%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638023961774375413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bMiiAtjOSv4KRhIfyssOHz9Ep7aRfi%2FsW2MT%2Bd5KqbI%3D&reserved=0>
>
>     <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Demailclient&data=05%7C01%7Croland.lichters%40acadia.inc%7C2ed85f91eb1d4b1a648508dab769acdf%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638023961774375413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ecPurlEGdY4wjmir%2BOyJ3fyF6kg%2ByLb7%2Fm0joMhmOkk%3D&reserved=0>
>
>     	
>
>     Virenfrei.www.avast.com
>     <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.avast.com%2Fsig-email%3Futm_medium%3Demail%26utm_source%3Dlink%26utm_campaign%3Dsig-email%26utm_content%3Demailclient&data=05%7C01%7Croland.lichters%40acadia.inc%7C2ed85f91eb1d4b1a648508dab769acdf%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638023961774375413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ecPurlEGdY4wjmir%2BOyJ3fyF6kg%2ByLb7%2Fm0joMhmOkk%3D&reserved=0>
>
>
>
>
>     _______________________________________________
>
>     QuantLib-users mailing list
>
>     Qua...@li...
>
>     https://lists.sourceforge.net/lists/listinfo/quantlib-users  <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fquantlib-users&data=05%7C01%7Croland.lichters%40acadia.inc%7C2ed85f91eb1d4b1a648508dab769acdf%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638023961774375413%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bMiiAtjOSv4KRhIfyssOHz9Ep7aRfi%2FsW2MT%2Bd5KqbI%3D&reserved=0>
>
>
> The information contained in this e-mail, and any attachment, is 
> confidential and is intended solely for the use of the intended 
> recipient. Access, copying or re-use of the e-mail or any attachment, 
> or any information contained therein, by any other person is not 
> authorized. If you are not the intended recipient please return the 
> e-mail to the sender and delete it from your computer. The acadia.inc 
> privacy policy is available on our website. 

-- 
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com

Re: [Quantlib-users] Release candidate for 1.28

[Ioannis R. <qua...@de...>]

Is there anyone affiliated with ORE or Acadia who could perhaps answer 
the question below?

On 10/18/2022 7:08 PM, Ioannis Rigopoulos wrote:
>
> Hi Roland,
>
> One little question that I think is of interest to all ORE users:
>
> Is it within your plans to move in a direction where future ORE 
> releases will relate to QuantLib in a fashion similar to that 
> prevailing until ORE release 6, in the sense that the referenced 
> QuantLib code will be identical with a given (not forked) official 
> QuantLib release?
>
> Thank you.
>
> Ioannis
>
> On 10/17/2022 9:41 AM, Roland Lichters via QuantLib-users wrote:
>>
>> Hi Luigi,
>>
>> this works for ORE with some amendments because of the breaking 
>> change in ql/experimental.
>>
>> We are aiming at upgrading ORE on github soon after QL and QL SWIG is 
>> out, within a month.
>>
>> Regards,
>>
>> Roland
>>
>> *From: *Luigi Ballabio <lui...@gm...>
>> *Date: *Tuesday, 11 October 2022 at 19:02
>> *To: *QuantLib users <qua...@li...>
>> *Subject: *Re: [Quantlib-users] Release candidate for 1.28
>>
>> CAUTION:External email warning. This email originated from outside 
>> acadia.inc. Beware of phishing attempts. Comply with all acadia.inc 
>> policy to confirm sender identity before responding, forwarding, and 
>> especially clicking links or opening attachments.
>>
>> Ok, the ones now at 
>> <https://github.com/lballabio/QuantLib/releases/tag/1.28-rc 
>> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flballabio%2FQuantLib%2Freleases%2Ftag%2F1.28-rc&data=05%7C01%7Croland.lichters%40acadia.inc%7Cf9de3dbd507d487f0ca108daabaa5421%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638011045315869694%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hr0VEJ3yWjpPIOa9Hk30sAzcmaQ%2FW0tsOcJ05G5LvtM%3D&reserved=0>> 
>> should be viable.  Thanks!
>>
>> Luigi
>>
>> On Tue, Oct 11, 2022 at 1:50 PM Luigi Ballabio 
>> <lui...@gm...> wrote:
>>
>>     Please belay that — I discovered a problem with some non-standard
>>     configurations right after I posted. I'll update the RC shortly.
>>
>>     Luigi
>>
>>     On Tue, Oct 11, 2022 at 11:53 AM Luigi Ballabio
>>     <lui...@gm...> wrote:
>>
>>         Hello everybody,
>>
>>             I just published a RC for version 1.28 at
>>         <https://github.com/lballabio/QuantLib/releases/tag/1.28-rc
>>         <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flballabio%2FQuantLib%2Freleases%2Ftag%2F1.28-rc&data=05%7C01%7Croland.lichters%40acadia.inc%7Cf9de3dbd507d487f0ca108daabaa5421%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638011045315869694%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hr0VEJ3yWjpPIOa9Hk30sAzcmaQ%2FW0tsOcJ05G5LvtM%3D&reserved=0>>.
>>         If you have some time, please give it a spin and report any
>>         problems here on the mailing list.  Thanks!
>>
>>         Luigi
>>
>>
>> The information contained in this e-mail, and any attachment, is 
>> confidential and is intended solely for the use of the intended 
>> recipient. Access, copying or re-use of the e-mail or any attachment, 
>> or any information contained therein, by any other person is not 
>> authorized. If you are not the intended recipient please return the 
>> e-mail to the sender and delete it from your computer. The acadia.inc 
>> privacy policy is available on our website.
>>
>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
> 	Virenfrei.www.avast.com 
> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> 
>
>
> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

-- 
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com

[Quantlib-users] QuantLib 1.28 released

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

QuantLib 1.28 has been released and is available for download at <
https://www.quantlib.org/download.shtml>.

The list of changes for this release is at <
https://www.quantlib.org/reference/history.html>.

Please report any problems you have with this release to the QuantLib
mailing list (<qua...@li...>), or open a GitHub
issue at <https://github.com/lballabio/quantlib/issues>.

Re: [Quantlib-users] SOFR index runtime Error

[Mark <gr...@gm...>]

Thank you Peter for your tip!

On Sun, Oct 16, 2022 at 3:26 AM Peter Caspers <pca...@gm...>
wrote:

> I'd use a tenor matching the coupon frequency of your swaption, e.g.
> Euribor3M if the SOFR payments are quarterly in the swap underlying
> the swaption. You can also attach a SOFR forecasting curve to the
> Euribor3M index. I guess that would in fact be a quite good
> approximation of a SOFR swaption, whether it references term SOFR or
> overnight SOFR.
> Thank you
> Peter
>
> On Sun, 16 Oct 2022 at 04:42, Mark <gr...@gm...> wrote:
> >
> > Jonathan and Peter,
> >
> > Thank you for your response. If I used Euribo as a proxy to SOFR for
> swaption calculation, will Euribo1m a better choice than Euribo6m?
> >
> > Thanks,
> > Mark
> >
> > On Sat, Oct 15, 2022 at 11:58 AM Peter Caspers <pca...@gm...>
> wrote:
> >>
> >> Just to add to what Jonathan said: QuantLib does not model SOFR
> >> swaptions correctly at the moment, so even if the technical issue is
> >> resolved you'll not get an accurate valuation.
> >> Best, Peter
> >>
> >> On Sat, 15 Oct 2022 at 11:23, Jonathan Sweemer <sw...@gm...>
> wrote:
> >> >
> >> > Hi Mark,
> >> >
> >> > You can find the source of the error message here:
> https://github.com/lballabio/QuantLib/blob/master/ql/processes/gsrprocess.cpp#L92-L93
> >> >
> >> > Looks like your Sofr term structure somehow contains a forward from
> 0.915068 to 0.912329, which of course is not allowed, but it's a bit hard
> to know why without seeing the rest of your code.
> >> >
> >> >
> >> > On Sat, Oct 15, 2022 at 11:58 AM Mark <gr...@gm...> wrote:
> >> >>
> >> >> Hi,
> >> >>
> >> >> If I used index=Euribor6M(termstructure) as the yield curve I can
> calculate European swaption through GSR model, but once I changed the index
> to index=Sofr(termstructure), I will get below error:
> >> >>
> >> >> atmSwaption.NPV()
> >> >> Return _QuantLib.Intrument_NPV(self)
> >> >> RuntimeError:  G(t,w) should be called with w (0.912329) not lesser
> than t(0.915068)
> >> >>
> >> >> Does anyone know what this error message means?
> >> >>
> >> >> Thanks,
> >> >> Mark
> >> >> _______________________________________________
> >> >> 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] Release candidate for 1.28

[Ioannis R. <qua...@de...>]

Hi Roland,

One little question that I think is of interest to all ORE users:

Is it within your plans to move in a direction where future ORE releases 
will relate to QuantLib in a fashion similar to that prevailing until 
ORE release 6, in the sense that the referenced QuantLib code will be 
identical with a given (not forked) official QuantLib release?

Thank you.

Ioannis

On 10/17/2022 9:41 AM, Roland Lichters via QuantLib-users wrote:
>
> Hi Luigi,
>
> this works for ORE with some amendments because of the breaking change 
> in ql/experimental.
>
> We are aiming at upgrading ORE on github soon after QL and QL SWIG is 
> out, within a month.
>
> Regards,
>
> Roland
>
> *From: *Luigi Ballabio <lui...@gm...>
> *Date: *Tuesday, 11 October 2022 at 19:02
> *To: *QuantLib users <qua...@li...>
> *Subject: *Re: [Quantlib-users] Release candidate for 1.28
>
> CAUTION:External email warning. This email originated from outside 
> acadia.inc. Beware of phishing attempts. Comply with all acadia.inc 
> policy to confirm sender identity before responding, forwarding, and 
> especially clicking links or opening attachments.
>
> Ok, the ones now at 
> <https://github.com/lballabio/QuantLib/releases/tag/1.28-rc 
> <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flballabio%2FQuantLib%2Freleases%2Ftag%2F1.28-rc&data=05%7C01%7Croland.lichters%40acadia.inc%7Cf9de3dbd507d487f0ca108daabaa5421%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638011045315869694%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hr0VEJ3yWjpPIOa9Hk30sAzcmaQ%2FW0tsOcJ05G5LvtM%3D&reserved=0>> 
> should be viable.  Thanks!
>
> Luigi
>
> On Tue, Oct 11, 2022 at 1:50 PM Luigi Ballabio 
> <lui...@gm...> wrote:
>
>     Please belay that — I discovered a problem with some non-standard
>     configurations right after I posted. I'll update the RC shortly.
>
>     Luigi
>
>     On Tue, Oct 11, 2022 at 11:53 AM Luigi Ballabio
>     <lui...@gm...> wrote:
>
>         Hello everybody,
>
>             I just published a RC for version 1.28 at
>         <https://github.com/lballabio/QuantLib/releases/tag/1.28-rc
>         <https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flballabio%2FQuantLib%2Freleases%2Ftag%2F1.28-rc&data=05%7C01%7Croland.lichters%40acadia.inc%7Cf9de3dbd507d487f0ca108daabaa5421%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638011045315869694%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hr0VEJ3yWjpPIOa9Hk30sAzcmaQ%2FW0tsOcJ05G5LvtM%3D&reserved=0>>.
>         If you have some time, please give it a spin and report any
>         problems here on the mailing list.  Thanks!
>
>         Luigi
>
>
> The information contained in this e-mail, and any attachment, is 
> confidential and is intended solely for the use of the intended 
> recipient. Access, copying or re-use of the e-mail or any attachment, 
> or any information contained therein, by any other person is not 
> authorized. If you are not the intended recipient please return the 
> e-mail to the sender and delete it from your computer. The acadia.inc 
> privacy policy is available on our website.
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

-- 
Diese E-Mail wurde von Avast-Antivirussoftware auf Viren geprüft.
www.avast.com

Re: [Quantlib-users] Getting different theta when using BlackVarianceSurface and constant Vol

[Jonathan S. <sw...@gm...>]

I'm not sure what your use case is, but again I would stress that "proper"
thetas for short-dated options should probably not rely on Black-Scholes
pricing assumptions. You can look for articles on modeling short-dated SPX
skew to get some ideas for a better approach.

If you must use a constant vol surface with American options, then you
might also want to check out BaroneAdesiWhaleyApproximationEngine, but be
aware that it only provides theta for call options
<https://github.com/lballabio/QuantLib/blob/master/ql/pricingengines/vanilla/baroneadesiwhaleyengine.cpp#L185>,
not for put options, and it only works with VanillaOption, not
DividendVanillaOption (which should be fine for you since you use a
continuous dividend yield).

On Mon, Oct 17, 2022 at 11:13 PM Dan VolPM <dan...@gm...> wrote:

> Thank you Jonathan.
> My example was on SPX to make it easier to read but I do need the
> FdBlackScholesVanillaEngine for american options on dividend paying single
> stocks and I want to make sure that the convergence between american and
> european remains pure hence the checking.
> Otherwise for SPX, you are correct that analytic is cleaner and faster. In
> fact we even use the regular analytic engine without dividend and instead
> we "yieldify" the dividends to pass them in the process instead which makes
> it even faster.
>
> In any case it would be great to get proper thetas on single stocks
> american options and it looks like it's not possible at the moment.
>
> On Sat, Oct 15, 2022 at 8:02 AM Jonathan Sweemer <sw...@gm...>
> wrote:
>
>> Looks like it's due to some numerical error in
>> the FdBlackScholesVanillaEngine. If I replace FdBlackScholesVanillaEngine
>> with AnalyticDividendEuropeanEngine in your code then I get 0.37 as the
>> breakeven vol for both the constant vol case as well as the vol surface
>> case as expected.
>>
>> Is there any reason that you need to use the FdBlackScholesVanillaEngine?
>> If not then I suppose you can use the AnalyticDividendEuropeanEngine
>> instead. But if your question is what is causing the numerical error in the
>> FdBlackScholesVanillaEngine then that will require more debugging.
>>
>> I'm sure you know already, but a constant vol surface is not suitable for
>> real-world pricing, especially for short maturities where the skew in SPX
>> is most extreme. You'll want to try out other pricing engines to obtain
>> meaningful results on real-world data.
>>
>>
>> On Tue, Oct 11, 2022 at 11:31 PM Dan VolPM <dan...@gm...> wrote:
>>
>>> Hi,
>>>
>>> I am running into an issue where quantlib outputs different thetas
>>> whether i price with a blackvariancesurface or with the constant vol
>>> extracted from the surface.
>>>
>>> I have a vol surface from the market on the SPX index. Not all
>>> strikes/maturities are populated. In addition, there could potentially be
>>> arbitrages in short maturities since we have lots of daily options and I am
>>> not correcting yet for arbitrages.
>>>
>>> Yet when building a BlackVarianceSurface with this data and price a
>>> vanilla option, I expect that option to be priced with a constant vol
>>> interpolated from the grid.
>>>
>>> When I pass the surface object to the pricer I am getting a very
>>> different theta (and therefore breakeven vol) from simply passing the
>>> constant vol taken from the surface.
>>>
>>> Could you help me understand exactly how QLIB handles the surface and
>>> how is theta computed ?
>>>
>>> Thank you very very much.
>>>
>>> Here's some sample code that compares a constant vol with a surface vol
>>> pricing. Notice how the theta changes between the 2 cases leading to a very
>>> different break even vol.
>>>
>>>
>>> import pandas as pd, QuantLib as ql, math, numpy as npfrom datetime import datetime
>>>
>>>
>>> def from_YYYYMMDD_to_ql_date(ymd):
>>>     ymd = int(ymd)
>>>     year = math.floor(ymd / 10000)
>>>     month = int(ymd / 100) % 100
>>>     day = ymd % 100
>>>
>>>     ql_date = ql.Date(day, month, year)
>>>     return ql_date
>>>
>>>
>>> def run_test():
>>>
>>>     ####################################################################
>>>     ####            Global Variables
>>>     ####################################################################
>>>     pricing_date = datetime.strptime('20220916', '%Y%m%d')
>>>     ql_pricing_date = ql.Date(16, 9, 2022)
>>>     calendar = ql.UnitedStates(ql.UnitedStates.Settlement)
>>>     day_counter = ql.ActualActual()
>>>     spot = 3876.00
>>>     spot_handle = ql.QuoteHandle(ql.SimpleQuote(spot))
>>>     flat_ts = ql.YieldTermStructureHandle(ql.FlatForward(ql_pricing_date, 0, day_counter))
>>>     dividend_yield = ql.YieldTermStructureHandle(ql.FlatForward(ql_pricing_date, 0, day_counter))
>>>     K = 3800
>>>     ql_date_expiry = ql.Date(16, 12, 2022)
>>>     exercise = ql.EuropeanExercise(ql_date_expiry)
>>>     payoff = ql.PlainVanillaPayoff(ql.Option.Put, strike=K)
>>>
>>>
>>>     ####################################################################
>>>     ####            Build Vol surface
>>>     ####################################################################
>>>     list_opts = []
>>>     expirations = [datetime.strptime('20220921', '%Y%m%d'), datetime.strptime('20221118', '%Y%m%d'), datetime.strptime('20221216', '%Y%m%d'), ]
>>>     list_opts.append([pricing_date, expirations[0], 3800., 45.])
>>>     list_opts.append([pricing_date, expirations[0], 3900., 40.])
>>>
>>>     list_opts.append([pricing_date, expirations[1], 3800., 27.])
>>>     list_opts.append([pricing_date, expirations[1], 3900., 25.])
>>>
>>>     list_opts.append([pricing_date, expirations[2], 3800., 37.])
>>>     list_opts.append([pricing_date, expirations[2], 3900., 31.])
>>>
>>>     df = pd.DataFrame(list_opts, columns=['date', 'maturity', 'strike', 'vol'])
>>>
>>>     df['ymd'] = df['maturity'].dt.strftime('%Y%m%d')
>>>     df['q_exp_dates'] = df['ymd'].apply(from_YYYYMMDD_to_ql_date)
>>>
>>>     strikes = sorted(df.strike.unique())
>>>     expirations = sorted(df['q_exp_dates'].unique())
>>>
>>>     df['strike_idx'] = df['strike'].apply(lambda x: strikes.index(x))
>>>     df['expiry_idx'] = df['q_exp_dates'].apply(lambda x: expirations.index(x))
>>>
>>>     volMat_np = np.full((len(strikes), len(expirations)), np.nan)
>>>
>>>     for strk, exp, vol in zip(df['strike_idx'], df['expiry_idx'], df['vol']):
>>>         volMat_np[strk][exp] = vol / 100
>>>
>>>     df_vals = pd.DataFrame(volMat_np, index=strikes, columns=expirations)
>>>     print(df_vals)
>>>
>>>     ql_Matrix = ql.Matrix(len(strikes), len(expirations), np.nan)
>>>     for i in range(len(strikes)):
>>>         for j in range(len(expirations)):
>>>             ql_Matrix[i][j] = volMat_np[i, j]
>>>
>>>
>>>     ####################################################################
>>>     ####            We build 1 vol surface and a constant vol = BlackVol(surface)
>>>     ####################################################################
>>>
>>>     vol_process = ql.BlackVarianceSurface(ql_pricing_date, calendar, expirations, strikes,
>>>                                           ql_Matrix, day_counter)
>>>
>>>     option_vol = vol_process.blackVol(ql_date_expiry,K)
>>>     constant_vol = ql.BlackConstantVol(ql_pricing_date, calendar, option_vol, day_counter)
>>>
>>>     ####################################################################
>>>     ####            Build Process
>>>     ####################################################################
>>>
>>>     process_surface = ql.BlackScholesMertonProcess(spot_handle, dividendTS=dividend_yield, riskFreeTS=flat_ts,
>>>                                            volTS=ql.BlackVolTermStructureHandle(vol_process))
>>>
>>>     process_constant = ql.BlackScholesMertonProcess(spot_handle, dividendTS=dividend_yield, riskFreeTS=flat_ts,
>>>                                            volTS=ql.BlackVolTermStructureHandle(constant_vol))
>>>
>>>
>>>     ####################################################################
>>>     ####            Build Option to price
>>>     ####################################################################
>>>     option_surface = ql.DividendVanillaOption(payoff, exercise, [], [])
>>>     engine_surface = ql.FdBlackScholesVanillaEngine(process_surface, 200, 200)
>>>     option_surface.setPricingEngine(engine_surface)
>>>
>>>     option_constant = ql.DividendVanillaOption(payoff, exercise, [], [])
>>>     engine_constant = ql.FdBlackScholesVanillaEngine(process_constant, 200, 200)
>>>     option_constant.setPricingEngine(engine_constant)
>>>
>>>     prc_cst = option_constant.NPV()
>>>     gamma_cst = option_constant.gamma()
>>>     theta_cst = option_constant.theta() / 252. # biz day theta
>>>     vol_be_sqrt252_cst = round(math.sqrt(-2. * theta_cst / (gamma_cst * spot ** 2)) * math.sqrt(252),4)      # calculate theta-gamma break even vol to estimate what vol is being used by quantlib
>>>     print(f'Option details')
>>>     print(f'-------------------------------------------------')
>>>     print(f'Maturity: {ql_date_expiry}')
>>>     print(f'Strike: {K}')
>>>     print(f'Vol from surface: {option_vol}')
>>>     print(f'')
>>>     print(f'-------------------------------------------------')
>>>     print(f'Constant vol case')
>>>     print(f'-----------------')
>>>     print(f'Option price: {prc_cst}')
>>>     print(f'Option gamma: {gamma_cst}')
>>>     print(f'Option theta: {theta_cst}')
>>>     print(f'Break even Vol = {vol_be_sqrt252_cst} should be {option_vol}')
>>>
>>>     prc_surface = option_surface.NPV()
>>>     gamma_surface = option_surface.gamma()
>>>     theta_surface = option_surface.theta() / 252. # biz day theta
>>>     vol_be_sqrt252_surface = round(math.sqrt(-2. * theta_surface / (gamma_surface * spot ** 2)) * math.sqrt(252),4)      # calculate theta-gamma break even vol to estimate what vol is being used by quantlib
>>>     print(f'-------------------------------------------------')
>>>     print(f'Vol Surface case')
>>>     print(f'----------------')
>>>     print(f'Option price: {prc_surface}')
>>>     print(f'Option gamma: {gamma_surface}')
>>>     print(f'Option theta: {theta_surface}')
>>>     print(f'Break even Vol = {vol_be_sqrt252_surface} should be {option_vol}')
>>>
>>>
>>> if __name__ == '__main__':
>>>     run_test()
>>>
>>>
>>>
>>> We get the following results:
>>>
>>>             September 21st, 2022  November 18th, 2022  December 16th, 2022
>>>     3800.0                  0.45                 0.27                 0.37
>>>     3900.0                  0.40                 0.25                 0.31
>>>     Option details
>>>     -------------------------------------------------
>>>     Maturity: December 16th, 2022
>>>     Strike: 3800
>>>     Vol from surface: 0.37
>>>
>>>     -------------------------------------------------
>>>     Constant vol case
>>>     -----------------
>>>     Option price: 246.10555275972283
>>>     Option gamma: 0.0005462073912642451
>>>     Option theta: -2.2348817578128877
>>>     Break even Vol = 0.3705 should be 0.37
>>>     -------------------------------------------------
>>>     Vol Surface case
>>>     ----------------
>>>     Option price: 246.10595637993455
>>>     Option gamma: 0.0005462035022605052
>>>     Option theta: -3.3101198905503284
>>>     Break even Vol = 0.4509 should be 0.37
>>>
>>> If you change the vol surface to something which is not arbitrable but
>>> still has high very short term vol, the problem persists and even
>>> accentuates. In all cases the difference appears on the theta. The price of
>>> the option does not change.
>>>
>>> list_opts.append([pricing_date, expirations[0], 3800., 45.])
>>> list_opts.append([pricing_date, expirations[0], 3900., 40.])
>>>
>>> list_opts.append([pricing_date, expirations[1], 3800., 27.])
>>> list_opts.append([pricing_date, expirations[1], 3900., 25.])
>>>
>>> list_opts.append([pricing_date, expirations[2], 3800., 27.])
>>> list_opts.append([pricing_date, expirations[2], 3900., 25.])
>>>
>>> We get the following:
>>>
>>> Option details
>>> -------------------------------------------------
>>> Maturity: December 16th, 2022
>>> Strike: 3800
>>> Vol from surface: 0.27
>>>
>>> -------------------------------------------------Constant vol case
>>> -----------------
>>> Option price: 170.495477037466
>>> Option gamma: 0.0007462620578669159
>>> Option theta: -1.6258437988242298Break even Vol = 0.2703 should be 0.27
>>> -------------------------------------------------Vol Surface case
>>> ----------------
>>> Option price: 170.49560335893932
>>> Option gamma: 0.0007462597949764497
>>> Option theta: -4.538109308076177
>>> Break even Vol = 0.4517 should be 0.27
>>>
>>>
>>> Thank you very much
>>>
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>

Re: [Quantlib-users] Getting different theta when using BlackVarianceSurface and constant Vol

[Dan V. <dan...@gm...>]

Thank you Jonathan.
My example was on SPX to make it easier to read but I do need the
FdBlackScholesVanillaEngine for american options on dividend paying single
stocks and I want to make sure that the convergence between american and
european remains pure hence the checking.
Otherwise for SPX, you are correct that analytic is cleaner and faster. In
fact we even use the regular analytic engine without dividend and instead
we "yieldify" the dividends to pass them in the process instead which makes
it even faster.

In any case it would be great to get proper thetas on single stocks
american options and it looks like it's not possible at the moment.

On Sat, Oct 15, 2022 at 8:02 AM Jonathan Sweemer <sw...@gm...> wrote:

> Looks like it's due to some numerical error in
> the FdBlackScholesVanillaEngine. If I replace FdBlackScholesVanillaEngine
> with AnalyticDividendEuropeanEngine in your code then I get 0.37 as the
> breakeven vol for both the constant vol case as well as the vol surface
> case as expected.
>
> Is there any reason that you need to use the FdBlackScholesVanillaEngine?
> If not then I suppose you can use the AnalyticDividendEuropeanEngine
> instead. But if your question is what is causing the numerical error in the
> FdBlackScholesVanillaEngine then that will require more debugging.
>
> I'm sure you know already, but a constant vol surface is not suitable for
> real-world pricing, especially for short maturities where the skew in SPX
> is most extreme. You'll want to try out other pricing engines to obtain
> meaningful results on real-world data.
>
>
> On Tue, Oct 11, 2022 at 11:31 PM Dan VolPM <dan...@gm...> wrote:
>
>> Hi,
>>
>> I am running into an issue where quantlib outputs different thetas
>> whether i price with a blackvariancesurface or with the constant vol
>> extracted from the surface.
>>
>> I have a vol surface from the market on the SPX index. Not all
>> strikes/maturities are populated. In addition, there could potentially be
>> arbitrages in short maturities since we have lots of daily options and I am
>> not correcting yet for arbitrages.
>>
>> Yet when building a BlackVarianceSurface with this data and price a
>> vanilla option, I expect that option to be priced with a constant vol
>> interpolated from the grid.
>>
>> When I pass the surface object to the pricer I am getting a very
>> different theta (and therefore breakeven vol) from simply passing the
>> constant vol taken from the surface.
>>
>> Could you help me understand exactly how QLIB handles the surface and how
>> is theta computed ?
>>
>> Thank you very very much.
>>
>> Here's some sample code that compares a constant vol with a surface vol
>> pricing. Notice how the theta changes between the 2 cases leading to a very
>> different break even vol.
>>
>>
>> import pandas as pd, QuantLib as ql, math, numpy as npfrom datetime import datetime
>>
>>
>> def from_YYYYMMDD_to_ql_date(ymd):
>>     ymd = int(ymd)
>>     year = math.floor(ymd / 10000)
>>     month = int(ymd / 100) % 100
>>     day = ymd % 100
>>
>>     ql_date = ql.Date(day, month, year)
>>     return ql_date
>>
>>
>> def run_test():
>>
>>     ####################################################################
>>     ####            Global Variables
>>     ####################################################################
>>     pricing_date = datetime.strptime('20220916', '%Y%m%d')
>>     ql_pricing_date = ql.Date(16, 9, 2022)
>>     calendar = ql.UnitedStates(ql.UnitedStates.Settlement)
>>     day_counter = ql.ActualActual()
>>     spot = 3876.00
>>     spot_handle = ql.QuoteHandle(ql.SimpleQuote(spot))
>>     flat_ts = ql.YieldTermStructureHandle(ql.FlatForward(ql_pricing_date, 0, day_counter))
>>     dividend_yield = ql.YieldTermStructureHandle(ql.FlatForward(ql_pricing_date, 0, day_counter))
>>     K = 3800
>>     ql_date_expiry = ql.Date(16, 12, 2022)
>>     exercise = ql.EuropeanExercise(ql_date_expiry)
>>     payoff = ql.PlainVanillaPayoff(ql.Option.Put, strike=K)
>>
>>
>>     ####################################################################
>>     ####            Build Vol surface
>>     ####################################################################
>>     list_opts = []
>>     expirations = [datetime.strptime('20220921', '%Y%m%d'), datetime.strptime('20221118', '%Y%m%d'), datetime.strptime('20221216', '%Y%m%d'), ]
>>     list_opts.append([pricing_date, expirations[0], 3800., 45.])
>>     list_opts.append([pricing_date, expirations[0], 3900., 40.])
>>
>>     list_opts.append([pricing_date, expirations[1], 3800., 27.])
>>     list_opts.append([pricing_date, expirations[1], 3900., 25.])
>>
>>     list_opts.append([pricing_date, expirations[2], 3800., 37.])
>>     list_opts.append([pricing_date, expirations[2], 3900., 31.])
>>
>>     df = pd.DataFrame(list_opts, columns=['date', 'maturity', 'strike', 'vol'])
>>
>>     df['ymd'] = df['maturity'].dt.strftime('%Y%m%d')
>>     df['q_exp_dates'] = df['ymd'].apply(from_YYYYMMDD_to_ql_date)
>>
>>     strikes = sorted(df.strike.unique())
>>     expirations = sorted(df['q_exp_dates'].unique())
>>
>>     df['strike_idx'] = df['strike'].apply(lambda x: strikes.index(x))
>>     df['expiry_idx'] = df['q_exp_dates'].apply(lambda x: expirations.index(x))
>>
>>     volMat_np = np.full((len(strikes), len(expirations)), np.nan)
>>
>>     for strk, exp, vol in zip(df['strike_idx'], df['expiry_idx'], df['vol']):
>>         volMat_np[strk][exp] = vol / 100
>>
>>     df_vals = pd.DataFrame(volMat_np, index=strikes, columns=expirations)
>>     print(df_vals)
>>
>>     ql_Matrix = ql.Matrix(len(strikes), len(expirations), np.nan)
>>     for i in range(len(strikes)):
>>         for j in range(len(expirations)):
>>             ql_Matrix[i][j] = volMat_np[i, j]
>>
>>
>>     ####################################################################
>>     ####            We build 1 vol surface and a constant vol = BlackVol(surface)
>>     ####################################################################
>>
>>     vol_process = ql.BlackVarianceSurface(ql_pricing_date, calendar, expirations, strikes,
>>                                           ql_Matrix, day_counter)
>>
>>     option_vol = vol_process.blackVol(ql_date_expiry,K)
>>     constant_vol = ql.BlackConstantVol(ql_pricing_date, calendar, option_vol, day_counter)
>>
>>     ####################################################################
>>     ####            Build Process
>>     ####################################################################
>>
>>     process_surface = ql.BlackScholesMertonProcess(spot_handle, dividendTS=dividend_yield, riskFreeTS=flat_ts,
>>                                            volTS=ql.BlackVolTermStructureHandle(vol_process))
>>
>>     process_constant = ql.BlackScholesMertonProcess(spot_handle, dividendTS=dividend_yield, riskFreeTS=flat_ts,
>>                                            volTS=ql.BlackVolTermStructureHandle(constant_vol))
>>
>>
>>     ####################################################################
>>     ####            Build Option to price
>>     ####################################################################
>>     option_surface = ql.DividendVanillaOption(payoff, exercise, [], [])
>>     engine_surface = ql.FdBlackScholesVanillaEngine(process_surface, 200, 200)
>>     option_surface.setPricingEngine(engine_surface)
>>
>>     option_constant = ql.DividendVanillaOption(payoff, exercise, [], [])
>>     engine_constant = ql.FdBlackScholesVanillaEngine(process_constant, 200, 200)
>>     option_constant.setPricingEngine(engine_constant)
>>
>>     prc_cst = option_constant.NPV()
>>     gamma_cst = option_constant.gamma()
>>     theta_cst = option_constant.theta() / 252. # biz day theta
>>     vol_be_sqrt252_cst = round(math.sqrt(-2. * theta_cst / (gamma_cst * spot ** 2)) * math.sqrt(252),4)      # calculate theta-gamma break even vol to estimate what vol is being used by quantlib
>>     print(f'Option details')
>>     print(f'-------------------------------------------------')
>>     print(f'Maturity: {ql_date_expiry}')
>>     print(f'Strike: {K}')
>>     print(f'Vol from surface: {option_vol}')
>>     print(f'')
>>     print(f'-------------------------------------------------')
>>     print(f'Constant vol case')
>>     print(f'-----------------')
>>     print(f'Option price: {prc_cst}')
>>     print(f'Option gamma: {gamma_cst}')
>>     print(f'Option theta: {theta_cst}')
>>     print(f'Break even Vol = {vol_be_sqrt252_cst} should be {option_vol}')
>>
>>     prc_surface = option_surface.NPV()
>>     gamma_surface = option_surface.gamma()
>>     theta_surface = option_surface.theta() / 252. # biz day theta
>>     vol_be_sqrt252_surface = round(math.sqrt(-2. * theta_surface / (gamma_surface * spot ** 2)) * math.sqrt(252),4)      # calculate theta-gamma break even vol to estimate what vol is being used by quantlib
>>     print(f'-------------------------------------------------')
>>     print(f'Vol Surface case')
>>     print(f'----------------')
>>     print(f'Option price: {prc_surface}')
>>     print(f'Option gamma: {gamma_surface}')
>>     print(f'Option theta: {theta_surface}')
>>     print(f'Break even Vol = {vol_be_sqrt252_surface} should be {option_vol}')
>>
>>
>> if __name__ == '__main__':
>>     run_test()
>>
>>
>>
>> We get the following results:
>>
>>             September 21st, 2022  November 18th, 2022  December 16th, 2022
>>     3800.0                  0.45                 0.27                 0.37
>>     3900.0                  0.40                 0.25                 0.31
>>     Option details
>>     -------------------------------------------------
>>     Maturity: December 16th, 2022
>>     Strike: 3800
>>     Vol from surface: 0.37
>>
>>     -------------------------------------------------
>>     Constant vol case
>>     -----------------
>>     Option price: 246.10555275972283
>>     Option gamma: 0.0005462073912642451
>>     Option theta: -2.2348817578128877
>>     Break even Vol = 0.3705 should be 0.37
>>     -------------------------------------------------
>>     Vol Surface case
>>     ----------------
>>     Option price: 246.10595637993455
>>     Option gamma: 0.0005462035022605052
>>     Option theta: -3.3101198905503284
>>     Break even Vol = 0.4509 should be 0.37
>>
>> If you change the vol surface to something which is not arbitrable but
>> still has high very short term vol, the problem persists and even
>> accentuates. In all cases the difference appears on the theta. The price of
>> the option does not change.
>>
>> list_opts.append([pricing_date, expirations[0], 3800., 45.])
>> list_opts.append([pricing_date, expirations[0], 3900., 40.])
>>
>> list_opts.append([pricing_date, expirations[1], 3800., 27.])
>> list_opts.append([pricing_date, expirations[1], 3900., 25.])
>>
>> list_opts.append([pricing_date, expirations[2], 3800., 27.])
>> list_opts.append([pricing_date, expirations[2], 3900., 25.])
>>
>> We get the following:
>>
>> Option details
>> -------------------------------------------------
>> Maturity: December 16th, 2022
>> Strike: 3800
>> Vol from surface: 0.27
>>
>> -------------------------------------------------Constant vol case
>> -----------------
>> Option price: 170.495477037466
>> Option gamma: 0.0007462620578669159
>> Option theta: -1.6258437988242298Break even Vol = 0.2703 should be 0.27
>> -------------------------------------------------Vol Surface case
>> ----------------
>> Option price: 170.49560335893932
>> Option gamma: 0.0007462597949764497
>> Option theta: -4.538109308076177
>> Break even Vol = 0.4517 should be 0.27
>>
>>
>> Thank you very much
>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

Re: [Quantlib-users] Release candidate for 1.28

[Roland L. <rol...@ac...>]

Hi Luigi,
this works for ORE with some amendments because of the breaking change in ql/experimental.
We are aiming at upgrading ORE on github soon after QL and QL SWIG is out, within a month.
Regards,
Roland

From: Luigi Ballabio <lui...@gm...>
Date: Tuesday, 11 October 2022 at 19:02
To: QuantLib users <qua...@li...>
Subject: Re: [Quantlib-users] Release candidate for 1.28
CAUTION: External email warning. This email originated from outside acadia.inc. Beware of phishing attempts. Comply with all acadia.inc policy to confirm sender identity before responding, forwarding, and especially clicking links or opening attachments.

Ok, the ones now at <https://github.com/lballabio/QuantLib/releases/tag/1.28-rc<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flballabio%2FQuantLib%2Freleases%2Ftag%2F1.28-rc&data=05%7C01%7Croland.lichters%40acadia.inc%7Cf9de3dbd507d487f0ca108daabaa5421%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638011045315869694%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hr0VEJ3yWjpPIOa9Hk30sAzcmaQ%2FW0tsOcJ05G5LvtM%3D&reserved=0>> should be viable.  Thanks!

Luigi


On Tue, Oct 11, 2022 at 1:50 PM Luigi Ballabio <lui...@gm...<mailto:lui...@gm...>> wrote:
Please belay that — I discovered a problem with some non-standard configurations right after I posted.  I'll update the RC shortly.

Luigi


On Tue, Oct 11, 2022 at 11:53 AM Luigi Ballabio <lui...@gm...<mailto:lui...@gm...>> wrote:
Hello everybody,
    I just published a RC for version 1.28 at <https://github.com/lballabio/QuantLib/releases/tag/1.28-rc<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Flballabio%2FQuantLib%2Freleases%2Ftag%2F1.28-rc&data=05%7C01%7Croland.lichters%40acadia.inc%7Cf9de3dbd507d487f0ca108daabaa5421%7Cf432debe2aae495fb2dfe8458cace1da%7C0%7C0%7C638011045315869694%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hr0VEJ3yWjpPIOa9Hk30sAzcmaQ%2FW0tsOcJ05G5LvtM%3D&reserved=0>>.  If you have some time, please give it a spin and report any problems here on the mailing list.  Thanks!

Luigi


The information contained in this e-mail, and any attachment, is confidential and is intended solely for the use of the intended recipient. Access, copying or re-use of the e-mail or any attachment, or any information contained therein, by any other person is not authorized. If you are not the intended recipient please return the e-mail to the sender and delete it from your computer. The acadia.inc privacy policy is available on our website.

Re: [Quantlib-users] SOFR index runtime Error

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

I'd use a tenor matching the coupon frequency of your swaption, e.g.
Euribor3M if the SOFR payments are quarterly in the swap underlying
the swaption. You can also attach a SOFR forecasting curve to the
Euribor3M index. I guess that would in fact be a quite good
approximation of a SOFR swaption, whether it references term SOFR or
overnight SOFR.
Thank you
Peter

On Sun, 16 Oct 2022 at 04:42, Mark <gr...@gm...> wrote:
>
> Jonathan and Peter,
>
> Thank you for your response. If I used Euribo as a proxy to SOFR for swaption calculation, will Euribo1m a better choice than Euribo6m?
>
> Thanks,
> Mark
>
> On Sat, Oct 15, 2022 at 11:58 AM Peter Caspers <pca...@gm...> wrote:
>>
>> Just to add to what Jonathan said: QuantLib does not model SOFR
>> swaptions correctly at the moment, so even if the technical issue is
>> resolved you'll not get an accurate valuation.
>> Best, Peter
>>
>> On Sat, 15 Oct 2022 at 11:23, Jonathan Sweemer <sw...@gm...> wrote:
>> >
>> > Hi Mark,
>> >
>> > You can find the source of the error message here: https://github.com/lballabio/QuantLib/blob/master/ql/processes/gsrprocess.cpp#L92-L93
>> >
>> > Looks like your Sofr term structure somehow contains a forward from 0.915068 to 0.912329, which of course is not allowed, but it's a bit hard to know why without seeing the rest of your code.
>> >
>> >
>> > On Sat, Oct 15, 2022 at 11:58 AM Mark <gr...@gm...> wrote:
>> >>
>> >> Hi,
>> >>
>> >> If I used index=Euribor6M(termstructure) as the yield curve I can calculate European swaption through GSR model, but once I changed the index to index=Sofr(termstructure), I will get below error:
>> >>
>> >> atmSwaption.NPV()
>> >> Return _QuantLib.Intrument_NPV(self)
>> >> RuntimeError:  G(t,w) should be called with w (0.912329) not lesser than t(0.915068)
>> >>
>> >> Does anyone know what this error message means?
>> >>
>> >> Thanks,
>> >> Mark
>> >> _______________________________________________
>> >> 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] SOFR index runtime Error

[Mark <gr...@gm...>]

Jonathan and Peter,

Thank you for your response. If I used Euribo as a proxy to SOFR for
swaption calculation, will Euribo1m a better choice than Euribo6m?

Thanks,
Mark

On Sat, Oct 15, 2022 at 11:58 AM Peter Caspers <pca...@gm...>
wrote:

> Just to add to what Jonathan said: QuantLib does not model SOFR
> swaptions correctly at the moment, so even if the technical issue is
> resolved you'll not get an accurate valuation.
> Best, Peter
>
> On Sat, 15 Oct 2022 at 11:23, Jonathan Sweemer <sw...@gm...> wrote:
> >
> > Hi Mark,
> >
> > You can find the source of the error message here:
> https://github.com/lballabio/QuantLib/blob/master/ql/processes/gsrprocess.cpp#L92-L93
> >
> > Looks like your Sofr term structure somehow contains a forward from
> 0.915068 to 0.912329, which of course is not allowed, but it's a bit hard
> to know why without seeing the rest of your code.
> >
> >
> > On Sat, Oct 15, 2022 at 11:58 AM Mark <gr...@gm...> wrote:
> >>
> >> Hi,
> >>
> >> If I used index=Euribor6M(termstructure) as the yield curve I can
> calculate European swaption through GSR model, but once I changed the index
> to index=Sofr(termstructure), I will get below error:
> >>
> >> atmSwaption.NPV()
> >> Return _QuantLib.Intrument_NPV(self)
> >> RuntimeError:  G(t,w) should be called with w (0.912329) not lesser
> than t(0.915068)
> >>
> >> Does anyone know what this error message means?
> >>
> >> Thanks,
> >> Mark
> >> _______________________________________________
> >> 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
>