quantlib-users — QuantLib users discussion list

Re: [Quantlib-users] Need help with QuantLib.TARGET()

[HANISH S. <han...@gm...>]

Hi Luigi,

Thank you for the explanation.
This implementation sparks another line of thought.

If I make 2 instances of BespokeCalendar (say obj =
BespokeCalendar("Cal1") and  obj2 =  BespokeCalendar("Cal2")) and holidays
to one of the instances, the code will behave in the same way as the
previous implementation with Target class as they both are the instances of
the same calendar class.

Is my understanding correct?

Regards
Hanish Sharma


On Tue, Jun 1, 2021 at 3:08 PM Luigi Ballabio <lui...@gm...>
wrote:

> ...and of course that wasn't tested.  Here are the correct calls:
>
> obj2 = ql.BespokeCalendar("mycalendar")
> obj2.addWeekend(ql.Saturday)
> obj2.addWeekend(ql.Sunday)
>
> for d in ql.TARGET().holidayList(start_date, end_date):
>    obj2.addHoliday(d)
>
> obj2.addHoliday(my_new_holiday1)
> obj2.addHoliday(my_new_holiday2)
>
>
>
> On Tue, Jun 1, 2021 at 11:32 AM Luigi Ballabio <lui...@gm...>
> wrote:
>
>> Hello,
>>     instances of the same calendar share the added holidays.  The
>> rationale is that, when a new holiday is announced (for instance, next
>> year's Platinum Jubilee in the UK) it's possible to add it to the relevant
>> calendar just once at initialization instead of having to do it for each
>> instance.
>>
>> If you want a particular calendar instance detached from all others, you
>> can use the BespokeCalendar class, but in that case you'll start from a
>> calendar without holidays and you'll have to add the whole list of them
>> manually.  You can do something like this:
>>
>> obj2 = ql.BespokeCalendar("mycalendar")
>> obj2.addWeekday(ql.Saturday)
>> obj2.addWeekday(ql.Sunday)
>>
>> for d in TARGET().holidayList(start_date, end_date):
>>    obj2.add(d)
>>
>> obj2.add(my_new_holiday1)
>> obj2.add(my_new_holiday2)
>>
>> Hope this helps,
>>     Luigi
>>
>>
>>
>> On Tue, Jun 1, 2021 at 12:07 AM HANISH SHARMA <han...@gm...>
>> wrote:
>>
>>> Hello,
>>>
>>> Greetings,
>>>
>>> I have a question regarding the TARGET class.
>>> I have created 2 instances of the target class "obj" and "obj2".
>>> After this, I added 2 holidays in obj2 instance using addHoliday().
>>>
>>> Now, if I print the holidayList of both the instances, I get the same
>>> result ie 2 added holidays in the holiday list of obj as well.
>>> PFB the code snippet and output:
>>> [image: image.png]
>>> [image: image.png]
>>>
>>> Why is the output of obj.holidayList contains the holidays added in obj2
>>> instance?
>>>
>>> How can I get the holidaylist of obj exclusive to obj ie holidays added
>>> in other instances do not become the part obj's holidaylist.
>>>
>>> Thank you in advance.
>>>
>>> Regards
>>> Hanish Sharma
>>> _______________________________________________
>>> QuantLib-users mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>>
>>

Re: [Quantlib-users] Need help with QuantLib.TARGET()

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

...and of course that wasn't tested.  Here are the correct calls:

obj2 = ql.BespokeCalendar("mycalendar")
obj2.addWeekend(ql.Saturday)
obj2.addWeekend(ql.Sunday)

for d in ql.TARGET().holidayList(start_date, end_date):
   obj2.addHoliday(d)

obj2.addHoliday(my_new_holiday1)
obj2.addHoliday(my_new_holiday2)



On Tue, Jun 1, 2021 at 11:32 AM Luigi Ballabio <lui...@gm...>
wrote:

> Hello,
>     instances of the same calendar share the added holidays.  The
> rationale is that, when a new holiday is announced (for instance, next
> year's Platinum Jubilee in the UK) it's possible to add it to the relevant
> calendar just once at initialization instead of having to do it for each
> instance.
>
> If you want a particular calendar instance detached from all others, you
> can use the BespokeCalendar class, but in that case you'll start from a
> calendar without holidays and you'll have to add the whole list of them
> manually.  You can do something like this:
>
> obj2 = ql.BespokeCalendar("mycalendar")
> obj2.addWeekday(ql.Saturday)
> obj2.addWeekday(ql.Sunday)
>
> for d in TARGET().holidayList(start_date, end_date):
>    obj2.add(d)
>
> obj2.add(my_new_holiday1)
> obj2.add(my_new_holiday2)
>
> Hope this helps,
>     Luigi
>
>
>
> On Tue, Jun 1, 2021 at 12:07 AM HANISH SHARMA <han...@gm...>
> wrote:
>
>> Hello,
>>
>> Greetings,
>>
>> I have a question regarding the TARGET class.
>> I have created 2 instances of the target class "obj" and "obj2".
>> After this, I added 2 holidays in obj2 instance using addHoliday().
>>
>> Now, if I print the holidayList of both the instances, I get the same
>> result ie 2 added holidays in the holiday list of obj as well.
>> PFB the code snippet and output:
>> [image: image.png]
>> [image: image.png]
>>
>> Why is the output of obj.holidayList contains the holidays added in obj2
>> instance?
>>
>> How can I get the holidaylist of obj exclusive to obj ie holidays added
>> in other instances do not become the part obj's holidaylist.
>>
>> Thank you in advance.
>>
>> Regards
>> Hanish Sharma
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>

Re: [Quantlib-users] Need help with QuantLib.TARGET()

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

Hello,
    instances of the same calendar share the added holidays.  The rationale
is that, when a new holiday is announced (for instance, next year's
Platinum Jubilee in the UK) it's possible to add it to the relevant
calendar just once at initialization instead of having to do it for each
instance.

If you want a particular calendar instance detached from all others, you
can use the BespokeCalendar class, but in that case you'll start from a
calendar without holidays and you'll have to add the whole list of them
manually.  You can do something like this:

obj2 = ql.BespokeCalendar("mycalendar")
obj2.addWeekday(ql.Saturday)
obj2.addWeekday(ql.Sunday)

for d in TARGET().holidayList(start_date, end_date):
   obj2.add(d)

obj2.add(my_new_holiday1)
obj2.add(my_new_holiday2)

Hope this helps,
    Luigi



On Tue, Jun 1, 2021 at 12:07 AM HANISH SHARMA <han...@gm...>
wrote:

> Hello,
>
> Greetings,
>
> I have a question regarding the TARGET class.
> I have created 2 instances of the target class "obj" and "obj2".
> After this, I added 2 holidays in obj2 instance using addHoliday().
>
> Now, if I print the holidayList of both the instances, I get the same
> result ie 2 added holidays in the holiday list of obj as well.
> PFB the code snippet and output:
> [image: image.png]
> [image: image.png]
>
> Why is the output of obj.holidayList contains the holidays added in obj2
> instance?
>
> How can I get the holidaylist of obj exclusive to obj ie holidays added in
> other instances do not become the part obj's holidaylist.
>
> Thank you in advance.
>
> Regards
> Hanish Sharma
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] Need help with QuantLib.TARGET()

[HANISH S. <han...@gm...>]

Hello,

Greetings,

I have a question regarding the TARGET class.
I have created 2 instances of the target class "obj" and "obj2".
After this, I added 2 holidays in obj2 instance using addHoliday().

Now, if I print the holidayList of both the instances, I get the same
result ie 2 added holidays in the holiday list of obj as well.
PFB the code snippet and output:
[image: image.png]
[image: image.png]

Why is the output of obj.holidayList contains the holidays added in obj2
instance?

How can I get the holidaylist of obj exclusive to obj ie holidays added in
other instances do not become the part obj's holidaylist.

Thank you in advance.

Regards
Hanish Sharma

Re: [Quantlib-users] Correct way to manage the negative time in bond pricing

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

Hello,
    yes, the curve should be extended as suggested — the second bond coupon
fixes in February 2015, and the zero curve starts at `mydate +
Period("6M")` which is April 8th 2015, so it can't forecast that index
fixing.  If you don't have other information on the rates, you'll have to
pick a sensible way to extrapolate back.  Doing it with flat rates, as in
your second working example, sounds defensible.  Starting at 0.0, less so.

Luigi


On Sat, Apr 10, 2021 at 1:47 AM Brian Smith <bri...@gm...>
wrote:

> Hi,
>
> I have below code to price a floating rate bond:
>
> import math
> import datetime
>
> mydate = Date(8, 10, 2014)
> issueDate = Date(8, August, 2014)
> maturityDate = Date(8, August, 2019)
>
> Settings.instance().evaluationDate = mydate
>
> spots = [mydate + Period("6m"), mydate + Period("1y"), mydate +
> Period("2y"), mydate + Period("5y")]
> spotsdate = [0.002, 0.002, 0.002, 0.002]
> curveHandle = YieldTermStructureHandle(ZeroCurve(spots, spotsdate,
> Actual360(), TARGET(), Linear(), Compounded, Semiannual))
> myindex = Euribor6M(curveHandle)
> myindex.addFixing(Date(6, August, 2014), spotsdate[1], True)
>
> bond_schedule = Schedule(issueDate, maturityDate, Period(6, Months),
> TARGET(), Following, Following, DateGeneration.Backward, False)
>
> mybond = FloatingRateBond(3, 100, bond_schedule, myindex, Actual360())
>
> mybond.setPricingEngine(DiscountingBondEngine(curveHandle))
> mybond.NPV()
>
> When I run this code, I get error as
>
> RuntimeError: negative time (-0.161111) given
>
> In one of the earlier discussions, it was suggested to use some dummy
> rate corresponding to pricing date, during the curve construction. But
> if I use a dummy rate as 0 then I get different value for bond from
> using some other rate. So below 2 choices give me 2 different results
> -
>
> spots = [mydate, mydate + Period("6m"), mydate + Period("1y"), mydate
> + Period("2y"), mydate + Period("5y")]
> spotsdate = [0.00, 0.002, 0.002, 0.002, 0.002]
>
> and
>
> spots = [mydate, mydate + Period("6m"), mydate + Period("1y"), mydate
> + Period("2y"), mydate + Period("5y")]
> spotsdate = [0.002, 0.002, 0.002, 0.002, 0.002]. ### simple backfilling
>
> So I wonder, what is the right way to correct the RuntimeError:
> negative time (-0.161111) given?
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] Wrong UK holiday

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

