You can subscribe to this list here.
| 2000 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
(60) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
(18) |
Feb
(4) |
Mar
(6) |
Apr
(2) |
May
|
Jun
(12) |
Jul
(48) |
Aug
(6) |
Sep
(3) |
Oct
(24) |
Nov
(15) |
Dec
(18) |
| 2002 |
Jan
(39) |
Feb
(12) |
Mar
(80) |
Apr
(72) |
May
(46) |
Jun
(27) |
Jul
(23) |
Aug
(34) |
Sep
(65) |
Oct
(71) |
Nov
(19) |
Dec
(14) |
| 2003 |
Jan
(44) |
Feb
(59) |
Mar
(18) |
Apr
(62) |
May
(54) |
Jun
(27) |
Jul
(46) |
Aug
(15) |
Sep
(44) |
Oct
(36) |
Nov
(19) |
Dec
(12) |
| 2004 |
Jan
(26) |
Feb
(33) |
Mar
(47) |
Apr
(63) |
May
(36) |
Jun
(65) |
Jul
(80) |
Aug
(163) |
Sep
(65) |
Oct
(39) |
Nov
(36) |
Dec
(39) |
| 2005 |
Jan
(97) |
Feb
(78) |
Mar
(64) |
Apr
(64) |
May
(48) |
Jun
(55) |
Jul
(89) |
Aug
(57) |
Sep
(51) |
Oct
(111) |
Nov
(86) |
Dec
(76) |
| 2006 |
Jan
(84) |
Feb
(103) |
Mar
(143) |
Apr
(92) |
May
(55) |
Jun
(58) |
Jul
(71) |
Aug
(57) |
Sep
(74) |
Oct
(59) |
Nov
(8) |
Dec
(32) |
| 2007 |
Jan
(60) |
Feb
(40) |
Mar
(50) |
Apr
(26) |
May
(61) |
Jun
(120) |
Jul
(119) |
Aug
(48) |
Sep
(121) |
Oct
(66) |
Nov
(103) |
Dec
(43) |
| 2008 |
Jan
(60) |
Feb
(109) |
Mar
(92) |
Apr
(106) |
May
(82) |
Jun
(59) |
Jul
(67) |
Aug
(118) |
Sep
(131) |
Oct
(56) |
Nov
(37) |
Dec
(69) |
| 2009 |
Jan
(75) |
Feb
(76) |
Mar
(103) |
Apr
(78) |
May
(61) |
Jun
(35) |
Jul
(66) |
Aug
(69) |
Sep
(166) |
Oct
(46) |
Nov
(72) |
Dec
(65) |
| 2010 |
Jan
(48) |
Feb
(57) |
Mar
(93) |
Apr
(85) |
May
(123) |
Jun
(82) |
Jul
(98) |
Aug
(121) |
Sep
(146) |
Oct
(86) |
Nov
(72) |
Dec
(34) |
| 2011 |
Jan
(96) |
Feb
(55) |
Mar
(73) |
Apr
(57) |
May
(33) |
Jun
(74) |
Jul
(89) |
Aug
(71) |
Sep
(103) |
Oct
(76) |
Nov
(52) |
Dec
(61) |
| 2012 |
Jan
(48) |
Feb
(54) |
Mar
(78) |
Apr
(60) |
May
(75) |
Jun
(59) |
Jul
(33) |
Aug
(66) |
Sep
(43) |
Oct
(46) |
Nov
(75) |
Dec
(51) |
| 2013 |
Jan
(112) |
Feb
(72) |
Mar
(49) |
Apr
(48) |
May
(42) |
Jun
(44) |
Jul
(80) |
Aug
(19) |
Sep
(33) |
Oct
(37) |
Nov
(38) |
Dec
(98) |
| 2014 |
Jan
(113) |
Feb
(93) |
Mar
(49) |
Apr
(106) |
May
(97) |
Jun
(155) |
Jul
(87) |
Aug
(127) |
Sep
(85) |
Oct
(48) |
Nov
(41) |
Dec
(37) |
| 2015 |
Jan
(34) |
Feb
(50) |
Mar
(104) |
Apr
(80) |
May
(82) |
Jun
(66) |
Jul
(41) |
Aug
(84) |
Sep
(37) |
Oct
(65) |
Nov
(83) |
Dec
(52) |
| 2016 |
Jan
(68) |
Feb
(35) |
Mar
(42) |
Apr
(35) |
May
(54) |
Jun
(75) |
Jul
(45) |
Aug
(52) |
Sep
(60) |
Oct
(52) |
Nov
(36) |
Dec
(64) |
| 2017 |
Jan
(92) |
Feb
(59) |
Mar
(35) |
Apr
(53) |
May
(83) |
Jun
(43) |
Jul
(65) |
Aug
(68) |
Sep
(46) |
Oct
(75) |
Nov
(40) |
Dec
(49) |
| 2018 |
Jan
(68) |
Feb
(54) |
Mar
(48) |
Apr
(58) |
May
(51) |
Jun
(44) |
Jul
(40) |
Aug
(68) |
Sep
(35) |
Oct
(15) |
Nov
(7) |
Dec
(37) |
| 2019 |
Jan
(43) |
Feb
(7) |
Mar
(22) |
Apr
(21) |
May
(31) |
Jun
(39) |
Jul
(73) |
Aug
(45) |
Sep
(47) |
Oct
(89) |
Nov
(19) |
Dec
(69) |
| 2020 |
Jan
(52) |
Feb
(63) |
Mar
(45) |
Apr
(59) |
May
(42) |
Jun
(57) |
Jul
(30) |
Aug
(29) |
Sep
(75) |
Oct
(64) |
Nov
(96) |
Dec
(22) |
| 2021 |
Jan
(14) |
Feb
(24) |
Mar
(35) |
Apr
(58) |
May
(36) |
Jun
(15) |
Jul
(18) |
Aug
(31) |
Sep
(30) |
Oct
(33) |
Nov
(27) |
Dec
(16) |
| 2022 |
Jan
(35) |
Feb
(22) |
Mar
(14) |
Apr
(20) |
May
(44) |
Jun
(53) |
Jul
(25) |
Aug
(56) |
Sep
(11) |
Oct
(47) |
Nov
(22) |
Dec
(36) |
| 2023 |
Jan
(30) |
Feb
(17) |
Mar
(31) |
Apr
(48) |
May
(31) |
Jun
(7) |
Jul
(25) |
Aug
(26) |
Sep
(61) |
Oct
(66) |
Nov
(19) |
Dec
(21) |
| 2024 |
Jan
(37) |
Feb
(29) |
Mar
(26) |
Apr
(26) |
May
(34) |
Jun
(9) |
Jul
(27) |
Aug
(13) |
Sep
(15) |
Oct
(25) |
Nov
(13) |
Dec
(8) |
| 2025 |
Jan
(13) |
Feb
(1) |
Mar
(16) |
Apr
(17) |
May
(8) |
Jun
(6) |
Jul
(9) |
Aug
|
Sep
(6) |
Oct
(15) |
Nov
(6) |
Dec
|
| 2026 |
Jan
(6) |
Feb
(4) |
Mar
(20) |
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ching K. T. <tun...@ya...> - 2021-05-13 03:29:37
|
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 |
|
From: Luigi B. <lui...@gm...> - 2021-05-12 07:18:45
|
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 >>> >>> |
|
From: Alix L. <ali...@gm...> - 2021-05-11 12:01:39
|
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 >> >> |
|
From: Luigi B. <lui...@gm...> - 2021-05-10 07:15:00
|
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
>
|
|
From: Luigi B. <lui...@gm...> - 2021-05-10 07:05:39
|
Hi Kenneth,
one thing you might want to check is the units for rates — when you say
1Y -> -0.12, i.e. -12 bps, that should be passed as -0.0012. (You might
already do that, but I thought I'd check.)
Luigi
On Sun, May 9, 2021 at 4:59 PM Kenneth Christensen <ke...@mo...>
wrote:
> Hi all!
>
> I am trying to price a callable fixed rate amortizing danish mortgage
> bond. since QuantLib only has `CallableFixedRateBond` i have created a
> dervived class called `CallableAmortizedBond` which looks like
> `AmortizingFixedRateBond`:
>
> ```
> class CallableAmortizedBond : public CallableFixedRateBond
> {
>
> public:
> CallableAmortizedBond(
> Natural settlementDays,
> Real faceAmount,
> const Schedule &schedule,
> const vector<Rate> &coupons,
> const DayCounter &accrualDayCounter,
> BusinessDayConvention paymentConvention,
> Real redemption,
> const Date &issueDate,
> const vector<Rate> ¬ionals,
> const CallabilitySchedule &putCallSchedule)
> : CallableFixedRateBond(settlementDays, faceAmount, schedule,
> coupons, accrualDayCounter, paymentConvention, redemption, issueDate,
> putCallSchedule)
> {
> cashflows_ =
> FixedRateLeg(schedule)
> .withNotionals(notionals)
> .withCouponRates(coupons, accrualDayCounter)
> .withPaymentAdjustment(paymentConvention);
> }
> };
> ```
>
> I have added notionals with inspiration from:
>
> ```
> Schedule sinkingSchedule(const Date& startDate,
> const Period& maturityTenor,
> const Frequency& sinkingFrequency,
> const Calendar& paymentCalendar)
> ```
>
> Which can look like this for different bonds:
>
> For bond with no amortization it will be a vector of faceValues e.g.
> `[100.0 .. 100.0]`
> For bonds with partial amortization it will be with faceValues until
> amortization starts and then fully amortizing: `[100.0, 100.0 .. 99.0 97.0
> .. 0.0]`
> For bonds with full amortization it will be `[100.0, 99.0 .. 0.0]`
>
> I use swaprates to create a `YieldTermStructure` with the following values:
>
> ```1Y -> -0.12
> 2Y -> -0.13
> 3Y -> -0.09
> 4Y -> -0.03
> 5Y -> -0.03
> 6Y -> 0.1
> 7Y -> 0.18
> 8Y -> 0.25
> 9Y -> 0.32
> 10Y -> 0.39
> 12Y -> 0.51
> 15Y -> 0.65
> ```
>
> like this:
>
> ```
> Handle<YieldTermStructure> calculateTermStructure(rust::Vec<SwapRates>
> swapRates, RustDate now)
> {
> Calendar calendar = TARGET();
> Date settlementDate(now.day, getMonthFromInt(now.month), now.year);
> Frequency swFixedLegFrequency = Annual;
> BusinessDayConvention swFixedLegConvention = Unadjusted;
> DayCounter swFixedLegDayCounter = dayCounter;
> DayCounter termStructureDayCounter = dayCounter;
> ext::shared_ptr<IborIndex> swFloatingLegIndex(new Euribor1Y);
>
> const Period forwardStart(1 * Days);
>
> std::vector<ext::shared_ptr<RateHelper>> swapInstruments;
> for (auto const &swapRate : swapRates)
> {
> ext::shared_ptr<Quote> simpleQuote(new SimpleQuote(swapRate.rate));
> ext::shared_ptr<RateHelper> swapRateHelper(new SwapRateHelper(
> Handle<Quote>(simpleQuote), swapRate.maturity * Years,
> calendar, swFixedLegFrequency,
> swFixedLegConvention, swFixedLegDayCounter,
> swFloatingLegIndex, Handle<Quote>(), forwardStart));
> swapInstruments.push_back(swapRateHelper);
> }
>
> ext::shared_ptr<YieldTermStructure> swapTermStructure(
> new PiecewiseYieldCurve<Discount, LogLinear>(
> settlementDate, swapInstruments,
> termStructureDayCounter));
> Handle<YieldTermStructure> termStructure(swapTermStructure);
>
> termStructure->enableExtrapolation();
> return termStructure;
> }
> ```
>
> I create the `CallabilitySchedule` using the following function:
>
> ```
> CallabilitySchedule getCallSchedule(rust::Vec<RustDate> callSchedule)
> {
>
> CallabilitySchedule callabilitySchedule;
> Real callPrice = 100.;
>
> for (auto const &callRustRate : callSchedule)
> {
> Bond::Price bondCallPrice(callPrice, Bond::Price::Clean);
>
> Date callDate(callRustRate.day, getMonthFromInt(callRustRate.month),
> callRustRate.year);
> callabilitySchedule.push_back(
> ext::make_shared<Callability>(
> bondCallPrice,
> Callability::Call,
> callDate));
> }
>
> return callabilitySchedule;
> }
> ```
>
> Which i then use to price a callable mortgage bond:
>
> ```
> Integer gridIntervals = 40;
> Real reversionParameter = .03;
>
> // output price/yield results for varying volatility parameter
>
> Real sigma = QL_EPSILON; // core dumps if zero on Cygwin
>
> ext::shared_ptr<ShortRateModel> hw0(
> new HullWhite(termStructure, reversionParameter, sigma));
>
> ext::shared_ptr<PricingEngine> engine0(
> new TreeCallableFixedRateBondEngine(hw0, gridIntervals));
>
> ext::shared_ptr<PricingEngine> bondEngine(
> new DiscountingBondEngine(termStructure));
>
> vector<Rate> notionalRates;
> for (auto const ¬ional : notionals)
> {
> notionalRates.push_back(notional);
> }
>
> CallableAmortizedBond callableAmortizedBond(settlementDays, faceAmount,
> schedule,
> vector<Rate>(1, coupon),
> dayCounter,
> paymentConvention,
> redemption, datedDate,
> notionalRates, callabilitySchedule);
>
> callableAmortizedBond.setPricingEngine(engine0);
>
> return callableAmortizedBond.cleanPrice();
> ```
>
> The price returned using `.cleanPrice()` is much lower than the price
> found on Nasdaq. For example [this bond](
> http://www.nasdaqomxnordic.com/bonds/denmark/microsite?Instrument=XCSE0%3A5RD27SSA53)
> has a last price of `91.210` but my price using the current swap rates is
> `88.542` with no amortization.
>
> Another issue is that with amortization i get lower prices than without.
> Which is opposite of what happens in the real world. So is this correct way
> to price callable amortizing mortgage bonds? And is it the correct way to
> add amortization for the callable bond class?
>
> Thanks a lot for you help!
>
> Kenneth
>
>
>
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
|
|
From: Kenneth C. <ke...@mo...> - 2021-05-09 14:57:05
|
Hi all!
I am trying to price a callable fixed rate amortizing danish mortgage bond. since QuantLib only has `CallableFixedRateBond` i have created a dervived class called `CallableAmortizedBond` which looks like `AmortizingFixedRateBond`:
```
class CallableAmortizedBond : public CallableFixedRateBond
{
public:
CallableAmortizedBond(
Natural settlementDays,
Real faceAmount,
const Schedule &schedule,
const vector<Rate> &coupons,
const DayCounter &accrualDayCounter,
BusinessDayConvention paymentConvention,
Real redemption,
const Date &issueDate,
const vector<Rate> ¬ionals,
const CallabilitySchedule &putCallSchedule)
: CallableFixedRateBond(settlementDays, faceAmount, schedule, coupons, accrualDayCounter, paymentConvention, redemption, issueDate, putCallSchedule)
{
cashflows_ =
FixedRateLeg(schedule)
.withNotionals(notionals)
.withCouponRates(coupons, accrualDayCounter)
.withPaymentAdjustment(paymentConvention);
}
};
```
I have added notionals with inspiration from:
```
Schedule sinkingSchedule(const Date& startDate,
const Period& maturityTenor,
const Frequency& sinkingFrequency,
const Calendar& paymentCalendar)
```
Which can look like this for different bonds:
For bond with no amortization it will be a vector of faceValues e.g. `[100.0 .. 100.0]`
For bonds with partial amortization it will be with faceValues until amortization starts and then fully amortizing: `[100.0, 100.0 .. 99.0 97.0 .. 0.0]`
For bonds with full amortization it will be `[100.0, 99.0 .. 0.0]`
I use swaprates to create a `YieldTermStructure` with the following values:
```1Y -> -0.12
2Y -> -0.13
3Y -> -0.09
4Y -> -0.03
5Y -> -0.03
6Y -> 0.1
7Y -> 0.18
8Y -> 0.25
9Y -> 0.32
10Y -> 0.39
12Y -> 0.51
15Y -> 0.65
```
like this:
```
Handle<YieldTermStructure> calculateTermStructure(rust::Vec<SwapRates> swapRates, RustDate now)
{
Calendar calendar = TARGET();
Date settlementDate(now.day, getMonthFromInt(now.month), now.year);
Frequency swFixedLegFrequency = Annual;
BusinessDayConvention swFixedLegConvention = Unadjusted;
DayCounter swFixedLegDayCounter = dayCounter;
DayCounter termStructureDayCounter = dayCounter;
ext::shared_ptr<IborIndex> swFloatingLegIndex(new Euribor1Y);
const Period forwardStart(1 * Days);
std::vector<ext::shared_ptr<RateHelper>> swapInstruments;
for (auto const &swapRate : swapRates)
{
ext::shared_ptr<Quote> simpleQuote(new SimpleQuote(swapRate.rate));
ext::shared_ptr<RateHelper> swapRateHelper(new SwapRateHelper(
Handle<Quote>(simpleQuote), swapRate.maturity * Years,
calendar, swFixedLegFrequency,
swFixedLegConvention, swFixedLegDayCounter,
swFloatingLegIndex, Handle<Quote>(), forwardStart));
swapInstruments.push_back(swapRateHelper);
}
ext::shared_ptr<YieldTermStructure> swapTermStructure(
new PiecewiseYieldCurve<Discount, LogLinear>(
settlementDate, swapInstruments,
termStructureDayCounter));
Handle<YieldTermStructure> termStructure(swapTermStructure);
termStructure->enableExtrapolation();
return termStructure;
}
```
I create the `CallabilitySchedule` using the following function:
```
CallabilitySchedule getCallSchedule(rust::Vec<RustDate> callSchedule)
{
CallabilitySchedule callabilitySchedule;
Real callPrice = 100.;
for (auto const &callRustRate : callSchedule)
{
Bond::Price bondCallPrice(callPrice, Bond::Price::Clean);
Date callDate(callRustRate.day, getMonthFromInt(callRustRate.month), callRustRate.year);
callabilitySchedule.push_back(
ext::make_shared<Callability>(
bondCallPrice,
Callability::Call,
callDate));
}
return callabilitySchedule;
}
```
Which i then use to price a callable mortgage bond:
```
Integer gridIntervals = 40;
Real reversionParameter = .03;
// output price/yield results for varying volatility parameter
Real sigma = QL_EPSILON; // core dumps if zero on Cygwin
ext::shared_ptr<ShortRateModel> hw0(
new HullWhite(termStructure, reversionParameter, sigma));
ext::shared_ptr<PricingEngine> engine0(
new TreeCallableFixedRateBondEngine(hw0, gridIntervals));
ext::shared_ptr<PricingEngine> bondEngine(
new DiscountingBondEngine(termStructure));
vector<Rate> notionalRates;
for (auto const ¬ional : notionals)
{
notionalRates.push_back(notional);
}
CallableAmortizedBond callableAmortizedBond(settlementDays, faceAmount, schedule,
vector<Rate>(1, coupon),
dayCounter, paymentConvention,
redemption, datedDate, notionalRates, callabilitySchedule);
callableAmortizedBond.setPricingEngine(engine0);
return callableAmortizedBond.cleanPrice();
```
The price returned using `.cleanPrice()` is much lower than the price found on Nasdaq. For example [this bond](http://www.nasdaqomxnordic.com/bonds/denmark/microsite?Instrument=XCSE0%3A5RD27SSA53) has a last price of `91.210` but my price using the current swap rates is `88.542` with no amortization.
Another issue is that with amortization i get lower prices than without. Which is opposite of what happens in the real world. So is this correct way to price callable amortizing mortgage bonds? And is it the correct way to add amortization for the callable bond class?
Thanks a lot for you help!
Kenneth |
|
From: Alix L. <ali...@gm...> - 2021-05-08 14:19:38
|
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 |
|
From: Francis D. <fdf...@gm...> - 2021-05-06 19:23:52
|
Hi Luigi, I thought that I cc'ed the group on this but I replied directly by mistake. I answered this as follows with the updated attachment: I have attached a v2 of your file with some changes showing how you get back the input fair spread and an NPV of 0: - I would use "settlementDays" = 0 i.e. protection start is equal to trade date with protection effective immediately. I believe that this is the standard for CDS post the 2009 Big Bang. I know that the ISDA model has T + 1 for riskless days but that is handled in the engine. - Evaluation date is 13 Jun 2011, so I would use "DateGeneration::CDS". For more recent evaluation dates after 2015, I would use "DateGeneration::CDS2015". - To get the "terminationDate" that you use in your schedule, I would use the "cdsMaturity(...)" function. It handles the various CDS conventions to generate the correct maturity. - When creating the instrument, I would use the extra ctor parameters to provide the "protectionStart" explicitly as the trade date (if this is not provided, protection start is assumed to be the first date in the CDS schedule) and the last period day counter of "Actual360(true)". These changes give an output of: -- Repricing the first instrument used for calibration: -- par spread: 0.792700 % NPV: -2.65118e-10 default leg: -4165.83 coupon leg: 6037.46 Thanks, Francis. On Thu, May 6, 2021 at 5:08 PM Luigi Ballabio <lui...@gm...> wrote: > Thanks for the heads up. There's definitely something weird going on. > I'll try investigating some more... > > Luigi > > > On Wed, Apr 21, 2021 at 4:19 AM HB <kar...@gm...> wrote: > >> Hi all, >> >> I would really appreciate any insights on how to properly re-price >> the CDS used to bootstrap a survival probability curve. >> >> After building a survival probability curve from CDS instruments, I >> re-price the calibration instruments as a sanity check, however the NPV of >> the re-priced CDS is not zero. >> >> The attached file is a minimal working example. >> >> Using the first CDS as an example, if in each `SpreadCdsHelper` I use >> `model == CreditDefaultSwap::ISDA` and as pricing engine the >> `MidPointCdsEngine`, then I get an NPV of ~17 cents. If the pricing engine >> is changed to `IsdaCdsEngine` (so that, on the surface, appears consistent >> with the model), then the NPV becomes a whooping ~ $22: >> >> -- Repricing the first instrument used for calibration: >> -- par spread: 0.792734 % >> NPV: -0.176124 >> default leg: -4143.93 >> coupon leg: 4143.75 >> >> -- Repricing the first instrument used for calibration: >> -- par spread: 0.796878 % >> NPV: -21.8426 >> default leg: -4165.85 >> coupon leg: 4144.01 >> >> >> Thanks in advance and best regards, >> HB >> _______________________________________________ >> 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 > |
|
From: Luigi B. <lui...@gm...> - 2021-05-06 16:06:21
|
Thanks for the heads up. There's definitely something weird going on. I'll try investigating some more... Luigi On Wed, Apr 21, 2021 at 4:19 AM HB <kar...@gm...> wrote: > Hi all, > > I would really appreciate any insights on how to properly re-price the CDS > used to bootstrap a survival probability curve. > > After building a survival probability curve from CDS instruments, I > re-price the calibration instruments as a sanity check, however the NPV of > the re-priced CDS is not zero. > > The attached file is a minimal working example. > > Using the first CDS as an example, if in each `SpreadCdsHelper` I use > `model == CreditDefaultSwap::ISDA` and as pricing engine the > `MidPointCdsEngine`, then I get an NPV of ~17 cents. If the pricing engine > is changed to `IsdaCdsEngine` (so that, on the surface, appears consistent > with the model), then the NPV becomes a whooping ~ $22: > > -- Repricing the first instrument used for calibration: > -- par spread: 0.792734 % > NPV: -0.176124 > default leg: -4143.93 > coupon leg: 4143.75 > > -- Repricing the first instrument used for calibration: > -- par spread: 0.796878 % > NPV: -21.8426 > default leg: -4165.85 > coupon leg: 4144.01 > > > Thanks in advance and best regards, > HB > _______________________________________________ > QuantLib-users mailing list > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-users > |
|
From: Luigi B. <lui...@gm...> - 2021-05-06 07:23:15
|
Jan,
your rates are off by a factor of 100. A rate of 2% needs to be
written in as 0.02, not 2.0.
Best,
Luigi
On Wed, May 5, 2021 at 5:08 PM Jan Muller <jan...@gm...> wrote:
> Hey,
>
> I am attempting to price a callable bond and determine the option-adjusted
> spread of a callable bond under the Hull-White model. I have an example of
> code attached enclosed:
>
> https://stackoverflow.com/questions/67370737/oas-quantlib-of-callable-bond
>
> Unfortunately, the results I am obtaining for OAS are always negative,
> though the obtained bond yields from the same object seem reasonable. Does
> anyone have any ideas of what is going wrong?
>
> The bond should be callable on either a) the call dates (European) at the
> prices provided or b) on the coupon dates (Bermudan/American).
>
> Best Regards,
> Jan Muller
> _______________________________________________
> QuantLib-users mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>
|
|
From: Philippe H. <phi...@ex...> - 2021-05-05 15:26:25
|
I posted this on StackOverflow. Not a final answer, but some ideas to help debug. I would set the prepay penalty (call strike) very high so that it is always uneconomic to call, then observe/confirm that your OAS is zero. That would at least validate some of your overall setup. if it passes that test then I would incrementally make one of them economic, and try pricing the European option separately (you could do closed-form with Jamshidian Engine on top of your HW process which is affine) then see if the decompounded value of the option on the dv01 of the bond is close enough to your OAS (assuming the latter is positive). Although if you have a negative OAS with an American set of call dates, it's unlikely that it will become positive with an European call schedule. But these tests may provide some insights. Philippe Hatstadt On Wed, May 5, 2021 at 11:06 AM Jan Muller <jan...@gm...> wrote: > Hey, > > I am attempting to price a callable bond and determine the option-adjusted > spread of a callable bond under the Hull-White model. I have an example of > code attached enclosed: > > https://stackoverflow.com/questions/67370737/oas-quantlib-of-callable-bond > > Unfortunately, the results I am obtaining for OAS are always negative, > though the obtained bond yields from the same object seem reasonable. Does > anyone have any ideas of what is going wrong? > > The bond should be callable on either a) the call dates (European) at the > prices provided or b) on the coupon dates (Bermudan/American). > > Best Regards, > Jan Muller > _______________________________________________ > QuantLib-users mailing list > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-users > -- Broker-Dealer services offered through Exos Securities LLC, member of SIPC <http://www.sipc.org/> / FINRA <http://www.finra.org/> / BrokerCheck <https://brokercheck.finra.org/>/ 2021 Exos, inc. For important disclosures, click here <https://www.exosfinancial.com/general-disclosures>. |
|
From: Jan M. <jan...@gm...> - 2021-05-05 15:06:32
|
Hey, I am attempting to price a callable bond and determine the option-adjusted spread of a callable bond under the Hull-White model. I have an example of code attached enclosed: https://stackoverflow.com/questions/67370737/oas-quantlib-of-callable-bond Unfortunately, the results I am obtaining for OAS are always negative, though the obtained bond yields from the same object seem reasonable. Does anyone have any ideas of what is going wrong? The bond should be callable on either a) the call dates (European) at the prices provided or b) on the coupon dates (Bermudan/American). Best Regards, Jan Muller |
|
From: Eric E. <eri...@re...> - 2021-05-03 15:21:52
|
QuantLibXL, QuantLibAddin, ObjectHandler, and gensrc version 1.22 have been released and are available for download: https://github.com/eehlers/QuantLibAddin-Old/releases/tag/QuantLibAddin-v1.22 QuantLibAddin http://www.quantlibaddin.org QuantLibAddin exports the QuantLib interface to a variety of end user platforms. QuantLibXL http://www.quantlibxl.org QuantLibXL is the implementation of QuantLibAddin for Microsoft Excel. The QuantLibXL project includes a binary release comprising a compiled Addin and example workbooks. ObjectHandler http://www.objecthandler.org ObjectHandler implements a repository where objects can be stored, shared, updated, interrogated, and destroyed. This facilitates object orientation in procedural environments such as spreadsheets. |
|
From: Peter C. <pca...@gm...> - 2021-05-01 17:18:27
|
Hi Christofer,
below are some such example trades represented in ORE XML. You should
think of EUR-EONIA as one of the new RFRs probably.
Thanks
Peter
<?xml version="1.0" encoding="UTF-8"?>
<Portfolio>
<Trade id="global_excludeSpread">
<TradeType>Swap</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<SwapData>
<LegData>
<LegType>Floating</LegType>
<Payer>false</Payer>
<Currency>EUR</Currency>
<Notionals>
<Notional>100000000</Notional>
</Notionals>
<DayCounter>A360</DayCounter>
<PaymentConvention>MF</PaymentConvention>
<FloatingLegData>
<Index>EUR-EONIA</Index>
<FixingDays>0</FixingDays>
<Lookback>0D</Lookback>
<RateCutoff>2</RateCutoff>
<IncludeSpread>false</IncludeSpread>
<Spreads>
<Spread>0.01</Spread>
</Spreads>
<Floors>
<Floor>0.0</Floor>
</Floors>
<NakedOption>false</NakedOption>
<LocalCapFloor>false</LocalCapFloor>
</FloatingLegData>
<ScheduleData>
<Rules>
<StartDate>20201130</StartDate>
<EndDate>20221130</EndDate>
<Tenor>3M</Tenor>
<Calendar>US</Calendar>
<Convention>MF</Convention>
<TermConvention>MF</TermConvention>
<Rule>Backward</Rule>
<EndOfMonth>false</EndOfMonth>
<FirstDate/>
<LastDate/>
</Rules>
</ScheduleData>
</LegData>
</SwapData>
</Trade>
<Trade id="global_includeSpread">
<TradeType>Swap</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<SwapData>
<LegData>
<LegType>Floating</LegType>
<Payer>false</Payer>
<Currency>EUR</Currency>
<Notionals>
<Notional>100000000</Notional>
</Notionals>
<DayCounter>A360</DayCounter>
<PaymentConvention>MF</PaymentConvention>
<FloatingLegData>
<Index>EUR-EONIA</Index>
<FixingDays>0</FixingDays>
<Lookback>0D</Lookback>
<RateCutoff>2</RateCutoff>
<IncludeSpread>true</IncludeSpread>
<Spreads>
<Spread>0.01</Spread>
</Spreads>
<Floors>
<Floor>0.0</Floor>
</Floors>
<NakedOption>false</NakedOption>
<LocalCapFloor>false</LocalCapFloor>
</FloatingLegData>
<ScheduleData>
<Rules>
<StartDate>20201130</StartDate>
<EndDate>20221130</EndDate>
<Tenor>3M</Tenor>
<Calendar>US</Calendar>
<Convention>MF</Convention>
<TermConvention>MF</TermConvention>
<Rule>Backward</Rule>
<EndOfMonth>false</EndOfMonth>
<FirstDate/>
<LastDate/>
</Rules>
</ScheduleData>
</LegData>
</SwapData>
</Trade>
<Trade id="local_excludeSpread">
<TradeType>Swap</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<SwapData>
<LegData>
<LegType>Floating</LegType>
<Payer>false</Payer>
<Currency>EUR</Currency>
<Notionals>
<Notional>100000000</Notional>
</Notionals>
<DayCounter>A360</DayCounter>
<PaymentConvention>MF</PaymentConvention>
<FloatingLegData>
<Index>EUR-EONIA</Index>
<FixingDays>0</FixingDays>
<Lookback>0D</Lookback>
<RateCutoff>2</RateCutoff>
<IncludeSpread>false</IncludeSpread>
<Spreads>
<Spread>0.01</Spread>
</Spreads>
<Floors>
<Floor>0.0</Floor>
</Floors>
<NakedOption>false</NakedOption>
<LocalCapFloor>true</LocalCapFloor>
</FloatingLegData>
<ScheduleData>
<Rules>
<StartDate>20201130</StartDate>
<EndDate>20221130</EndDate>
<Tenor>3M</Tenor>
<Calendar>US</Calendar>
<Convention>MF</Convention>
<TermConvention>MF</TermConvention>
<Rule>Backward</Rule>
<EndOfMonth>false</EndOfMonth>
<FirstDate/>
<LastDate/>
</Rules>
</ScheduleData>
</LegData>
</SwapData>
</Trade>
<Trade id="local_includeSpread">
<TradeType>Swap</TradeType>
<Envelope>
<CounterParty>CPTY_A</CounterParty>
<NettingSetId>CPTY_A</NettingSetId>
<AdditionalFields/>
</Envelope>
<SwapData>
<LegData>
<LegType>Floating</LegType>
<Payer>false</Payer>
<Currency>EUR</Currency>
<Notionals>
<Notional>100000000</Notional>
</Notionals>
<DayCounter>A360</DayCounter>
<PaymentConvention>MF</PaymentConvention>
<FloatingLegData>
<Index>EUR-EONIA</Index>
<FixingDays>0</FixingDays>
<Lookback>0D</Lookback>
<RateCutoff>2</RateCutoff>
<IncludeSpread>true</IncludeSpread>
<Spreads>
<Spread>0.01</Spread>
</Spreads>
<Floors>
<Floor>0.0</Floor>
</Floors>
<NakedOption>false</NakedOption>
<LocalCapFloor>true</LocalCapFloor>
</FloatingLegData>
<ScheduleData>
<Rules>
<StartDate>20201130</StartDate>
<EndDate>20221130</EndDate>
<Tenor>3M</Tenor>
<Calendar>US</Calendar>
<Convention>MF</Convention>
<TermConvention>MF</TermConvention>
<Rule>Backward</Rule>
<EndOfMonth>false</EndOfMonth>
<FirstDate/>
<LastDate/>
</Rules>
</ScheduleData>
</LegData>
</SwapData>
</Trade>
</Portfolio>
On Fri, 30 Apr 2021 at 21:41, Christofer Bogaso
<bog...@gm...> wrote:
>
> Hi,
>
> I will really appreciate it if someone can show any example on the
> subject below.
>
> Thanks and regards,
>
> On Fri, Apr 9, 2021 at 3:53 PM Christofer Bogaso
> <bog...@gm...> wrote:
> >
> > Great, thanks!
> >
> > Just wondering if there is any example on this implementation either
> > in C++ or Python. The payoff of such instruments is based on
> > Arithmetic/Geometric average of OI rate over the tenor.
> >
> > Thanks and regards,
> >
> > On Fri, Apr 9, 2021 at 1:16 PM Peter Caspers <pca...@gm...> wrote:
> > >
> > > Hi Christofer, this is released code, so you can do it today.
> > > Thanks, Peter
> > >
> > > On Sun, 21 Mar 2021 at 19:46, Christofer Bogaso
> > > <bog...@gm...> wrote:
> > > >
> > > > Thanks.
> > > >
> > > > Do we have any timeline when cap / floor pricing for ON coupons will
> > > > be available?
> > > >
> > > > Also, some workout examples will be super helpful.
> > > >
> > > > On Sat, Mar 20, 2021 at 12:55 AM Peter Caspers <pca...@gm...> wrote:
> > > > >
> > > > > Hi Christofer,
> > > > >
> > > > > we have added a pricer here
> > > > >
> > > > > https://github.com/OpenSourceRisk/Engine/blob/master/QuantExt/qle/cashflows/blackovernightindexedcouponpricer.hpp
> > > > >
> > > > > inspired by Lyanshenko / Mercurio, Looking forward to backward looking
> > > > > rates, section 6.3. Currently there are only the old Libor
> > > > > volatilities available as far as I know. I'd expect that there will be
> > > > > new volatility quotes in the future and some sort of market formula
> > > > > that translates those into standard cap prices. Therefore the
> > > > > implementation should be seen as preliminary and proprietary, there
> > > > > are other possible approaches. We'll update the method as soon as the
> > > > > market develops. I should also mention that there is a bug in the
> > > > > github code, line 70 in the cpp should be
> > > > >
> > > > > Real stdDev = sigma * std::sqrt(std::max(fixingStartTime, 0.0) +
> > > > > std::pow(fixingEndTime -
> > > > > std::max(fixingStartTime, 0.0), 3.0) /
> > > > > std::pow(fixingEndTime -
> > > > > fixingStartTime, 2.0) / 3.0);
> > > > >
> > > > > which will be in the next ORE release. We also added daily (or
> > > > > "local") cap / floor pricing for ON coupons, which will be available
> > > > > in that release as well. Hope that helps in one way or the other. Any
> > > > > feedback or discussions around this topic are welcome!
> > > > >
> > > > > Thanks
> > > > > Peter
> > > > >
> > > > > On Wed, 17 Mar 2021 at 18:39, Christofer Bogaso
> > > > > <bog...@gm...> wrote:
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I am just wondering if there is any implementation to price some
> > > > > > Interest Rate Caps and Swaptions where payoff is based on Overnight
> > > > > > rate contrary to present Libor references.
> > > > > >
> > > > > > So far I can only see QL implementation based on Libor.
> > > > > >
> > > > > > Any reference to OI based pricing would be appreciated.
> > > > > >
> > > > > > Thanks and regards,
> > > > > >
> > > > > >
> > > > > > _______________________________________________
> > > > > > QuantLib-users mailing list
> > > > > > Qua...@li...
> > > > > > https://lists.sourceforge.net/lists/listinfo/quantlib-users
|
|
From: Christofer B. <bog...@gm...> - 2021-04-30 19:41:44
|
Hi, I will really appreciate it if someone can show any example on the subject below. Thanks and regards, On Fri, Apr 9, 2021 at 3:53 PM Christofer Bogaso <bog...@gm...> wrote: > > Great, thanks! > > Just wondering if there is any example on this implementation either > in C++ or Python. The payoff of such instruments is based on > Arithmetic/Geometric average of OI rate over the tenor. > > Thanks and regards, > > On Fri, Apr 9, 2021 at 1:16 PM Peter Caspers <pca...@gm...> wrote: > > > > Hi Christofer, this is released code, so you can do it today. > > Thanks, Peter > > > > On Sun, 21 Mar 2021 at 19:46, Christofer Bogaso > > <bog...@gm...> wrote: > > > > > > Thanks. > > > > > > Do we have any timeline when cap / floor pricing for ON coupons will > > > be available? > > > > > > Also, some workout examples will be super helpful. > > > > > > On Sat, Mar 20, 2021 at 12:55 AM Peter Caspers <pca...@gm...> wrote: > > > > > > > > Hi Christofer, > > > > > > > > we have added a pricer here > > > > > > > > https://github.com/OpenSourceRisk/Engine/blob/master/QuantExt/qle/cashflows/blackovernightindexedcouponpricer.hpp > > > > > > > > inspired by Lyanshenko / Mercurio, Looking forward to backward looking > > > > rates, section 6.3. Currently there are only the old Libor > > > > volatilities available as far as I know. I'd expect that there will be > > > > new volatility quotes in the future and some sort of market formula > > > > that translates those into standard cap prices. Therefore the > > > > implementation should be seen as preliminary and proprietary, there > > > > are other possible approaches. We'll update the method as soon as the > > > > market develops. I should also mention that there is a bug in the > > > > github code, line 70 in the cpp should be > > > > > > > > Real stdDev = sigma * std::sqrt(std::max(fixingStartTime, 0.0) + > > > > std::pow(fixingEndTime - > > > > std::max(fixingStartTime, 0.0), 3.0) / > > > > std::pow(fixingEndTime - > > > > fixingStartTime, 2.0) / 3.0); > > > > > > > > which will be in the next ORE release. We also added daily (or > > > > "local") cap / floor pricing for ON coupons, which will be available > > > > in that release as well. Hope that helps in one way or the other. Any > > > > feedback or discussions around this topic are welcome! > > > > > > > > Thanks > > > > Peter > > > > > > > > On Wed, 17 Mar 2021 at 18:39, Christofer Bogaso > > > > <bog...@gm...> wrote: > > > > > > > > > > Hi, > > > > > > > > > > I am just wondering if there is any implementation to price some > > > > > Interest Rate Caps and Swaptions where payoff is based on Overnight > > > > > rate contrary to present Libor references. > > > > > > > > > > So far I can only see QL implementation based on Libor. > > > > > > > > > > Any reference to OI based pricing would be appreciated. > > > > > > > > > > Thanks and regards, > > > > > > > > > > > > > > > _______________________________________________ > > > > > QuantLib-users mailing list > > > > > Qua...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/quantlib-users |
|
From: HB <kar...@gm...> - 2021-04-21 02:17:14
|
Hi all,
I would really appreciate any insights on how to properly re-price the CDS
used to bootstrap a survival probability curve.
After building a survival probability curve from CDS instruments, I
re-price the calibration instruments as a sanity check, however the NPV of
the re-priced CDS is not zero.
The attached file is a minimal working example.
Using the first CDS as an example, if in each `SpreadCdsHelper` I use
`model == CreditDefaultSwap::ISDA` and as pricing engine the
`MidPointCdsEngine`, then I get an NPV of ~17 cents. If the pricing engine
is changed to `IsdaCdsEngine` (so that, on the surface, appears consistent
with the model), then the NPV becomes a whooping ~ $22:
-- Repricing the first instrument used for calibration:
-- par spread: 0.792734 %
NPV: -0.176124
default leg: -4143.93
coupon leg: 4143.75
-- Repricing the first instrument used for calibration:
-- par spread: 0.796878 %
NPV: -21.8426
default leg: -4165.85
coupon leg: 4144.01
Thanks in advance and best regards,
HB
|
|
From: Luigi B. <lui...@gm...> - 2021-04-16 07:12:51
|
Hello,
no, in general the parameters that describe the contract for the
instrument (as opposed to market quotes) can't be changed once the
instrument is created.
Luigi
On Mon, Apr 12, 2021 at 7:58 PM jian Xu <jia...@gm...> wrote:
> Make sense. So is there a way to change the spread of a
> floatingRateBond after the object is constructed? If yes, then I can
> bump the spread up and down to avoid bumping the index up and down.
> This should have the same impact, and it won't affect other bonds.
>
> On Mon, Apr 12, 2021 at 9:09 AM Luigi Ballabio <lui...@gm...>
> wrote:
> >
> > Jian,
> > the idea behind it is that, if that were possible, one could be
> given a bond and through that be able to affect any other bonds that use
> the same index or forecast curve. We thought that this made it too easy to
> do the wrong thing without realizing it.
> >
> > Luigi
> >
> >
> > On Mon, Apr 12, 2021 at 3:30 PM jian Xu <jia...@gm...> wrote:
> >>
> >> I see. I know how to use the original curve to calculate the interest
> >> rate sensitivity. But not being able to extract it from the index
> >> seems a bit surprising to me. Because for a fixedRateBond, the IR
> >> sensitivity interface is simply
> >>
> >> def sensitivity(fixedRatebond, y):
> >>
> >> But for a floating rate bond, it becomes:
> >>
> >> def sensitivity(floatingRateBond, y, forecast_curve):
> >>
> >> If we can extract the forecast_curve from the index from the
> >> floatingRateBond, then the two API could be unified, which seems more
> >> reasonable to me.
> >>
> >> Jian
> >>
> >> On Mon, Apr 12, 2021 at 2:24 AM Luigi Ballabio <
> lui...@gm...> wrote:
> >> >
> >> > Hello,
> >> > the term structure that you can retrieve from the index can't be
> relinked. Instead, you should keep hold of the one you originally used to
> build the index and bump that one. The index will react accordingly.
> >> >
> >> > Hope this helps,
> >> > Luigi
> >> >
> >> >
> >> > On Sun, Apr 11, 2021 at 4:42 PM jian Xu <jia...@gm...> wrote:
> >> >>
> >> >> Can anyone help here? I think I'm already very close. There ought
> to
> >> >> be a way to bump the index, either buy relink it to a bumped curve,
> or
> >> >> by some other means. This should be a common practice when we want
> to
> >> >> calculate the interest rate sensitivity of a floating rate bond,
> >> >> shouldn't it?
> >> >>
> >> >> Thanks.
> >> >>
> >> >> On Fri, Apr 9, 2021 at 2:49 PM jian Xu <jia...@gm...> wrote:
> >> >> >
> >> >> > But after I get the index, how to bump the index? What I'm trying
> to
> >> >> > do is to calculate the cashflows when the index curve is bumped up,
> >> >> > say 0.0001, in parallel. I have the floating rate bond already
> >> >> > constructed, then
> >> >> >
> >> >> > bond = ql.FloatingRateBond(...)
> >> >> > cpn = ql.as_floating_rate_coupon(bond.cashflows()[0])
> >> >> > ibor = ql.as_iborindex(cpn.index())
> >> >> > forecast_curve = ibor.forwardingTermStructure()
> >> >> >
> >> >> > But how do I bump the forecast_curve? I can create a bumped
> forecast
> >> >> > curve like the following:
> >> >> >
> >> >> > forecast_curve_bumped =
> ql.ZeroSpreadedTermStructure(forecast_curve,
> >> >> > ql.QuoteHandle(ql.SimpleQuote(.0001)))
> >> >> >
> >> >> > But then how do I link the index to this bumped curve, so that the
> >> >> > bond's cashflow will be impacted? Thanks.
> >> >> >
> >> >> >
> >> >> > On Fri, Apr 9, 2021 at 11:57 AM jian Xu <jia...@gm...>
> wrote:
> >> >> > >
> >> >> > > I see. Thanks!
> >> >> > >
> >> >> > > On Fri, Apr 9, 2021 at 4:31 AM Luigi Ballabio <
> lui...@gm...> wrote:
> >> >> > > >
> >> >> > > > As David said — or you can avoid the map by selecting the
> first coupon before conversion:
> >> >> > > >
> >> >> > > > c = ql.as_floating_rate_coupon(bnd.cashflows()[0])
> >> >> > > > myindex = c.index()
> >> >> > > >
> >> >> > > >
> >> >> > > > On Fri, Apr 9, 2021 at 10:25 AM David Duarte <nh...@gm...>
> wrote:
> >> >> > > >>
> >> >> > > >> Hi,
> >> >> > > >>
> >> >> > > >> I'm not sure the index is exposed for the bond object, but
> you can extract it from the cashflows.
> >> >> > > >> Maybe not the easiest way to go about it, but hopefully
> you'll get the idea:
> >> >> > > >>
> >> >> > > >> bnd = ql.FloatingRateBond(...)
> >> >> > > >> c = [*map(ql.as_floating_rate_coupon, bnd.cashflows())][0]
> >> >> > > >> myindex = c.index()
> >> >> > > >>
> >> >> > > >> Regards,
> >> >> > > >> David
> >> >> > > >>
> >> >> > > >> On Fri, 9 Apr 2021 at 03:03, jian Xu <jia...@gm...>
> wrote:
> >> >> > > >>>
> >> >> > > >>> Hi,
> >> >> > > >>>
> >> >> > > >>> An index is passed in duration the construction of a
> FloatingRateBond,
> >> >> > > >>> But after that, given the FloatingRateBond object, how do I
> get the
> >> >> > > >>> index back (in Python)? Thanks.
> >> >> > > >>>
> >> >> > > >>> Jian
> >> >> > > >>>
> >> >> > > >>>
> >> >> > > >>> _______________________________________________
> >> >> > > >>> 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
>
|
|
From: Luigi B. <lui...@gm...> - 2021-04-15 13:28:55
|
QuantLib 1.22 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>. |
|
From: Marcin R. <mry...@gm...> - 2021-04-14 22:12:11
|
Hi Luigi, Many thanks for clarifying. I was able to compile SWIG Python with the instructions that you provided and the tests ran successfully. Only in my case including the —disable-shared flag lead to unresolved symbol error when running the tests. After compiling the library again without this flag, all worked fine. Many thanks, Marcin On Tue, 13 Apr 2021 at 12:13, Luigi Ballabio <lui...@gm...> wrote: > Thanks, Marcin. On OS X 10.14 the existing instructions worked (after > adding -std=c+11, because clang still defaults to C++03) for Python >= 3.7, > while 3.6 failed. Instead, the following seems to work with all versions > still supported, that is, 3.6 and above: > > For QuantLib, same as written in the instructions on the site: > ./configure --disable-shared CXXFLAGS='-O2 -g0 -std=c++11 > -stdlib=libc++ -mmacosx-version-min=10.9' LDFLAGS='-stdlib=libc++ > -mmacosx-version-min=10.9' > make > make install > > (The --disable-shared flag is suggested on the site and results in a > self-contained Python module instead of one that requires a dynamic library > for QuantLib installed.) > > For QuantLib-Python, forget about configure and run: > > cd Python > CXXFLAGS='-O2 -g0 -std=c++11 -stdlib=libc++ -mmacosx-version-min=10.9' > LDFLAGS='-stdlib=libc++ -mmacosx-version-min=10.9' python3 setup.py build > python3 setup.py test > python3 setup.py install > > (you can replace python3 with whatever Python you want to use: for > instance /Library/Frameworks/Python.framework/Versions/3.9/bin/python3) > > Please let me know if this works for you too. If so, I'll update the > instructions. > > Luigi > > > > On Mon, Apr 12, 2021 at 7:06 PM Marcin Rybacki <mry...@gm...> > wrote: > >> Hi Luigi, >> >> I hope it is yet not too late to send feedback. >> >> On a Windows 10 machine I see the following after compiling the library: >> >> Running 884 test cases... >> >> Tests completed in 9 m 50 s >> >> *** No errors detected >> >> >> Building QuantLib-SWIG and running Python tests gives: >> ---------------------------------------------------------------------- >> Ran 125 tests in 19.243s >> >> OK >> >> On OS X 10.15.6 I was able to compile the library and successfully run >> the unit tests, but only after adding -std=c++11 flag to CXXFLAGS. >> I could not get SWIG Python to compile, I struggled a bit which flags >> should be used in ./configure. >> Hence, perhaps it might be good to update the installation instructions >> for Mac OS X to reflect that? Unless this is just due to my local setup. >> >> Many thanks, >> Marcin >> >> On Thu, 1 Apr 2021 at 15:24, Luigi Ballabio <lui...@gm...> >> wrote: >> >>> Hello everybody, >>> I published release candidates for version 1.22 at < >>> https://github.com/lballabio/QuantLib/releases/tag/1.22rc>. If you >>> have some time in the next week or two, I'd appreciate your feedback. >>> >>> Have a nice Easter break, >>> Luigi >>> >>> >>> _______________________________________________ >>> QuantLib-users mailing list >>> Qua...@li... >>> https://lists.sourceforge.net/lists/listinfo/quantlib-users >>> >> |
|
From: Eric E. <eri...@re...> - 2021-04-13 11:43:02
|
Hi All, A preliminary build of QuantLibXL version 1.22 is available at this link: https://bintray.com/quantlib/prerelease/QuantLibXL/1.22_prerelease#files I would be grateful to anyone who could test it and let me know if it's OK. I believe that I have merged all of the pull requests that I have received, and responded to other queries. If I forgot anything please let me know. Kind Regards, Eric |
|
From: Luigi B. <lui...@gm...> - 2021-04-13 10:13:48
|
Thanks, Marcin. On OS X 10.14 the existing instructions worked (after
adding -std=c+11, because clang still defaults to C++03) for Python >= 3.7,
while 3.6 failed. Instead, the following seems to work with all versions
still supported, that is, 3.6 and above:
For QuantLib, same as written in the instructions on the site:
./configure --disable-shared CXXFLAGS='-O2 -g0 -std=c++11
-stdlib=libc++ -mmacosx-version-min=10.9' LDFLAGS='-stdlib=libc++
-mmacosx-version-min=10.9'
make
make install
(The --disable-shared flag is suggested on the site and results in a
self-contained Python module instead of one that requires a dynamic library
for QuantLib installed.)
For QuantLib-Python, forget about configure and run:
cd Python
CXXFLAGS='-O2 -g0 -std=c++11 -stdlib=libc++ -mmacosx-version-min=10.9'
LDFLAGS='-stdlib=libc++ -mmacosx-version-min=10.9' python3 setup.py build
python3 setup.py test
python3 setup.py install
(you can replace python3 with whatever Python you want to use: for instance
/Library/Frameworks/Python.framework/Versions/3.9/bin/python3)
Please let me know if this works for you too. If so, I'll update the
instructions.
Luigi
On Mon, Apr 12, 2021 at 7:06 PM Marcin Rybacki <mry...@gm...> wrote:
> Hi Luigi,
>
> I hope it is yet not too late to send feedback.
>
> On a Windows 10 machine I see the following after compiling the library:
>
> Running 884 test cases...
>
> Tests completed in 9 m 50 s
>
> *** No errors detected
>
>
> Building QuantLib-SWIG and running Python tests gives:
> ----------------------------------------------------------------------
> Ran 125 tests in 19.243s
>
> OK
>
> On OS X 10.15.6 I was able to compile the library and successfully run the
> unit tests, but only after adding -std=c++11 flag to CXXFLAGS.
> I could not get SWIG Python to compile, I struggled a bit which flags
> should be used in ./configure.
> Hence, perhaps it might be good to update the installation instructions
> for Mac OS X to reflect that? Unless this is just due to my local setup.
>
> Many thanks,
> Marcin
>
> On Thu, 1 Apr 2021 at 15:24, Luigi Ballabio <lui...@gm...>
> wrote:
>
>> Hello everybody,
>> I published release candidates for version 1.22 at <
>> https://github.com/lballabio/QuantLib/releases/tag/1.22rc>. If you have
>> some time in the next week or two, I'd appreciate your feedback.
>>
>> Have a nice Easter break,
>> Luigi
>>
>>
>> _______________________________________________
>> QuantLib-users mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-users
>>
>
|
|
From: jian Xu <jia...@gm...> - 2021-04-12 17:59:00
|
Make sense. So is there a way to change the spread of a floatingRateBond after the object is constructed? If yes, then I can bump the spread up and down to avoid bumping the index up and down. This should have the same impact, and it won't affect other bonds. On Mon, Apr 12, 2021 at 9:09 AM Luigi Ballabio <lui...@gm...> wrote: > > Jian, > the idea behind it is that, if that were possible, one could be given a bond and through that be able to affect any other bonds that use the same index or forecast curve. We thought that this made it too easy to do the wrong thing without realizing it. > > Luigi > > > On Mon, Apr 12, 2021 at 3:30 PM jian Xu <jia...@gm...> wrote: >> >> I see. I know how to use the original curve to calculate the interest >> rate sensitivity. But not being able to extract it from the index >> seems a bit surprising to me. Because for a fixedRateBond, the IR >> sensitivity interface is simply >> >> def sensitivity(fixedRatebond, y): >> >> But for a floating rate bond, it becomes: >> >> def sensitivity(floatingRateBond, y, forecast_curve): >> >> If we can extract the forecast_curve from the index from the >> floatingRateBond, then the two API could be unified, which seems more >> reasonable to me. >> >> Jian >> >> On Mon, Apr 12, 2021 at 2:24 AM Luigi Ballabio <lui...@gm...> wrote: >> > >> > Hello, >> > the term structure that you can retrieve from the index can't be relinked. Instead, you should keep hold of the one you originally used to build the index and bump that one. The index will react accordingly. >> > >> > Hope this helps, >> > Luigi >> > >> > >> > On Sun, Apr 11, 2021 at 4:42 PM jian Xu <jia...@gm...> wrote: >> >> >> >> Can anyone help here? I think I'm already very close. There ought to >> >> be a way to bump the index, either buy relink it to a bumped curve, or >> >> by some other means. This should be a common practice when we want to >> >> calculate the interest rate sensitivity of a floating rate bond, >> >> shouldn't it? >> >> >> >> Thanks. >> >> >> >> On Fri, Apr 9, 2021 at 2:49 PM jian Xu <jia...@gm...> wrote: >> >> > >> >> > But after I get the index, how to bump the index? What I'm trying to >> >> > do is to calculate the cashflows when the index curve is bumped up, >> >> > say 0.0001, in parallel. I have the floating rate bond already >> >> > constructed, then >> >> > >> >> > bond = ql.FloatingRateBond(...) >> >> > cpn = ql.as_floating_rate_coupon(bond.cashflows()[0]) >> >> > ibor = ql.as_iborindex(cpn.index()) >> >> > forecast_curve = ibor.forwardingTermStructure() >> >> > >> >> > But how do I bump the forecast_curve? I can create a bumped forecast >> >> > curve like the following: >> >> > >> >> > forecast_curve_bumped = ql.ZeroSpreadedTermStructure(forecast_curve, >> >> > ql.QuoteHandle(ql.SimpleQuote(.0001))) >> >> > >> >> > But then how do I link the index to this bumped curve, so that the >> >> > bond's cashflow will be impacted? Thanks. >> >> > >> >> > >> >> > On Fri, Apr 9, 2021 at 11:57 AM jian Xu <jia...@gm...> wrote: >> >> > > >> >> > > I see. Thanks! >> >> > > >> >> > > On Fri, Apr 9, 2021 at 4:31 AM Luigi Ballabio <lui...@gm...> wrote: >> >> > > > >> >> > > > As David said — or you can avoid the map by selecting the first coupon before conversion: >> >> > > > >> >> > > > c = ql.as_floating_rate_coupon(bnd.cashflows()[0]) >> >> > > > myindex = c.index() >> >> > > > >> >> > > > >> >> > > > On Fri, Apr 9, 2021 at 10:25 AM David Duarte <nh...@gm...> wrote: >> >> > > >> >> >> > > >> Hi, >> >> > > >> >> >> > > >> I'm not sure the index is exposed for the bond object, but you can extract it from the cashflows. >> >> > > >> Maybe not the easiest way to go about it, but hopefully you'll get the idea: >> >> > > >> >> >> > > >> bnd = ql.FloatingRateBond(...) >> >> > > >> c = [*map(ql.as_floating_rate_coupon, bnd.cashflows())][0] >> >> > > >> myindex = c.index() >> >> > > >> >> >> > > >> Regards, >> >> > > >> David >> >> > > >> >> >> > > >> On Fri, 9 Apr 2021 at 03:03, jian Xu <jia...@gm...> wrote: >> >> > > >>> >> >> > > >>> Hi, >> >> > > >>> >> >> > > >>> An index is passed in duration the construction of a FloatingRateBond, >> >> > > >>> But after that, given the FloatingRateBond object, how do I get the >> >> > > >>> index back (in Python)? Thanks. >> >> > > >>> >> >> > > >>> Jian >> >> > > >>> >> >> > > >>> >> >> > > >>> _______________________________________________ >> >> > > >>> 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 |
|
From: Marcin R. <mry...@gm...> - 2021-04-12 17:06:27
|
Hi Luigi, I hope it is yet not too late to send feedback. On a Windows 10 machine I see the following after compiling the library: Running 884 test cases... Tests completed in 9 m 50 s *** No errors detected Building QuantLib-SWIG and running Python tests gives: ---------------------------------------------------------------------- Ran 125 tests in 19.243s OK On OS X 10.15.6 I was able to compile the library and successfully run the unit tests, but only after adding -std=c++11 flag to CXXFLAGS. I could not get SWIG Python to compile, I struggled a bit which flags should be used in ./configure. Hence, perhaps it might be good to update the installation instructions for Mac OS X to reflect that? Unless this is just due to my local setup. Many thanks, Marcin On Thu, 1 Apr 2021 at 15:24, Luigi Ballabio <lui...@gm...> wrote: > Hello everybody, > I published release candidates for version 1.22 at < > https://github.com/lballabio/QuantLib/releases/tag/1.22rc>. If you have > some time in the next week or two, I'd appreciate your feedback. > > Have a nice Easter break, > Luigi > > > _______________________________________________ > QuantLib-users mailing list > Qua...@li... > https://lists.sourceforge.net/lists/listinfo/quantlib-users > |
|
From: Luigi B. <lui...@gm...> - 2021-04-12 14:10:17
|
Jian,
the idea behind it is that, if that were possible, one could be given a
bond and through that be able to affect any other bonds that use the same
index or forecast curve. We thought that this made it too easy to do the
wrong thing without realizing it.
Luigi
On Mon, Apr 12, 2021 at 3:30 PM jian Xu <jia...@gm...> wrote:
> I see. I know how to use the original curve to calculate the interest
> rate sensitivity. But not being able to extract it from the index
> seems a bit surprising to me. Because for a fixedRateBond, the IR
> sensitivity interface is simply
>
> def sensitivity(fixedRatebond, y):
>
> But for a floating rate bond, it becomes:
>
> def sensitivity(floatingRateBond, y, forecast_curve):
>
> If we can extract the forecast_curve from the index from the
> floatingRateBond, then the two API could be unified, which seems more
> reasonable to me.
>
> Jian
>
> On Mon, Apr 12, 2021 at 2:24 AM Luigi Ballabio <lui...@gm...>
> wrote:
> >
> > Hello,
> > the term structure that you can retrieve from the index can't be
> relinked. Instead, you should keep hold of the one you originally used to
> build the index and bump that one. The index will react accordingly.
> >
> > Hope this helps,
> > Luigi
> >
> >
> > On Sun, Apr 11, 2021 at 4:42 PM jian Xu <jia...@gm...> wrote:
> >>
> >> Can anyone help here? I think I'm already very close. There ought to
> >> be a way to bump the index, either buy relink it to a bumped curve, or
> >> by some other means. This should be a common practice when we want to
> >> calculate the interest rate sensitivity of a floating rate bond,
> >> shouldn't it?
> >>
> >> Thanks.
> >>
> >> On Fri, Apr 9, 2021 at 2:49 PM jian Xu <jia...@gm...> wrote:
> >> >
> >> > But after I get the index, how to bump the index? What I'm trying to
> >> > do is to calculate the cashflows when the index curve is bumped up,
> >> > say 0.0001, in parallel. I have the floating rate bond already
> >> > constructed, then
> >> >
> >> > bond = ql.FloatingRateBond(...)
> >> > cpn = ql.as_floating_rate_coupon(bond.cashflows()[0])
> >> > ibor = ql.as_iborindex(cpn.index())
> >> > forecast_curve = ibor.forwardingTermStructure()
> >> >
> >> > But how do I bump the forecast_curve? I can create a bumped forecast
> >> > curve like the following:
> >> >
> >> > forecast_curve_bumped = ql.ZeroSpreadedTermStructure(forecast_curve,
> >> > ql.QuoteHandle(ql.SimpleQuote(.0001)))
> >> >
> >> > But then how do I link the index to this bumped curve, so that the
> >> > bond's cashflow will be impacted? Thanks.
> >> >
> >> >
> >> > On Fri, Apr 9, 2021 at 11:57 AM jian Xu <jia...@gm...> wrote:
> >> > >
> >> > > I see. Thanks!
> >> > >
> >> > > On Fri, Apr 9, 2021 at 4:31 AM Luigi Ballabio <
> lui...@gm...> wrote:
> >> > > >
> >> > > > As David said — or you can avoid the map by selecting the first
> coupon before conversion:
> >> > > >
> >> > > > c = ql.as_floating_rate_coupon(bnd.cashflows()[0])
> >> > > > myindex = c.index()
> >> > > >
> >> > > >
> >> > > > On Fri, Apr 9, 2021 at 10:25 AM David Duarte <nh...@gm...>
> wrote:
> >> > > >>
> >> > > >> Hi,
> >> > > >>
> >> > > >> I'm not sure the index is exposed for the bond object, but you
> can extract it from the cashflows.
> >> > > >> Maybe not the easiest way to go about it, but hopefully you'll
> get the idea:
> >> > > >>
> >> > > >> bnd = ql.FloatingRateBond(...)
> >> > > >> c = [*map(ql.as_floating_rate_coupon, bnd.cashflows())][0]
> >> > > >> myindex = c.index()
> >> > > >>
> >> > > >> Regards,
> >> > > >> David
> >> > > >>
> >> > > >> On Fri, 9 Apr 2021 at 03:03, jian Xu <jia...@gm...>
> wrote:
> >> > > >>>
> >> > > >>> Hi,
> >> > > >>>
> >> > > >>> An index is passed in duration the construction of a
> FloatingRateBond,
> >> > > >>> But after that, given the FloatingRateBond object, how do I
> get the
> >> > > >>> index back (in Python)? Thanks.
> >> > > >>>
> >> > > >>> Jian
> >> > > >>>
> >> > > >>>
> >> > > >>> _______________________________________________
> >> > > >>> 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
>
|
|
From: jian Xu <jia...@gm...> - 2021-04-12 13:30:26
|
I see. I know how to use the original curve to calculate the interest rate sensitivity. But not being able to extract it from the index seems a bit surprising to me. Because for a fixedRateBond, the IR sensitivity interface is simply def sensitivity(fixedRatebond, y): But for a floating rate bond, it becomes: def sensitivity(floatingRateBond, y, forecast_curve): If we can extract the forecast_curve from the index from the floatingRateBond, then the two API could be unified, which seems more reasonable to me. Jian On Mon, Apr 12, 2021 at 2:24 AM Luigi Ballabio <lui...@gm...> wrote: > > Hello, > the term structure that you can retrieve from the index can't be relinked. Instead, you should keep hold of the one you originally used to build the index and bump that one. The index will react accordingly. > > Hope this helps, > Luigi > > > On Sun, Apr 11, 2021 at 4:42 PM jian Xu <jia...@gm...> wrote: >> >> Can anyone help here? I think I'm already very close. There ought to >> be a way to bump the index, either buy relink it to a bumped curve, or >> by some other means. This should be a common practice when we want to >> calculate the interest rate sensitivity of a floating rate bond, >> shouldn't it? >> >> Thanks. >> >> On Fri, Apr 9, 2021 at 2:49 PM jian Xu <jia...@gm...> wrote: >> > >> > But after I get the index, how to bump the index? What I'm trying to >> > do is to calculate the cashflows when the index curve is bumped up, >> > say 0.0001, in parallel. I have the floating rate bond already >> > constructed, then >> > >> > bond = ql.FloatingRateBond(...) >> > cpn = ql.as_floating_rate_coupon(bond.cashflows()[0]) >> > ibor = ql.as_iborindex(cpn.index()) >> > forecast_curve = ibor.forwardingTermStructure() >> > >> > But how do I bump the forecast_curve? I can create a bumped forecast >> > curve like the following: >> > >> > forecast_curve_bumped = ql.ZeroSpreadedTermStructure(forecast_curve, >> > ql.QuoteHandle(ql.SimpleQuote(.0001))) >> > >> > But then how do I link the index to this bumped curve, so that the >> > bond's cashflow will be impacted? Thanks. >> > >> > >> > On Fri, Apr 9, 2021 at 11:57 AM jian Xu <jia...@gm...> wrote: >> > > >> > > I see. Thanks! >> > > >> > > On Fri, Apr 9, 2021 at 4:31 AM Luigi Ballabio <lui...@gm...> wrote: >> > > > >> > > > As David said — or you can avoid the map by selecting the first coupon before conversion: >> > > > >> > > > c = ql.as_floating_rate_coupon(bnd.cashflows()[0]) >> > > > myindex = c.index() >> > > > >> > > > >> > > > On Fri, Apr 9, 2021 at 10:25 AM David Duarte <nh...@gm...> wrote: >> > > >> >> > > >> Hi, >> > > >> >> > > >> I'm not sure the index is exposed for the bond object, but you can extract it from the cashflows. >> > > >> Maybe not the easiest way to go about it, but hopefully you'll get the idea: >> > > >> >> > > >> bnd = ql.FloatingRateBond(...) >> > > >> c = [*map(ql.as_floating_rate_coupon, bnd.cashflows())][0] >> > > >> myindex = c.index() >> > > >> >> > > >> Regards, >> > > >> David >> > > >> >> > > >> On Fri, 9 Apr 2021 at 03:03, jian Xu <jia...@gm...> wrote: >> > > >>> >> > > >>> Hi, >> > > >>> >> > > >>> An index is passed in duration the construction of a FloatingRateBond, >> > > >>> But after that, given the FloatingRateBond object, how do I get the >> > > >>> index back (in Python)? Thanks. >> > > >>> >> > > >>> Jian >> > > >>> >> > > >>> >> > > >>> _______________________________________________ >> > > >>> 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 |