Fixed in https://github.com/lballabio/QuantLib/pull/1103.  Thanks for the
heads-up!


On Fri, May 28, 2021 at 1:03 PM Ioannis Rigopoulos <qua...@de...>
wrote:

> Problem with the 30 May 2022 of the UK calendar resolved.
>
> It has to do with a one-time exception caused by the Queen's platinum
> jubilee celebration that allocates an extra UK bank holiday on Friday, June
> 3rd 2022.
>
> The usual last Monday of May Spring holiday has been shifted to Thursday,
> June 2nd 2022, making the Monday, May 30th 2022 a business day.
>
> More details at
> https://en.wikipedia.org/wiki/Platinum_Jubilee_of_Elizabeth_II
>
> Please adjust your code settings accordingly.
>
> Ioannis
> On 5/28/2021 12:29 PM, Ioannis Rigopoulos wrote:
>
> Resent it with a proper subject :)
> On 5/28/2021 12:20 PM, Ioannis Rigopoulos wrote:
>
> Hi QuantLib users and developers,
>
> I have just discovered the following wrong holiday that affects the
> UnitedKingdom class.
>
> I mention it here because the UK market is extremely important due to the
> many financial instruments traded there and used to calibrate many curves.
>
> All Libor rates, for example, are affected.
>
> *QuantLib regards wrongly the 30 May 2022 as holiday. This date should be
> actually replaced with the two dates 2 June (Spring or Late May) and 3 June
> (Platinum Jubilee of Elizabeth II).*
>
> The interesting is that all remaining holidays until 2049 are correct!
>
> I am not sure why this happens wrt that particular date. I will try to
> investigate and let you know.
>
> Cheers,
>
> Ioannis
>
>
>
> <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>
> <#m_-2997134614297766375_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>

[Quantlib-users] Wrong UK holiday

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

Resent it with a proper subject :)

On 5/28/2021 12:20 PM, Ioannis Rigopoulos wrote:
>
> Hi QuantLib users and developers,
>
> I have just discovered the following wrong holiday that affects the 
> UnitedKingdom class.
>
> I mention it here because the UK market is extremely important due to 
> the many financial instruments traded there and used to calibrate many 
> curves.
>
> All Libor rates, for example, are affected.
>
> *QuantLib regards wrongly the 30 May 2022 as holiday. This date should 
> be actually replaced with the two dates 2 June (Spring or Late May) 
> and 3 June (Platinum Jubilee of Elizabeth II).*
>
> The interesting is that all remaining holidays until 2049 are correct!
>
> I am not sure why this happens wrt that particular date. I will try to 
> investigate and let you know.
>
> Cheers,
>
> Ioannis
>


-- 
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Re: [Quantlib-users] Wrong UK holiday

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

Problem with the 30 May 2022 of the UK calendar resolved.

It has to do with a one-time exception caused by the Queen's platinum 
jubilee celebration that allocates an extra UK bank holiday on Friday, 
June 3rd 2022.

The usual last Monday of May Spring holiday has been shifted to 
Thursday, June 2nd 2022, making the Monday, May 30th 2022 a business day.

More details at 
https://en.wikipedia.org/wiki/Platinum_Jubilee_of_Elizabeth_II

Please adjust your code settings accordingly.

Ioannis

On 5/28/2021 12:29 PM, Ioannis Rigopoulos wrote:
>
> Resent it with a proper subject :)
>
> On 5/28/2021 12:20 PM, Ioannis Rigopoulos wrote:
>>
>> Hi QuantLib users and developers,
>>
>> I have just discovered the following wrong holiday that affects the 
>> UnitedKingdom class.
>>
>> I mention it here because the UK market is extremely important due to 
>> the many financial instruments traded there and used to calibrate 
>> many curves.
>>
>> All Libor rates, for example, are affected.
>>
>> *QuantLib regards wrongly the 30 May 2022 as holiday. This date 
>> should be actually replaced with the two dates 2 June (Spring or Late 
>> May) and 3 June (Platinum Jubilee of Elizabeth II).*
>>
>> The interesting is that all remaining holidays until 2049 are correct!
>>
>> I am not sure why this happens wrt that particular date. I will try 
>> to investigate and let you know.
>>
>> Cheers,
>>
>> Ioannis
>>


-- 
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Re: [Quantlib-users] Pricing of CAP and Swaption with Quantlib

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

Hi QuantLib users and developers,

I have just discovered the following wrong holiday that affects the 
UnitedKingdom class.

I mention it here because the UK market is extremely important due to 
the many financial instruments traded there and used to calibrate many 
curves.

All Libor rates, for example, are affected.

*QuantLib regards wrongly the 30 May 2022 as holiday. This date should 
be actually replaced with the two dates 2 June (Spring or Late May) and 
3 June (Platinum Jubilee of Elizabeth II).*

The interesting is that all remaining holidays until 2049 are correct!

I am not sure why this happens wrt that particular date. I will try to 
investigate and let you know.

Cheers,

Ioannis



-- 
Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft.
https://www.avast.com/antivirus

Re: [Quantlib-users] Time dependent volatility parameter

[Giuseppe T. <tr...@gm...>]

Hi Hitesh,

yes, you should check the example for Gaussian1dModels where you can find
the Hull and White (1 factor) with piecewise constant volatility and mean
reversion parameters:

https://www.quantlib.org/reference/_gaussian1d_models_8cpp-example.html

By the way it's also part of the python bindings already available:

https://github.com/lballabio/QuantLib-SWIG/blob/master/Python/examples/gaussian1d-models.py



Il giorno mar 25 mag 2021 alle ore 16:56 Luigi Ballabio <
lui...@gm...> ha scritto:

> Hello,
>     there's a GeneralizedHullWhite class
> in ql/experimental/shortrate/generalizedhullwhite.hpp that can take a
> series of dates and volatilities, but it's not much tested.
>
> Luigi
>
>
> On Sun, Apr 4, 2021 at 9:11 AM Hitesh Kapoor <hhi...@gm...>
> wrote:
>
>> Hi Quantlib Users,
>>
>> Is it possible to obtain time dependent volatility parameter
>> in HW1F calibration using Quantlib.
>>
>> 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
>


-- 
*Giuseppe Trapani*

Re: [Quantlib-users] Time dependent volatility parameter

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

Hello,
    there's a GeneralizedHullWhite class
in ql/experimental/shortrate/generalizedhullwhite.hpp that can take a
series of dates and volatilities, but it's not much tested.

Luigi


On Sun, Apr 4, 2021 at 9:11 AM Hitesh Kapoor <hhi...@gm...>
wrote:

> Hi Quantlib Users,
>
> Is it possible to obtain time dependent volatility parameter
> in HW1F calibration using Quantlib.
>
> Thanks,
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] QL Python Instance Evaluation Date

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

Hi Mike,
    yes, I think that's how you do it.  You have two sets of dates/discount
factors, so you can't build a single curve that moves on its own when the
evaluation date changes.

Luigi


On Tue, May 18, 2021 at 5:58 PM Mike DelMedico <mik...@gm...>
wrote:

> Hello all,
>
> I have two sets of dates/discount factors for a given type of curve (let’s
> say it’s 3mL for sake of discussion), one is yesterday’s closing curve with
> discount factor 1.0 date of 17May2021, and the other is today’s live curve
> with discount factor 1.0 date of 18May2021.
>
> If I have ql.Settings.instance().evaluationDate set to 18May2021, then in
> order to get the proper analytics like fair rate etc for today’s spot 5y
> swap (20May2021 - 20May2026) from the t-1 closing curve, I would need to 1)
> reset ql.Settings.instance().evaluationDate to 17May2021, 2) set the swap
> instrument to point to that t-1 curve, 3) do all the calculations, 4) reset
> ql.Settings.instance().evaluationDate back to 18May2021, and 5) reset the
> swap instrument to point to t0 curve?  Then I could continue any other
> downstream calcs using today’s live curve I think.
>
> I just want to make sure I’m understanding the workflow correctly and that
> I didn’t miss some other easier/more efficient way to implement this type
> of analysis.
>
> Thanks in advance for any feedback.
>
> Best,
> Mike
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] SWIG/examples/isda-cds.py

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

Francis,
    thanks.  Should the same changes be applied to the example in the
official repo?

Luigi


On Fri, May 14, 2021 at 5:51 PM Francis Duffy <fdf...@gm...>
wrote:

> Hi Ashwani,
>
> I had a quick look at this. The attached Python file uses the data and
> code that you have provided, with minor amendments described below, to get
> within $5 of the upfront vs. the ISDA CDS model output. The attached Excel
> sheet uses the ISDA model add-in available here
> <https://www.cdsmodel.com/cdsmodel/documentation.html#> to generate the
> ISDA CDS model upfront values that I am using for comparison. The code also
> checks the discount factors vs. the ISDA CDS model output.
>
> The minor amendments were:
>
>    - 1Y IR instrument is a depo as opposed to a swap
>    - The piecewise yield curve must be built with a reference date equal
>    to spot date i.e. trade date (31 Mar 2021 + 2) = 2 Apr 2021. I had to copy
>    that curve and insert a discount factor of 1.0 on 31 Mar 2021. Without
>    this, the code generates an error yield term structure reference date
>    (April 2nd, 2021 should be evaluation date (March 31st, 2021). This is
>    coming from here
>    <https://github.com/lballabio/QuantLib/blob/master/ql/pricingengines/credit/isdacdsengine.cpp#L84> and
>    could probably be relaxed.
>    - Post CDS Big Bang, protection is effective immediately on the trade
>    date so you don't need trade date + 1 when creating the CDS instrument.
>    This is an ISDA CDS model implementation detail, i.e. current period break
>    up into Riskless days and Risky days, and is taken care of in the engine
>    here
>    <https://github.com/lballabio/QuantLib/blob/master/ql/pricingengines/credit/isdacdsengine.cpp#L100>
>    .
>
> The output is as follows, where I have set the tolerance to $5:
> 2021-05-14 16:12:59 INFO     Check Markit values
> 2021-05-14 16:12:59 INFO
> 0.168958,-1005800.972539,-1005801.000000,0.027461,True
> 2021-05-14 16:12:59 INFO
> 0.168945,-1685138.710635,-1685141.000000,2.289365,True
> 2021-05-14 16:12:59 INFO
> 0.168904,-2255634.376402,-2255639.000000,4.623598,True
> 2021-05-14 16:12:59 INFO
> 0.168860,-2729114.272363,-2729119.000000,4.727637,True
> 2021-05-14 16:12:59 INFO
> 0.168821,-3121225.248050,-3121230.000000,4.751950,True
> 2021-05-14 16:12:59 INFO     distance: 16.420010
>
> I don't have access to Bloomberg to check what it generates for a trade
> date of 31 Mar 2021 (as an aside, the IR values that you provided appear to
> be from the 31 Mar 2021 ISDA IR file whereas for a trade date of 31 Mar
> 2021 I think it is convention to use the file for 30 Mar 2021 - you will
> see effectiveasof equal to 2021-03-31 in that file). The values that you
> have provided from Bloomberg look closer to the ISDA CDS converter values
> without accrued rebate but they are still quite a distance off those also.
>
> Thanks,
> Francis.
>
> On Fri, May 14, 2021 at 2:29 PM Luigi Ballabio <lui...@gm...>
> wrote:
>
>> Ashwani,
>>     the Python example doesn't get results within tolerance either, so I
>> doubt there's an obvious answer here.  We should probably check the code of
>> the engine.
>>
>> Luigi
>>
>>
>> On Thu, Apr 1, 2021 at 1:41 AM Ashwani Singh <ash...@gm...>
>> wrote:
>>
>>> Using isda-cds.py
>>> <https://github.com/lballabio/QuantLib-SWIG/blob/master/Python/examples/isda-engine.py>
>>> example to compare with Bloomberg ISDA Standard Upfront Model but the
>>> difference between QL fairUpfront and that from BBG  is much larger than
>>> the precision set. Running just for 40% recovery and 1000 bps case while
>>> looping through 5 maturities (1Y-5Y).
>>>
>>> Results (as below):
>>>
>>>    Hazard   Upfront  Market Value  Distance  Within tolerance
>>> 0    0.17 -1.00e+06      -1003010    554.96             False
>>> 1    0.17 -1.68e+06      -1682459    641.48             False
>>> 2    0.17 -2.25e+06      -2253350    426.70             False
>>> 3    0.17 -2.73e+06      -2727484     62.97             False
>>> 4    0.17 -3.12e+06      -3120142    458.70             False
>>> total distance: 2144.81
>>>
>>>
>>> Anyone who might have tried this, could you please point the obvious
>>> mistake I am committing here? Code attached.
>>>
>>> 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
>>
>

[Quantlib-users] QL Python Instance Evaluation Date

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

Hello all,

I have two sets of dates/discount factors for a given type of curve (let’s
say it’s 3mL for sake of discussion), one is yesterday’s closing curve with
discount factor 1.0 date of 17May2021, and the other is today’s live curve
with discount factor 1.0 date of 18May2021.

If I have ql.Settings.instance().evaluationDate set to 18May2021, then in
order to get the proper analytics like fair rate etc for today’s spot 5y
swap (20May2021 - 20May2026) from the t-1 closing curve, I would need to 1)
reset ql.Settings.instance().evaluationDate to 17May2021, 2) set the swap
instrument to point to that t-1 curve, 3) do all the calculations, 4) reset
ql.Settings.instance().evaluationDate back to 18May2021, and 5) reset the
swap instrument to point to t0 curve?  Then I could continue any other
downstream calcs using today’s live curve I think.

I just want to make sure I’m understanding the workflow correctly and that
I didn’t miss some other easier/more efficient way to implement this type
of analysis.

Thanks in advance for any feedback.

Best,
Mike

Re: [Quantlib-users] Help on one error

[CK <tun...@ya...>]

You should try
print(coupon.amount())

> Zenea Bathla <bat...@gm...>於2021年5月17日 下午3:11寫道：
> 
> 
> Hello,
> 
> I'm new to learning Python and QuantLib. While executing one code, I'm getting an error. Can you please guide:
> <image.png>
> 
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] Help on one error

[R M <rm...@gm...>]

Dear Zenea Bathla,

I am new to QuantLib too, but this does not look like an error to me. You
have successfully constructed a FixedRateCoupon object. I suspect you are
hoping to see the output from the amount member function. I.e., run
coupon.amount() in the next jupyter notebook cell. If this is not what you
are hoping to see, then you may consult
https://www.quantlib.org/reference/class_quant_lib_1_1_fixed_rate_coupon.html

Regards,

*---*
*From:* Zenea Bathla <bat...@gm...>
*Sent:* 13 May 2021 12:30
*To:* qua...@li...
*Subject:* [Quantlib-users] Help on one error

Hello,

I'm new to learning Python and QuantLib. While executing one code, I'm
getting an error. Can you please guide:

[image: image.png]

Re: [Quantlib-users] Help on one error

[Giuseppe T. <tr...@gm...>]

Hi Zenea,
that's not an error, that's the actual output of

print(coupon)

I'll be honest: the python bindings of quantlib are the worst way to learn
python. That's because quantlib is written in c++ following c++ standards
so, unless you are actually a bit proficient in C++, you are going to see a
lot of weird messages and outcomes that you would have never seen in python
in the first place.

Beside that, such bindings, being (for the greatest part) automatically
generated, they lack of the typical docstring documentation that guides
python developers in recognizing the type and the order of the parameters
of the functions especially when working in repl-style environments like
jupyter.

Make up for a solid foundation of "standard" python and then go for
quantlib.

Do not be discouraged by my message, my purpose is actually the opposite:
to avoid a lot of unnecessary pain =).


Il giorno lun 17 mag 2021 alle ore 09:09 Zenea Bathla <
bat...@gm...> ha scritto:

> Hello,
>
> I'm new to learning Python and QuantLib. While executing one code, I'm
> getting an error. Can you please guide:
> [image: image.png]
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>


-- 
*Giuseppe Trapani*

Re: [Quantlib-users] Help on one error

[Arun K. S. <aru...@gm...>]

Hi,

I think you should wrap the rate with simplequote function.


On Mon, 17 May 2021 at 12:39, Zenea Bathla <bat...@gm...> wrote:

> Hello,
>
> I'm new to learning Python and QuantLib. While executing one code, I'm
> getting an error. Can you please guide:
> [image: image.png]
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] SWIG/examples/isda-cds.py

[Francis D. <fdf...@gm...>]

Hi Ashwani,

I had a quick look at this. The attached Python file uses the data and code
that you have provided, with minor amendments described below, to get
within $5 of the upfront vs. the ISDA CDS model output. The attached Excel
sheet uses the ISDA model add-in available here
<https://www.cdsmodel.com/cdsmodel/documentation.html#> to generate the
ISDA CDS model upfront values that I am using for comparison. The code also
checks the discount factors vs. the ISDA CDS model output.

The minor amendments were:

   - 1Y IR instrument is a depo as opposed to a swap
   - The piecewise yield curve must be built with a reference date equal to
   spot date i.e. trade date (31 Mar 2021 + 2) = 2 Apr 2021. I had to copy
   that curve and insert a discount factor of 1.0 on 31 Mar 2021. Without
   this, the code generates an error yield term structure reference date
   (April 2nd, 2021 should be evaluation date (March 31st, 2021). This is
   coming from here
   <https://github.com/lballabio/QuantLib/blob/master/ql/pricingengines/credit/isdacdsengine.cpp#L84>
and
   could probably be relaxed.
   - Post CDS Big Bang, protection is effective immediately on the trade
   date so you don't need trade date + 1 when creating the CDS instrument.
   This is an ISDA CDS model implementation detail, i.e. current period break
   up into Riskless days and Risky days, and is taken care of in the engine
   here
   <https://github.com/lballabio/QuantLib/blob/master/ql/pricingengines/credit/isdacdsengine.cpp#L100>
   .

The output is as follows, where I have set the tolerance to $5:
2021-05-14 16:12:59 INFO     Check Markit values
2021-05-14 16:12:59 INFO
0.168958,-1005800.972539,-1005801.000000,0.027461,True
2021-05-14 16:12:59 INFO
0.168945,-1685138.710635,-1685141.000000,2.289365,True
2021-05-14 16:12:59 INFO
0.168904,-2255634.376402,-2255639.000000,4.623598,True
2021-05-14 16:12:59 INFO
0.168860,-2729114.272363,-2729119.000000,4.727637,True
2021-05-14 16:12:59 INFO
0.168821,-3121225.248050,-3121230.000000,4.751950,True
2021-05-14 16:12:59 INFO     distance: 16.420010

I don't have access to Bloomberg to check what it generates for a trade
date of 31 Mar 2021 (as an aside, the IR values that you provided appear to
be from the 31 Mar 2021 ISDA IR file whereas for a trade date of 31 Mar
2021 I think it is convention to use the file for 30 Mar 2021 - you will
see effectiveasof equal to 2021-03-31 in that file). The values that you
have provided from Bloomberg look closer to the ISDA CDS converter values
without accrued rebate but they are still quite a distance off those also.

Thanks,
Francis.

On Fri, May 14, 2021 at 2:29 PM Luigi Ballabio <lui...@gm...>
wrote:

> Ashwani,
>     the Python example doesn't get results within tolerance either, so I
> doubt there's an obvious answer here.  We should probably check the code of
> the engine.
>
> Luigi
>
>
> On Thu, Apr 1, 2021 at 1:41 AM Ashwani Singh <ash...@gm...>
> wrote:
>
>> Using isda-cds.py
>> <https://github.com/lballabio/QuantLib-SWIG/blob/master/Python/examples/isda-engine.py>
>> example to compare with Bloomberg ISDA Standard Upfront Model but the
>> difference between QL fairUpfront and that from BBG  is much larger than
>> the precision set. Running just for 40% recovery and 1000 bps case while
>> looping through 5 maturities (1Y-5Y).
>>
>> Results (as below):
>>
>>    Hazard   Upfront  Market Value  Distance  Within tolerance
>> 0    0.17 -1.00e+06      -1003010    554.96             False
>> 1    0.17 -1.68e+06      -1682459    641.48             False
>> 2    0.17 -2.25e+06      -2253350    426.70             False
>> 3    0.17 -2.73e+06      -2727484     62.97             False
>> 4    0.17 -3.12e+06      -3120142    458.70             False
>> total distance: 2144.81
>>
>>
>> Anyone who might have tried this, could you please point the obvious
>> mistake I am committing here? Code attached.
>>
>> 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] SWIG/examples/isda-cds.py

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

Ashwani,
    the Python example doesn't get results within tolerance either, so I
doubt there's an obvious answer here.  We should probably check the code of
the engine.

Luigi


On Thu, Apr 1, 2021 at 1:41 AM Ashwani Singh <ash...@gm...>
wrote:

> Using isda-cds.py
> <https://github.com/lballabio/QuantLib-SWIG/blob/master/Python/examples/isda-engine.py>
> example to compare with Bloomberg ISDA Standard Upfront Model but the
> difference between QL fairUpfront and that from BBG  is much larger than
> the precision set. Running just for 40% recovery and 1000 bps case while
> looping through 5 maturities (1Y-5Y).
>
> Results (as below):
>
>    Hazard   Upfront  Market Value  Distance  Within tolerance
> 0    0.17 -1.00e+06      -1003010    554.96             False
> 1    0.17 -1.68e+06      -1682459    641.48             False
> 2    0.17 -2.25e+06      -2253350    426.70             False
> 3    0.17 -2.73e+06      -2727484     62.97             False
> 4    0.17 -3.12e+06      -3120142    458.70             False
> total distance: 2144.81
>
>
> Anyone who might have tried this, could you please point the obvious
> mistake I am committing here? Code attached.
>
> Thanks.
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] Build quantlib wheel using Docker

[CK <tun...@ya...>]

I used brew install instead of compiling quantlib on M1 Mac

brew install quantlib boost swig

and then have to add this boost header to CXXFLAGS
-I/opt/homebrew/Cellar/boost/1.75.0_3/include'

> Luigi Ballabio <lui...@gm...>於2021年5月13日 下午9:49寫道：
> 
> 
> You're right, we don't have one of those.  Please let me know how it goes, or if the instructions at <https://www.quantlib.org/install/macosx.shtml> and <https://www.quantlib.org/install/macosx-python.shtml> need to be updated for M1 Macs.
> 
> Thanks,
>     Luigi
> 
> 
>> On Thu, May 13, 2021 at 3:20 PM CK <tun...@ya...> wrote:
>> There is no m1 Mac arm64 version
>> 
>> 
>>> Luigi Ballabio <lui...@gm...>於2021年5月13日 下午3:13寫道：
>>> 
>>> 
>>> That would be the `configure` in the C++ library.
>>> 
>>> This said: are you building the wheel because you want to change the code? If not, don't build it, use `pip install QuantLib` instead.
>>> 
>>> Luigi
>>> 
>>> 
>>>> On Thu, May 13, 2021 at 5:29 AM Ching Kai TUNG <tun...@ya...> wrote:
>>>> Hi 
>>>> I try to build the wheel 
>>>> run `configure` with `--disable-shared`
>>>> 
>>>> But it said unrecognized option?
>>>> 
>>>>> Luigi Ballabio <lui...@gm...>於2021年5月12日 下午3:20寫道：
>>>>> 
>>>>> 
>>>>> No, I haven't seen the slowness.  I have built 64-bit wheels on a Windows virtual machine and they took some minutes, not hours.  The same goes for running Docker on a 64bit Mac.
>>>>> 
>>>>>> On Tue, May 11, 2021 at 2:01 PM Alix Lassauzet <ali...@gm...> wrote:
>>>>>> Thanks Luigi for your help. This is exactly what I needed. Running `configure` with `--disable-shared` works fine, but I had to add the flag '-fPIC' in the same time. Otherwise, the swig compilation fails. I will also give a look to manylinux, which looks a better practice, thanks again.
>>>>>> 
>>>>>> I have originally tried to build your dockerfiles on a 64bit Windows machine, and I noticed the swig compilation took hours -while the compilation directly on the host machine would take ~1h. Have you ever faced this sort of slowness? I remember having facing similar issues when trying to compile QuantLib Excel in 64bits, while it was fine in 32bits.
>>>>>> 
>>>>>> I also noticed the PyQL project tackle this "issue" by relying on Cython, so that they can use parallelization (but I never tried). I don't know if there exists any workaround with swig (maybe except adding additional flag to the compiler to remove extra optimisation).
>>>>>> 
>>>>>> Alix
>>>>>> 
>>>>>>> Le lun. 10 mai 2021 à 09:14, Luigi Ballabio <lui...@gm...> a écrit :
>>>>>>> Hello Alix,
>>>>>>>     I'm not sure that `auditwheel repair` works outside the manylinux images.  Personally I'm using the `quay.io/pypa/manylinux2010_x86_64` image to build the QuantLib wheels on PyPI (used to be `quay.io/pypa/manylinux1_x86_64`, but since the latest release we need a C++11 compiler so I upgraded).  If you want to distribute to users on a given Ubuntu version, I'd probably distribute both the wheel (unrepaired) and the shared library.  If you want a self-contained wheel, another possibility (which I have done on Mac OS, but not on Linux so I can't guarantee it works) might be to run `configure` with `--disable-shared`, so it only creates the static library.  This way, the library code would be linked in the wrappers instead of being a dependency.
>>>>>>> 
>>>>>>> Hope this helps,
>>>>>>>     Luigi
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> On Sat, May 8, 2021 at 4:21 PM Alix Lassauzet <ali...@gm...> wrote:
>>>>>>>> Hello Luigi and QL community,
>>>>>>>> 
>>>>>>>> I am actually stuck in the process of building properly a wheel in QuantLib-Python from docker. In short, I am starting from Luigi's repository (https://github.com/lballabio/dockerfiles), then building the images boost, base, default and python3. At this point, one can use QuantLib-Python.
>>>>>>>> 
>>>>>>>> Then, I tried to run "python3 setup.py bdist_wheel" to generate a wheel. And "repair" the wheel using auditwheel, I am facing this error:
>>>>>>>> 
>>>>>>>> auditwheel: error: cannot repair "QuantLib******.whl" to "manylinux1_x86_64" ABI because of the presence of too-recent versioned symbols. You'll need to compile the wheel on an older toolchain.
>>>>>>>> 
>>>>>>>> I have seen a discussion where Luigi mentioned to use manylinux for building a wheel. Does it mean we cannot generate a wheel from an Ubunbu distribution? If my understanding is correct, manylinux will provide wheels for any linux distribution, and looks the best practice to industrialise the release process. But what about if we don't care about the Linux distrib, and just want to build a wheel for this Ubuntu version, assuming users are required to use the same environment? The concern here seems to link the external shared library "libQuantLib.so.0".
>>>>>>>> 
>>>>>>>> Many thanks to all,
>>>>>>>> Alix
>>>>>>>> 
>>>>>>>> Attaching the 2 earlier discussions that look related to this topic for reference:
>>>>>>>> https://sourceforge.net/p/quantlib/mailman/message/36713117/
>>>>>>>> https://github.com/lballabio/QuantLib-SWIG/issues/103
>>>>>>>> 
>>>>>>>> 
>>>>>>>> _______________________________________________
>>>>>>>> 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] Build quantlib wheel using Docker

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

You're right, we don't have one of those.  Please let me know how it goes,
or if the instructions at <https://www.quantlib.org/install/macosx.shtml>
and <https://www.quantlib.org/install/macosx-python.shtml> need to be
updated for M1 Macs.

Thanks,
    Luigi


On Thu, May 13, 2021 at 3:20 PM CK <tun...@ya...> wrote:

> There is no m1 Mac arm64 version
>
>
> Luigi Ballabio <lui...@gm...>於2021年5月13日 下午3:13寫道：
>
> 
> That would be the `configure` in the C++ library.
>
> This said: are you building the wheel because you want to change the code?
> If not, don't build it, use `pip install QuantLib` instead.
>
> Luigi
>
>
> On Thu, May 13, 2021 at 5:29 AM Ching Kai TUNG <tun...@ya...>
> wrote:
>
>> Hi
>> I try to build the wheel
>> run `configure` with `--disable-shared`
>>
>> But it said unrecognized option?
>>
>> Luigi Ballabio <lui...@gm...>於2021年5月12日 下午3:20寫道：
>>
>> 
>> No, I haven't seen the slowness.  I have built 64-bit wheels on a Windows
>> virtual machine and they took some minutes, not hours.  The same goes for
>> running Docker on a 64bit Mac.
>>
>> On Tue, May 11, 2021 at 2:01 PM Alix Lassauzet <ali...@gm...>
>> wrote:
>>
>>> Thanks Luigi for your help. This is exactly what I needed. Running
>>> `configure` with `--disable-shared` works fine, but I had to add the flag
>>> '-fPIC' in the same time. Otherwise, the swig compilation fails. I will
>>> also give a look to manylinux, which looks a better practice, thanks again.
>>>
>>> I have originally tried to build your dockerfiles on a 64bit Windows
>>> machine, and I noticed the swig compilation took hours -while the
>>> compilation directly on the host machine would take ~1h. Have you ever
>>> faced this sort of slowness? I remember having facing similar issues when
>>> trying to compile QuantLib Excel in 64bits, while it was fine in 32bits.
>>>
>>> I also noticed the PyQL project tackle this "issue" by relying on
>>> Cython, so that they can use parallelization (but I never tried). I don't
>>> know if there exists any workaround with swig (maybe except adding
>>> additional flag to the compiler to remove extra optimisation).
>>>
>>> Alix
>>>
>>> Le lun. 10 mai 2021 à 09:14, Luigi Ballabio <lui...@gm...>
>>> a écrit :
>>>
>>>> Hello Alix,
>>>>     I'm not sure that `auditwheel repair` works outside the manylinux
>>>> images.  Personally I'm using the `quay.io/pypa/manylinux2010_x86_64`
>>>> <http://quay.io/pypa/manylinux2010_x86_64> image to build the QuantLib
>>>> wheels on PyPI (used to be `quay.io/pypa/manylinux1_x86_64`
>>>> <http://quay.io/pypa/manylinux1_x86_64>, but since the latest release
>>>> we need a C++11 compiler so I upgraded).  If you want to distribute to
>>>> users on a given Ubuntu version, I'd probably distribute both the wheel
>>>> (unrepaired) and the shared library.  If you want a self-contained wheel,
>>>> another possibility (which I have done on Mac OS, but not on Linux so I
>>>> can't guarantee it works) might be to run `configure` with
>>>> `--disable-shared`, so it only creates the static library.  This way, the
>>>> library code would be linked in the wrappers instead of being a dependency.
>>>>
>>>> Hope this helps,
>>>>     Luigi
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On Sat, May 8, 2021 at 4:21 PM Alix Lassauzet <ali...@gm...>
>>>> wrote:
>>>>
>>>>> Hello Luigi and QL community,
>>>>>
>>>>> I am actually stuck in the process of building properly a wheel in
>>>>> QuantLib-Python from docker. In short, I am starting from Luigi's
>>>>> repository (https://github.com/lballabio/dockerfiles), then building
>>>>> the images boost, base, default and python3. At this point, one can use
>>>>> QuantLib-Python.
>>>>>
>>>>> Then, I tried to run "python3 setup.py bdist_wheel" to generate a
>>>>> wheel. And "repair" the wheel using auditwheel, I am facing this error:
>>>>>
>>>>> auditwheel: error: cannot repair "QuantLib******.whl" to
>>>>> "manylinux1_x86_64" ABI because of the presence of too-recent versioned
>>>>> symbols. You'll need to compile the wheel on an older toolchain.
>>>>>
>>>>> I have seen a discussion where Luigi mentioned to use manylinux for
>>>>> building a wheel. Does it mean we cannot generate a wheel from an
>>>>> Ubunbu distribution? If my understanding is correct, manylinux will provide
>>>>> wheels for any linux distribution, and looks the best practice to
>>>>> industrialise the release process. But what about if we don't care about
>>>>> the Linux distrib, and just want to build a wheel for this Ubuntu version,
>>>>> assuming users are required to use the same environment? The concern here
>>>>> seems to link the external shared library "libQuantLib.so.0".
>>>>>
>>>>> Many thanks to all,
>>>>> Alix
>>>>>
>>>>> Attaching the 2 earlier discussions that look related to this topic
>>>>> for reference:
>>>>> https://sourceforge.net/p/quantlib/mailman/message/36713117/
>>>>> https://github.com/lballabio/QuantLib-SWIG/issues/103
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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] Build quantlib wheel using Docker

[CK <tun...@ya...>]

There is no m1 Mac arm64 version


> Luigi Ballabio <lui...@gm...>於2021年5月13日 下午3:13寫道：
> 
> 
> That would be the `configure` in the C++ library.
> 
> This said: are you building the wheel because you want to change the code? If not, don't build it, use `pip install QuantLib` instead.
> 
> Luigi
> 
> 
>> On Thu, May 13, 2021 at 5:29 AM Ching Kai TUNG <tun...@ya...> wrote:
>> Hi 
>> I try to build the wheel 
>> run `configure` with `--disable-shared`
>> 
>> But it said unrecognized option?
>> 
>>> Luigi Ballabio <lui...@gm...>於2021年5月12日 下午3:20寫道：
>>> 
>>> 
>>> No, I haven't seen the slowness.  I have built 64-bit wheels on a Windows virtual machine and they took some minutes, not hours.  The same goes for running Docker on a 64bit Mac.
>>> 
>>>> On Tue, May 11, 2021 at 2:01 PM Alix Lassauzet <ali...@gm...> wrote:
>>>> Thanks Luigi for your help. This is exactly what I needed. Running `configure` with `--disable-shared` works fine, but I had to add the flag '-fPIC' in the same time. Otherwise, the swig compilation fails. I will also give a look to manylinux, which looks a better practice, thanks again.
>>>> 
>>>> I have originally tried to build your dockerfiles on a 64bit Windows machine, and I noticed the swig compilation took hours -while the compilation directly on the host machine would take ~1h. Have you ever faced this sort of slowness? I remember having facing similar issues when trying to compile QuantLib Excel in 64bits, while it was fine in 32bits.
>>>> 
>>>> I also noticed the PyQL project tackle this "issue" by relying on Cython, so that they can use parallelization (but I never tried). I don't know if there exists any workaround with swig (maybe except adding additional flag to the compiler to remove extra optimisation).
>>>> 
>>>> Alix
>>>> 
>>>>> Le lun. 10 mai 2021 à 09:14, Luigi Ballabio <lui...@gm...> a écrit :
>>>>> Hello Alix,
>>>>>     I'm not sure that `auditwheel repair` works outside the manylinux images.  Personally I'm using the `quay.io/pypa/manylinux2010_x86_64` image to build the QuantLib wheels on PyPI (used to be `quay.io/pypa/manylinux1_x86_64`, but since the latest release we need a C++11 compiler so I upgraded).  If you want to distribute to users on a given Ubuntu version, I'd probably distribute both the wheel (unrepaired) and the shared library.  If you want a self-contained wheel, another possibility (which I have done on Mac OS, but not on Linux so I can't guarantee it works) might be to run `configure` with `--disable-shared`, so it only creates the static library.  This way, the library code would be linked in the wrappers instead of being a dependency.
>>>>> 
>>>>> Hope this helps,
>>>>>     Luigi
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> On Sat, May 8, 2021 at 4:21 PM Alix Lassauzet <ali...@gm...> wrote:
>>>>>> Hello Luigi and QL community,
>>>>>> 
>>>>>> I am actually stuck in the process of building properly a wheel in QuantLib-Python from docker. In short, I am starting from Luigi's repository (https://github.com/lballabio/dockerfiles), then building the images boost, base, default and python3. At this point, one can use QuantLib-Python.
>>>>>> 
>>>>>> Then, I tried to run "python3 setup.py bdist_wheel" to generate a wheel. And "repair" the wheel using auditwheel, I am facing this error:
>>>>>> 
>>>>>> auditwheel: error: cannot repair "QuantLib******.whl" to "manylinux1_x86_64" ABI because of the presence of too-recent versioned symbols. You'll need to compile the wheel on an older toolchain.
>>>>>> 
>>>>>> I have seen a discussion where Luigi mentioned to use manylinux for building a wheel. Does it mean we cannot generate a wheel from an Ubunbu distribution? If my understanding is correct, manylinux will provide wheels for any linux distribution, and looks the best practice to industrialise the release process. But what about if we don't care about the Linux distrib, and just want to build a wheel for this Ubuntu version, assuming users are required to use the same environment? The concern here seems to link the external shared library "libQuantLib.so.0".
>>>>>> 
>>>>>> Many thanks to all,
>>>>>> Alix
>>>>>> 
>>>>>> Attaching the 2 earlier discussions that look related to this topic for reference:
>>>>>> https://sourceforge.net/p/quantlib/mailman/message/36713117/
>>>>>> https://github.com/lballabio/QuantLib-SWIG/issues/103
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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

[Quantlib-users] Help on one error

[Zenea B. <bat...@gm...>]

Hello,

I'm new to learning Python and QuantLib. While executing one code, I'm
getting an error. Can you please guide:
[image: image.png]

Re: [Quantlib-users] Build quantlib wheel using Docker

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

That would be the `configure` in the C++ library.

This said: are you building the wheel because you want to change the code?
If not, don't build it, use `pip install QuantLib` instead.

Luigi


On Thu, May 13, 2021 at 5:29 AM Ching Kai TUNG <tun...@ya...>
wrote:

> Hi
> I try to build the wheel
> run `configure` with `--disable-shared`
>
> But it said unrecognized option?
>
> Luigi Ballabio <lui...@gm...>於2021年5月12日 下午3:20寫道：
>
> 
> No, I haven't seen the slowness.  I have built 64-bit wheels on a Windows
> virtual machine and they took some minutes, not hours.  The same goes for
> running Docker on a 64bit Mac.
>
> On Tue, May 11, 2021 at 2:01 PM Alix Lassauzet <ali...@gm...>
> wrote:
>
>> Thanks Luigi for your help. This is exactly what I needed. Running
>> `configure` with `--disable-shared` works fine, but I had to add the flag
>> '-fPIC' in the same time. Otherwise, the swig compilation fails. I will
>> also give a look to manylinux, which looks a better practice, thanks again.
>>
>> I have originally tried to build your dockerfiles on a 64bit Windows
>> machine, and I noticed the swig compilation took hours -while the
>> compilation directly on the host machine would take ~1h. Have you ever
>> faced this sort of slowness? I remember having facing similar issues when
>> trying to compile QuantLib Excel in 64bits, while it was fine in 32bits.
>>
>> I also noticed the PyQL project tackle this "issue" by relying on Cython,
>> so that they can use parallelization (but I never tried). I don't know if
>> there exists any workaround with swig (maybe except adding additional flag
>> to the compiler to remove extra optimisation).
>>
>> Alix
>>
>> Le lun. 10 mai 2021 à 09:14, Luigi Ballabio <lui...@gm...> a
>> écrit :
>>
>>> Hello Alix,
>>>     I'm not sure that `auditwheel repair` works outside the manylinux
>>> images.  Personally I'm using the `quay.io/pypa/manylinux2010_x86_64`
>>> <http://quay.io/pypa/manylinux2010_x86_64> image to build the QuantLib
>>> wheels on PyPI (used to be `quay.io/pypa/manylinux1_x86_64`
>>> <http://quay.io/pypa/manylinux1_x86_64>, but since the latest release
>>> we need a C++11 compiler so I upgraded).  If you want to distribute to
>>> users on a given Ubuntu version, I'd probably distribute both the wheel
>>> (unrepaired) and the shared library.  If you want a self-contained wheel,
>>> another possibility (which I have done on Mac OS, but not on Linux so I
>>> can't guarantee it works) might be to run `configure` with
>>> `--disable-shared`, so it only creates the static library.  This way, the
>>> library code would be linked in the wrappers instead of being a dependency.
>>>
>>> Hope this helps,
>>>     Luigi
>>>
>>>
>>>
>>>
>>>
>>> On Sat, May 8, 2021 at 4:21 PM Alix Lassauzet <ali...@gm...>
>>> wrote:
>>>
>>>> Hello Luigi and QL community,
>>>>
>>>> I am actually stuck in the process of building properly a wheel in
>>>> QuantLib-Python from docker. In short, I am starting from Luigi's
>>>> repository (https://github.com/lballabio/dockerfiles), then building
>>>> the images boost, base, default and python3. At this point, one can use
>>>> QuantLib-Python.
>>>>
>>>> Then, I tried to run "python3 setup.py bdist_wheel" to generate a
>>>> wheel. And "repair" the wheel using auditwheel, I am facing this error:
>>>>
>>>> auditwheel: error: cannot repair "QuantLib******.whl" to
>>>> "manylinux1_x86_64" ABI because of the presence of too-recent versioned
>>>> symbols. You'll need to compile the wheel on an older toolchain.
>>>>
>>>> I have seen a discussion where Luigi mentioned to use manylinux for
>>>> building a wheel. Does it mean we cannot generate a wheel from an
>>>> Ubunbu distribution? If my understanding is correct, manylinux will provide
>>>> wheels for any linux distribution, and looks the best practice to
>>>> industrialise the release process. But what about if we don't care about
>>>> the Linux distrib, and just want to build a wheel for this Ubuntu version,
>>>> assuming users are required to use the same environment? The concern here
>>>> seems to link the external shared library "libQuantLib.so.0".
>>>>
>>>> Many thanks to all,
>>>> Alix
>>>>
>>>> Attaching the 2 earlier discussions that look related to this topic for
>>>> reference:
>>>> https://sourceforge.net/p/quantlib/mailman/message/36713117/
>>>> https://github.com/lballabio/QuantLib-SWIG/issues/103
>>>>
>>>>
>>>> _______________________________________________
>>>> 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
>
>