lballabio / quantlib Goto Github PK

Say you have a CompositeInstrument with one VanillaOption component and you shift forward the evaluation date. If the component expires during that, the composite does as well (which is fine). If you now move the evaluation date back such that the component is live again, the composite won't recompute (although its isExpired() method says false). This is because the last notification sent from the component is the one from the date shift that caused its expiry. The component will then stay in state calculated_ == false and therefore won't fire any more notifications to the composite wrapper. The wrapper on the other hand will be in state calculated_ == true once it identified itself as expired, see the calculate() implementation in Instrument. This can be confirmed by manually calling update() on the composite, which will trigger recalculation and give the correct NPV again.

If I include multicurvesensitivities.hpp twice in my project, it will cause "error LNK2005".
To solve the problem, you can separate the declaration in the header file, and definition in cpp file.

I believe in line 855 of cashflows.cpp you want to use CashFlowLess{}

#if defined(QL_EXTRA_SAFETY_CHECKS)
        QL_REQUIRE(std::is_sorted(leg.begin(), leg.end(), CashFlowLess{}),
                   "cashflows must be sorted in ascending order w.r.t. their payment dates");
#endif

Irrelevant to the issue but even though my config.hpp shows

/* Define this if extra safety checks should be performed. This can degrade
   performance. */
#undef QL_EXTRA_SAFETY_CHECKS

and there is no definition in userconfig.hpp either, VS2015 did complain about it with error C2065: 'cashFlowLess': undeclared identifier.
Have to look into that matter, because I do not want those checks in my release build.

Hi,

I just compiled QuantLib for the first time on Windows 10 using Microsoft Visual Studio 2015 using the Release and x64 option. The compiler throws the following warning:

1>C:\CppDev\openxva\QuantLib\ql/math/fastfouriertransform.hpp(49): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) (compiling source file ql\models\volatility\garch.cpp)
1>  gjrgarchmodel.cpp
1>  hestonmodel.cpp
1>C:\CppDev\openxva\QuantLib\ql/math/fastfouriertransform.hpp(90): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) (compiling source file ql\models\volatility\garch.cpp)
1>  C:\CppDev\openxva\QuantLib\ql/math/fastfouriertransform.hpp(68): note: see reference to function template instantiation 'void QuantLib::FastFourierTransform::transform_impl<InputIterator,RandomAccessIterator>(InputIterator,InputIterator,RandomAccessIterator,bool) const' being compiled
1>          with
1>          [
1>              InputIterator=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<double>>>,
1>              RandomAccessIterator=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<std::complex<double>>>>
1>          ] (compiling source file ql\models\volatility\garch.cpp)
1>  C:\CppDev\openxva\QuantLib\ql/math/autocovariance.hpp(47): note: see reference to function template instantiation 'void QuantLib::FastFourierTransform::transform<ForwardIterator,std::_Vector_iterator<std::_Vector_val<std::_Simple_types<std::complex<double>>>>>(InputIterator,InputIterator,RandomAccessIterator) const' being compiled
1>          with
1>          [
1>              ForwardIterator=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<double>>>,
1>              InputIterator=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<double>>>,
1>              RandomAccessIterator=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<std::complex<double>>>>
1>          ] (compiling source file ql\models\volatility\garch.cpp)
1>  C:\CppDev\openxva\QuantLib\ql/math/autocovariance.hpp(106): note: see reference to function template instantiation 'std::vector<std::complex<double>,std::allocator<_Ty>> QuantLib::detail::double_ft<ForwardIterator>(ForwardIterator,ForwardIterator)' being compiled
1>          with
1>          [
1>              _Ty=std::complex<double>,
1>              ForwardIterator=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<double>>>
1>          ] (compiling source file ql\models\volatility\garch.cpp)
1>  ql\models\volatility\garch.cpp(421): note: see reference to function template instantiation 'void QuantLib::autocovariances<std::_Vector_iterator<std::_Vector_val<std::_Simple_types<double>>>,QuantLib::Array::iterator>(ForwardIterator,ForwardIterator,OutputIterator,size_t)' being compiled
1>          with
1>          [
1>              ForwardIterator=std::_Vector_iterator<std::_Vector_val<std::_Simple_types<double>>>,
1>              OutputIterator=QuantLib::Array::iterator
1>          ]
1>C:\CppDev\openxva\QuantLib\ql/math/fastfouriertransform.hpp(97): warning C4334: '<<': result of 32-bit shift implicitly converted to 64 bits (was 64-bit shift intended?) (compiling source file ql\models\volatility\garch.cpp)

I'm too new to QuantLib to assess whether or not this warning is serious or if it can be ignored safely. I just know that bitshifts are quite essential to the Fast Fourier Transform, so one might want to double check that part of the code. I guess the warning stems from the fact that in ql/math/fastfouriertransform.hpp(49):

std::size_t m = 1 << order

the 1 is interpreted as a 32bit integer.

Hi, I have got pyql bindings to work, did the test and install and also looked at examples all fine for pyql using git clone https://github.com/enthought/pyql.git
cd pyql
python setup.py build
python setup.py test
python setup.py install, but not the SWIG Python bindings. On a mac, with Boost and Quantlib 1.7.1 installed, also the xcode command line tools etc. cd to QuantLib-SWIG-1.7/Python
then python setup.py build

and get the following - >

running build
running build_py
running build_ext
building 'QuantLib._QuantLib' extension
/usr/bin/clang -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -m32 -m32 -I/opt/local/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -I/opt/local/include -I/opt/local/include -c QuantLib/quantlib_wrap.cpp -o build/temp.macosx-10.9-x86_64-2.7/QuantLib/quantlib_wrap.o -Wno-unused -m32
In file included from QuantLib/quantlib_wrap.cpp:3940:
In file included from /opt/local/include/ql/quantlib.hpp:43:
In file included from /opt/local/include/ql/experimental/all.hpp:25:
In file included from /opt/local/include/ql/experimental/volatility/all.hpp:21:
In file included from /opt/local/include/ql/experimental/volatility/zabr.hpp:31:
In file included from /opt/local/include/ql/math/statistics/incrementalstatistics.hpp:35:
In file included from /opt/local/include/boost/accumulators/statistics/stats.hpp:14:
In file included from /opt/local/include/boost/accumulators/statistics_fwd.hpp:12:
/opt/local/include/boost/mpl/print.hpp:50:19: warning: in-class initialization
of non-static data member is a C++11 extension [-Wc++11-extensions]
const int m_x = 1 / (sizeof(T) - sizeof(T));
^
In file included from QuantLib/quantlib_wrap.cpp:3940:
In file included from /opt/local/include/ql/quantlib.hpp:47:
In file included from /opt/local/include/ql/math/all.hpp:38:
In file included from /opt/local/include/ql/math/matrixutilities/all.hpp:4:
In file included from /opt/local/include/ql/math/matrixutilities/basisincompleteordered.hpp:25:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/valarray:4032:59: error:
'value_type' is a private member of
'boost::iterators::detail::operator_brackets_proxy<QuantLib::step_iterator<double
*> >'
__val_expr<_BinaryOp<__bit_shift_left,
^
QuantLib/quantlib_wrap.cpp:7271:23: note: while substituting deduced template
arguments into function template 'operator<<' [with Expr =
boost::iterators::detail::operator_brackets_proxy<QuantLib::step_iterator<double
*> >]
s << (self)[i][j];
^
In file included from QuantLib/quantlib_wrap.cpp:3940:
In file included from /opt/local/include/ql/quantlib.hpp:47:
In file included from /opt/local/include/ql/math/all.hpp:38:
In file included from /opt/local/include/ql/math/matrixutilities/all.hpp:4:
In file included from /opt/local/include/ql/math/matrixutilities/basisincompleteordered.hpp:25:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/valarray:4033:46: error:
'value_type' is a private member of
'boost::iterators::detail::operator_brackets_proxy<QuantLib::step_iterator<double
*> >'
scalar_expr, Expr> >
^
QuantLib/quantlib_wrap.cpp:7356:62: warning: conversion from string literal to
'char *' is deprecated [-Wc++11-compat-deprecated-writable-strings]
PyObject pyResult = PyObject_CallFunction(function,"d",x);
^
QuantLib/quantlib_wrap.cpp:7364:43: warning: conversion from string literal to
'char ' is deprecated [-Wc++11-compat-deprecated-writable-strings]
PyObject_CallMethod(function,"derivative","d",x);
^
QuantLib/quantlib_wrap.cpp:7364:56: warning: conversion from string literal to
'char *' is deprecated [-Wc++11-compat-deprecated-writable-strings]
PyObject_CallMethod(function,"derivative","d",x);
^
QuantLib/quantlib_wrap.cpp:7396:62: warning: conversion from string literal to
'char *' is deprecated [-Wc++11-compat-deprecated-writable-strings]
PyObject pyResult = PyObject_CallFunction(function,"dd",x,y);
^
5 warnings and 2 errors generated.
error: command '/usr/bin/clang' failed with exit status 1

0336d01 seems to have introduced a bug where 4W tenor schedules can't be constructed:

RuntimeError: undecidable comparison between 4W and 1M

Caught this because it causes the PyQL test suite to break (I am a PyQL user).

I am trying to build the library but it failed

git clone [email protected]:lballabio/QuantLib.git
cd QuantLib && makdir build && cd build && cmake ..
make 

Here comes the error at the end of make

[100%] Building CXX object test-suite/CMakeFiles/quantlib-test-suite.dir/cashflows.cpp.o
Linking CXX executable quantlib-test-suite
/usr/lib/gcc/x86_64-linux-gnu/4.9/../../../x86_64-linux-gnu/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
CMakeFiles/quantlib-test-suite.dir/inflation.cpp.o: In function `boost::unit_test::make_test_case(boost::function<void ()> const&, boost::unit_test::basic_cstring<char const>, boost::unit_test::basic_cstring<char const>, unsigned long)':
inflation.cpp:(.text._ZN5boost9unit_test14make_test_caseERKNS_8functionIFvvEEENS0_13basic_cstringIKcEES8_m[_ZN5boost9unit_test14make_test_caseERKNS_8functionIFvvEEENS0_13basic_cstringIKcEES8_m]+0x48): undefined reference to `boost::unit_test::ut_detail::normalize_test_case_name(boost::unit_test::basic_cstring<char const>)'
collect2: error: ld returned 1 exit status
test-suite/CMakeFiles/quantlib-test-suite.dir/build.make:3562: recipe for target 'test-suite/quantlib-test-suite' failed
make[2]: *** [test-suite/quantlib-test-suite] Error 1
CMakeFiles/Makefile2:1091: recipe for target 'test-suite/CMakeFiles/quantlib-test-suite.dir/all' failed
make[1]: *** [test-suite/CMakeFiles/quantlib-test-suite.dir/all] Error 2
Makefile:76: recipe for target 'all' failed
make: *** [all] Error 2

How to fix this ?

I tried to download the tar.bz and build but that fails too.

Boost version 1.62.0.1
G++ version 4.9.2

What would be required in order to add CEV model for both closed form and lattice based pricing engines?

Something like this: http://www.math.psu.edu/cheng/BinomialCEV.m

Did not confirm if above is correct.

I think there is a problem in the ZeroCurve implementation (or I am using it the wrong way). Consider the following code:

DayCounter dayCounter = Actual365Fixed();
Date settlementDate(1, January, 2017);
Settings::instance().evaluationDate() = settlementDate;
std::vector<Date> rateDates
    {
        Date(1, January, 2018)
        Date(1, January, 2019)
    };
std::vector<double> rateValues
    {
        0.1,
        0.1
    };
ZeroCurve rateCurve(rateDates, rateValues, dayCounter);
std::cout << rateCurve.discount(Date(1, January, 2018));

I would expect to get a discount factor of exp(-0.1) ~ 0.9048. However, I do get 1.0000.

Here is why. In the InterpolatedZeroCurve class, the time offsets are build relative to the first date defining the rate curve:

this->times_[i] = dayCounter().yearFraction(dates_[0], dates_[i]);

and the reference date of TermStructure is also initialized to that date:

template <class T>
InterpolatedZeroCurve<T>::InterpolatedZeroCurve(
                                           const std::vector<Date>& dates,
                                           const std::vector<Rate>& yields,
                                           const DayCounter& dayCounter,
                                           const T& interpolator,
                                           Compounding compounding,
                                           Frequency frequency)
: ZeroYieldStructure(dates.at(0), Calendar(), dayCounter),
  InterpolatedCurve<T>(std::vector<Time>(), yields, interpolator),
  dates_(dates)
{
    initialize(compounding,frequency);
}

When calling .discount(...) on the ZeroCurve, the time used for the rate lookup/interpolation is computed relative to the reference date of that curve (correct):

inline
DiscountFactor YieldTermStructure::discount(const Date& d,
                                            bool extrapolate) const {
    return discount(timeFromReference(d), extrapolate);
}

But the discountImpl(...) also uses that same time (0.0 instead of 1.0 in my above example) to compute the discount factor itself in:

inline DiscountFactor ZeroYieldStructure::discountImpl(Time t) const {
    if (t == 0.0)     // this acts as a safe guard in cases where
        return 1.0;   // zeroYieldImpl(0.0) would throw.

    Rate r = zeroYieldImpl(t);
    return DiscountFactor(std::exp(-r*t));
}

I can get around this by always adding the evaluation date as the first pillar in the rate curve. However, in this seems inconsistent with the curve supporting extrapolation at the short end.

$ g++ --version
g++ (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609

Boost version: 1.62

Configured with options:
--prefix=... --exec-prefix=... --enable-parallel-unit-test-runner --enable-examples --enable-benchmark --enable-intraday --with-boost-include=... --with-boost-lib=...

The following errors appeared:

In file included from quantlibtestsuite.cpp:27:0:
paralleltestrunner.hpp: In function ‘int main(int, char*)’:
paralleltestrunner.hpp:239:26: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
s_log_impl().stream() << "Total number of test cases: "
^
paralleltestrunner.hpp:242:26: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
s_log_impl().stream() << "Total number of worker processes: "
^
paralleltestrunner.hpp:264:57: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
std::streambuf const oldBuf = s_log_impl().stream().rdbuf();
^
paralleltestrunner.hpp:265:26: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
s_log_impl().stream().rdbuf(logBuf.rdbuf());
^
paralleltestrunner.hpp:273:43: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
output_logstream(s_log_impl().stream(), oldBuf, logBuf);
^
paralleltestrunner.hpp:274:26: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
s_log_impl().stream().rdbuf(oldBuf);
^
paralleltestrunner.hpp:357:61: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
std::streambuf* const oldBuf = s_log_impl().stream().rdbuf();
^
paralleltestrunner.hpp:358:30: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
s_log_impl().stream().rdbuf(logBuf.rdbuf());
^
paralleltestrunner.hpp:363:47: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
output_logstream(s_log_impl().stream(), oldBuf, logBuf);
^
paralleltestrunner.hpp:364:30: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
s_log_impl().stream().rdbuf(oldBuf);
^
paralleltestrunner.hpp:391:57: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
std::streambuf* const oldBuf = s_log_impl().stream().rdbuf();
^
paralleltestrunner.hpp:392:26: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
s_log_impl().stream().rdbuf(logBuf.rdbuf());
^
paralleltestrunner.hpp:430:47: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
output_logstream(s_log_impl().stream(), oldBuf, logBuf);
^
paralleltestrunner.hpp:441:43: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
output_logstream(s_log_impl().stream(), oldBuf, logBuf);
^
paralleltestrunner.hpp:442:26: error: ‘struct boost::unit_test::{anonymous}::unit_test_log_impl’ has no member named ‘stream’
s_log_impl().stream().rdbuf(oldBuf);
^

Hello,

I am having trouble simply building QuantLib as a static library. My build fails with the following error:

/QuantLib-1.7.1/ql/termstructures/inflation/seasonality.cpp:215:10: 
Use of undeclared identifier 'KerkhofSeasonality'

I checked the header file for this, and the class is defined seemingly without an issue.

I am using the GNU++98 setting for the C++ Language Dialect (in XCode's Build Settings) and libstdc++ for the C++ Standard Library (this works with Quantlib-1.6.2). Any idea? This identical setup builds 1.6.2 just fine.

Thanks!

Recent change (43e90db)
put Disposable<Array> f_A(const SparseMatrix &g, const Array &x) into QuantLib::detail namespace.
This causes LNK2005 (violation of one definition rule) on Microsoft Visual Studio (tested on VS2015).

My usage:
In my project, I put some universal helper functions into a library util.lib and link this library to an executable together with QuantLib.

The error vanished when making the function static:

namespace QuantLib {

namespace detail {

static Disposable<Array> f_A(const SparseMatrix &g, const Array &x) {
    return prod(g, x);
};

} 

See https://en.wikipedia.org/wiki/Uniform_Monday_Holiday_Act.

Thanks to Nick Glass for the find.

This seems to be due to a miscompilation of std::min/std::max fixed in update 3 (see https://msdn.microsoft.com/en-us/library/mt752379.aspx). Thanks to Ivan Cherkasov for the heads-up.

Hello,

This subject was briefly discussed here.
I am trying to bootstrap a curve where instruments are swaps where the floating leg has compounding (a 3m ibor is observed every 3m, payment is made every 6m according to the formula
Notional x [(1 + d_1 r_1) (1 + d_2 r_2) - 1] where d's are day count fraction and r's are fixings.

As suggested, I am trying to build Floating Legs and then swaps with SubPeriodsCoupon.
Two issues for the moment:
#1
I clearly don't have yet a term structure model (the purpose is to build one).
However as it happens in the official Examples, my plan would be to create a relinkable one, assign it to my libor and eventually relink it along these lines:

QuantLib::RelinkableHandle<QuantLib::YieldTermStructure> liborTermStructure; boost::shared_ptr<QuantLib::IborIndex> cdor3m(new QuantLib::Cdor(tenor, liborTermStructure));
//create coupons boost::shared_ptr<QuantLib::SubPeriodsCoupon> sbc (new QuantLib::SubPeriodsCoupon(paymentDate, nominal, cdor3m, startDate, endDate, fixingDays, dayCounter, gearing, cSpread, rSpread, periodStart, periodEnd));
//create floating legs
//create fixed legs
//create swap
//bootstrapping here
//boost::shared_ptr<YieldTermStructure>swapTermStructure
//relink liborTermStructure.linkTo(swapTermStructure);
//price stuff

Ther issue is that code breaks at run-time because SubPeriodsCoupon is calling the ibor index term structure (and at the moment that is empty). I will check if the call can be avoided

const Handle<YieldTermStructure>& rateCurve = index->forwardingTermStructure(); const Date& referenceDate = rateCurve->referenceDate();

#2
I am trying to use the template function FloatingLeg which should take care of calling SubPeriodsCoupon (and I still expect to face #1).

QuantLib::Leg flLeg = QuantLib::FloatingLeg<QuantLib::IborIndex, QuantLib::SubPeriodsCoupon, QuantLib::CappedFlooredIborCoupon>(...)
SubPeriodsCoupon doesn't have a constructor along the same lines of e.g. floatingRateCoupon.
I have rearranged a bit the arguments order and added some defaults to see if I can fit it in.

SubPeriodsCoupon( const Date& paymentDate, Real nominal, const Date& startDate, const Date& endDate, Natural fixingDays, const boost::shared_ptr<IborIndex>& index, Real gearing, Rate couponSpread, // Spread added to the computed // averaging/compounding rate. const Date& refPeriodStart, const Date& refPeriodEnd, const DayCounter& dayCounter, Rate rateSpread = 0 // Spread to be added onto each // fixing within the // averaging/compounding calculation );

Since December 2015

http://www2.isda.org/asset-classes/credit-derivatives/single-name-cds-roll

single name standard CDS contracts change their rolling frequency from 3m to 6m. For index CDS this was already the standard before. I believe we need a new date generation rule to be able to construct the associated schedules correctly.

./configure should detect alternate naming such as libboost_thread-mt for the Boost.Thread and Boost.System libraries recently added. The mechanism can be the same used in acinclude.m4 for Boost.Tests.

Hi,
While trying to build AUD and NZD curves, I realized Quantlib doesn't have explicit support for the BBSW and BKBM indexes. While it is possible to instantiate those indexes through the IborIndex parent class, I think there would be value to have them explicitly defined like Euribor3M is for instance.
As a follow up item, the associated swap rates could also be added.
If you agree, I'd be happy to do the work and propose through a pull request.
Please advise if that's something you'd be interested in.
F.

standard rate bounds for integration are 1bp - 200bp, this is adjusted by a shift for shifted lognormal volatility input; however when the volatility input is normal, the rate bounds remain unchanged and have to be set via the ctor settings parameter if one wants to go deeper into the negative rates regime. maybe it would be nicer to change the bounds to "-std::max(abs(lower),abs(upper)) ... upper" internally in this case. this would clearly change the behaviour though compared to preivous releases.

This is a revival of issue lballabio/quantlib-old#143. I rebased @pcaspers CDS branch on top of current master here thrasibule/QuantLib@1070866 and fixed a couple bugs.
On top of fixing the original issue (adding an extra day to the last period of a cds schedule), this branch adds a new ISDA pricer for cds. Using this new pricer, I can now tie exactly the computations of cds upfronts with bloomberg and the JPM/Markit code. I think this would be a great addition to QuantLib. What's the best way of gettings this merged? I can try to squash the branch into a series of logical commits, but since @pcaspers and @japari did most of the work, I don't want to steal their thunder.

When running the unit test for Stulz engine, I noticed that option value was different if I was using ACT360 instead of ACT365fixed despite the fact that option maturity is expressed in years.
Here below is an example with Quantlib-Python based on the unit test.

Thank you in advance for your help

import QuantLib as ql
calculation_date = ql.Date.todaysDate()
calendar = ql.Germany()

#/                                basketType,   optionType,    strike, s1,    s2,   q1,   q2,    r,    t,   v1,   v2,  rho, result, tol
#ew BasketOptionTwoData(BasketType.MinBasket,  Option.Type.Put,  100.0, 100.0, 100.0, 0.00, 0.00, 0.05, 0.50, 0.30, 0.30, 0.10, 11.893, 1.0e-3),
dc = ql.Actual360()
t = 0.5
r = 0.05

K = 100

S1 = 100
q1 = 0
v1 = 0.3

S2 = 100
q2 = 0
v2 = 0.3

rho = 0.1

expiryDate = calculation_date + int(360 * t + 0.5)

exercise = ql.EuropeanExercise(expiryDate)

r_curve = ql.YieldTermStructureHandle(ql.FlatForward(calculation_date, r, dc))
q1_curve = ql.YieldTermStructureHandle(ql.FlatForward(calculation_date, q1, dc))
v1_curve = ql.BlackVolTermStructureHandle(ql.BlackConstantVol(calculation_date, calendar, v1, dc))
q2_curve = ql.YieldTermStructureHandle(ql.FlatForward(calculation_date, q2, dc))
v2_curve = ql.BlackVolTermStructureHandle(ql.BlackConstantVol(calculation_date, calendar, v2, dc))

p1 = ql.BlackScholesMertonProcess(ql.QuoteHandle(ql.SimpleQuote(S1)), q1_curve, r_curve, v1_curve)
p2 = ql.BlackScholesMertonProcess(ql.QuoteHandle(ql.SimpleQuote(S2)), q1_curve, r_curve, v2_curve)

analyticEngine = ql.StulzEngine(p1, p2, rho);

payoff = ql.PlainVanillaPayoff(ql.Option.Put, K)
basketoption = ql.BasketOption(ql.MinBasketPayoff(payoff), exercise)
basketoption.setPricingEngine(analyticEngine)
result = basketoption.NPV()

print(result)

# returns 11.892 with dc = ql.Actual360()    and  expiryDate = calculation_date + int(360 * t + 0.5)      (pass unit test)
# returns 11.905 with dc = ql.Actual365Fixed()    and  expiryDate = calculation_date + int(365 * t + 0.5)   (fails unit test)

I have an InterpolatedZeroCurve-object (call it: discountingCurve) with an ActualActual::ISMA day counter, the Settings::instance().evaluationDate() is set to the reference date of 2016-10-13. Now, when I call discountingCurve->timeFromReference(Date(30, Nov, 2016)), I get a value of 2/12, i.e. 0.166666666666.
When I call discountingCurve->dayCounter().dayCount(referenceDate, Date(30, Nov, 2016)), I get the expected 48 days. Additionally, we have a leap year, i.e. we have 366 days in the reference period (correct?). So, I would expect a value of 48/366, i.e. ~0.13114754.
The problem (if I am not wrong) seems to be in ActualActual::ISMA_Impl::yearFraction (actualactual.cpp), combination of line 66, line 77 and the nested if statement (line 79) where we run into the return in line 88 where we return a period that is based on an estimate (66).
The consequence (in my context) is, that I get a discount factor that contradicts the one of a reference system due to the different year fraction.
Can anyone have a look at this? The problem is, that I don’t know the idea behind line 66, line 77 and 88 which makes it hard to adjust the function. Also, I cannot see how the function yearFraction considers a leap year.

Hopeful, this is the correct place to address such issues:-)
Best, m

as the title says, the swaption helper supports normal vols after the corresponding PRs are merged, but we do not supply it for the swaption instrument as such; that should be added

Initially posted on stackoverflow, appologize for spraying it over here too. I have been really struggling with this.

I had QuantLib 1.9 built already (succeeded), then I tried to install QuantLib-Python from SWIG 1.9. I worked with VS2015,boost_1_62_0 (msvs-14.0 32bit), Anaconda3, QuantLib-1.9, QuantLib-SWIG-1.9 and swigwin-3.0.10,all in the same folder.

When I did "python setup.py build" in dev command prompt for vs2015, I came across the error: Link: fatal error LINK1104:cannot open file 'QuantLib-vc140-mt.lib'. So I went to QuantLib-lib folder, found that the lib file in there is called "QuantLib-vc140-mt-gd.lib". I make a copy of it and renamed it to 'QuantLib-vc140-mt.lib'and ran build command again, this time it ran longer but I got this new error under some of the obj files "quantlib fatal error LNK2001:unresolved external symbol___imp___CrtDbgReportW"

I am really new to the subject and would really appreciate if someone could shed some light on this.

FloatingRateCoupon::setPricer is not virtual, therefore when doing c->setPricer(p) on a CappedFlooredCoupon via a base class pointer, the underlying coupon doesn't get its pricer set. The workaround for this is for example using boost::static_pointer_cast<CappedFlooredCoupon>(c)->setPricer(p). I wonder if FloatingRateCoupon::setPricer should be virtual?

While looking for more general way to control curve build I looked to strip a curves forward rates to perturb them and rebuild the curve to get a tangent plane in an orthogonal basis (fra's). What I found was that even though there is a maturityDate provided, the only forward rate computed is the one corresponding to the IBOR index. So if you input a maturity of, say 6x12 mo and use a 3mo IBOR curve, you will get the 6x9 mo FRA. A work around is to use 6mo IBOR index, but this is an issue if you try to create a "generic" FRA to use as a basis and you would also need to account for any 3mo / 6mo basis curve if you were hedging off the 3mo.

At line 46 of forwardrateagreement.cpp we have:

    forwardRate_ = InterestRate(index->fixing(fixingDate),
                                index->dayCounter(),
                                Simple, Once);

Which has no dependency (in the call or prior to it) on maturityDate. Was this the authors intent?

"Random".
In ql/experimental/math/fireflyalgorithm.hpp.

I am trying to build the JNI-SWIG version of Quantlib on Windows. It seems this was done via skwash, but that project seems to be dead. Any chance this could be done in Visual Studio?

The hash value seems to be dependent on the Boost version, which makes the corresponding test fail when run with Boost 1.62.0b1.

Rather than having to maintain values for different versions, I'd remove the check on the hash and only rely on the existing checks on the interpolated absorption values.

There is still a missing piece for normal / shifted lognormal volatility support which is the extension of the CapHelper class. It can be done similarly as in the case of the SwaptionHelper class for example.

The Gaussian1dSwaptionEngine is a general purpose engine, originally designed for use in the Markov functional model. For the GSR and LGM instances of Gaussian1dModel we can have faster european swaption pricing though using the (existing) Gaussian1dJamshidianSwaptionEngine. The steps would be as follows:

1. make the zero bond option method in Gaussian1dModel virtual with a default implementation as is
2. overwrite this method in GSR and LGM with analytical formulas
3. extend the Gaussian1dJamshidianSwaptionEngine such that a correction for forward curve != discounting curve is applied (e.g. following Hagan's approach in his swaption paper)

In the file swap.cpp the testInArrears will fail on the reference date 2016/2/29. IMO this test has assumed that the fixingEndDate in each ibor coupon is coincide with schedule dates. However this assumption is not true for specific today date as 2016/2/29.

On that specific date:

schedule dates are: [2016/2/29, 2017/2/28, 2018/2/28, 2019/2/28, 2020/2/29, 2021/2/28]. The corresponding 5 floating coupons fixing end dates are [2018/2/28, 2019/2/28, 2020/2/28, 2021/2/28]. The difference sits in the third coupon. The difference will cause index fixing to be slightly different from 0.05.

I have tried to fix that problem but without much success. It seems that this error comes from date generating inconsistency between schedule and index. I am not sure how to make them to be consistent everywhere. Or should we allow such inconsistency(may be that is just the market reality) and make some amendment to the test simply.

The documentation for cadlibor points to a dead link. Not sure what it should be pointing to.
problem file:
https://github.com/lballabio/QuantLib/blob/0ec43027834220baf0a554d68de79a159a2c5489/ql/indexes/ibor/cadlibor.hpp

Dead link that is in documentation:
http://www.bba.org.uk/bba/jsp/polopoly.jsp?d=225&a=1414

Peter, is there a make, cmake or cmakelists file for fxtarf? I can see you have shell scripts to pass data into this simulation, but it's not clear how to build it. Any help is greatly appreciated.

Thank you,
Brian

Canadian-Conventions-in-FI-Markets.pdf

Page 17, section 6.1 of attached document. The "Otherwise" part (i.e., DCS > 365/f) is not implemented in QuantLib.

For example, for cusip 350863AC0 on 26-jan-2016 (one day before coupon payment), the trade date accrued interest should be 3.356507 = (0.5 - (184 - 183) / 365) * 6.75 . This matches the TRADE_DT_ACC_INT field on bloomberg, as well as the FTSE TMX bond index numbers on that day.

Actual365Fixed matches the correct accrued interest on all days where "DCS < 365/frequency"

There could have sense to introduce CMake (https://cmake.org/) support for QuantLib, considering that actually there are 6 different *.sln versions, and one Makefile.am in the root folder of the project and 4 guides (2 for different versions of Visual Studio) how to install the library and to integrate it with Boost.

Microsoft stopped supporting VC8 in April 2016. We can do the same.

How do you feel about creating an official QuantLib NuGet package? Boost is now up on NuGet, so getting QuantLib with a Boost dependency should work just fine.

And a second question: have you considered actually adding a Boost NuGet dependency to the QuantLib Visual Studio solution?

Both of these are rather simple changes that would significantly improve usability both for QuantLib consumers as well as developers.

See https://sourceforge.net/p/quantlib/mailman/message/35361772/; the holiday should be moved to the next Monday if it falls on a Sunday.

Thanks to Eisuke Tani.

Hi,

just verified with package (downloaded from sourceforge):
MD5 (QuantLib-1.8.tar.gz) = 5ac2cd9e3328baf3c6ecd1d6eaa10bb3

CMakeLists.txt file is missing in Examples directory; it is present in git repo.

https://github.com/lballabio/QuantLib/blob/master/Examples/CMakeLists.txt

Best,
Vasiliy

Here's the compiler output:

/bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../../ql -I../../.. -I../../.. -I/home/aloupos/local/boost_1_62_0 -g -O2 -MT fireflyalgorithm.lo -MD -MP -MF .deps/fireflyalgorithm.Tpo -c -o fireflyalgorithm.lo fireflyalgorithm.cpp
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../../ql -I../../.. -I../../.. -I/home/aloupos/local/boost_1_62_0 -g -O2 -MT fireflyalgorithm.lo -MD -MP -MF .deps/fireflyalgorithm.Tpo -c fireflyalgorithm.cpp -fPIC -DPIC -o .libs/fireflyalgorithm.o
In file included from fireflyalgorithm.cpp:24:
../../../ql/experimental/math/fireflyalgorithm.hpp: In constructor ‘QuantLib::GaussianWalk::GaussianWalk(QuantLib::Real, QuantLib::Real, long unsigned int)’:
../../../ql/experimental/math/fireflyalgorithm.hpp:234: error: class ‘QuantLib::GaussianWalk’ does not have any field named ‘DistributionRandomWalk’
../../../ql/experimental/math/fireflyalgorithm.hpp:234: error: no matching function for call to ‘QuantLib::DistributionRandomWalk<boost::random::normal_distribution >::DistributionRandomWalk()’
../../../ql/experimental/math/fireflyalgorithm.hpp:211: note: candidates are: QuantLib::DistributionRandomWalk::DistributionRandomWalk(Distribution, QuantLib::Real, long unsigned int) [with Distribution = boost::random::normal_distribution]
../../../ql/experimental/math/fireflyalgorithm.hpp:208: note: QuantLib::DistributionRandomWalk<boost::random::normal_distribution >::DistributionRandomWalk(const QuantLib::DistributionRandomWalk<boost::random::normal_distribution >&)
../../../ql/experimental/math/fireflyalgorithm.hpp: In constructor ‘QuantLib::LevyFlightWalk::LevyFlightWalk(QuantLib::Real, QuantLib::Real, QuantLib::Real, long unsigned int)’:
../../../ql/experimental/math/fireflyalgorithm.hpp:244: error: class ‘QuantLib::LevyFlightWalk’ does not have any field named ‘DistributionRandomWalk’
../../../ql/experimental/math/fireflyalgorithm.hpp:244: error: no matching function for call to ‘QuantLib::DistributionRandomWalkQuantLib::LevyFlightDistribution::DistributionRandomWalk()’
../../../ql/experimental/math/fireflyalgorithm.hpp:211: note: candidates are: QuantLib::DistributionRandomWalk::DistributionRandomWalk(Distribution, QuantLib::Real, long unsigned int) [with Distribution = QuantLib::LevyFlightDistribution]
../../../ql/experimental/math/fireflyalgorithm.hpp:208: note: QuantLib::DistributionRandomWalkQuantLib::LevyFlightDistribution::DistributionRandomWalk(const QuantLib::DistributionRandomWalkQuantLib::LevyFlightDistribution&)
make[4]: *** [fireflyalgorithm.lo] Error 1

Had anyone tried that?

This is briefly what I've done:

# install toolchain
$ sudo apt-get install gcc-4.9-locales mingw32 mingw-w64 mingw-w64-tools \
    binutils-mingw-w64 binutils-mingw-w64-x86-64 binutils-mingw-w64-i686 \
    mingw-w64-x86-64-dev mingw-w64-i686-dev

# install autotools
$ sudo apt-get install autoconf automake autotools-dev

# make sure environment variables are set
export CC=/usr/bin/x86_64-w64-mingw32-gcc-win32
export CXX=/usr/bin/x86_64-w64-mingw32-g++-win32
export CPP=/usr/bin/x86_64-w64-mingw32-cpp-win32
export CXXCPP=/usr/bin/x86_64-w64-mingw32-cpp-win32
export AR=/usr/bin/x86_64-w64-mingw32-gcc-ar-win32
export NM=/usr/bin/x86_64-w64-mingw32-gcc-nm-win32
export RANLIB=/usr/bin/x86_64-w64-mingw32-gcc-ranlib-win32
export DLLTOOL=/usr/bin/x86_64-w64-mingw32-dlltool
export DLLWRAP=/usr/bin/x86_64-w64-mingw32-dllwrap
export LD=/usr/bin/x86_64-w64-mingw32-ld
export OBJCOPY=/usr/bin/x86_64-w64-mingw32-objcopy
export OBJDUMP=/usr/bin/x86_64-w64-mingw32-objdump
export PKGCONFIG=/usr/bin/x86_64-w64-mingw32-pkg-config

# build QuantLib, specifying target host
$ ./autogen.sh
$ ./configure --host=x86_64-x64-mingw32 \
    --disable-examples --disable-benchmark \
    --with-boost-include=/home/rgomes/workspace/boost_1_60_0
$ make

The result is that QuantLib is built properly, but I don't see any .dll and/or .exe as I would expect.
So, it seems that autoconf scripts do not support a cross compilation like this.

Any idea how a cross compilation using GNU mingw toolchain could be supported?

Thanks a lot,
-- Richard

Note:
I've removed FRA from the build, since it requires Boost binaries (i.e: not only Boost sources):

(j8s11)rgomes@terra:~/workspace/QuantLib$ git status
HEAD detached at QuantLib-v1.7
Changes not staged for commit:
  (use "git add/rm <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)
        deleted:    Examples/FRA/FRA.cpp
        deleted:    Examples/FRA/FRA.dev
        deleted:    Examples/FRA/FRA.vcxproj
        deleted:    Examples/FRA/FRA.vcxproj.filters
        deleted:    Examples/FRA/FRA_vc8.vcproj
        deleted:    Examples/FRA/FRA_vc9.vcproj
        deleted:    Examples/FRA/Makefile.am
        deleted:    Examples/FRA/ReadMe.txt
        modified:   Examples/Makefile.am
        modified:   configure.ac

The code in ql/termstructures/yieldtermstructure.cpp still requires discount factors expressing jumps to be between 0 and 1 included. Dropping the upper limit will allow negative jumps.

Thanks to Leanpub reader Jeff for the heads-up.

Hello!

I have during the past few days attempted to cross compile from Ubuntu to ARM, specifically for a project on the Raspberry Pi. I am attempting to build the library with the RTI toolchain (64 bit). Building and installation of the QL library on Ubuntu itself was completely worked perfectly, but there is little in the way of support for cross compilation to other versions of Linux. Furthermore, cross compilation of boost appears to be poorly documented. I would greatly appreciate any advice in response.

Thank you!

Hi, I'd be interested in submitting a PR with a CMakeLists.txt file for those users who are not using VS. Will you accept such a PR?

Hi,

I am making my own plugin on top of Quantlib. I have compiled Quantlib 1.8.1 library against Boost 1.62.0 and libQuantLib.a is properly generated with GCC 4.4.7 . But when I am compiling my plugin and trying to link it to libQuantLib.a, it is giving me error-

/usr/bin/ld: /var/tmp/anksi/quantlib/1.8.1/libs/libQuantLib.a(cashflow.o): relocation R_X86_64_32 against `typeinfo for QuantLib::VisitorQuantLib::CashFlow' can not be used when making a shared object; recompile with -fPIC
/var/tmp/anksi/quantlib/1.8.1/libs/libQuantLib.a: could not read symbols: Bad value
collect2: ld returned 1 exit status
gmake: *** [Release/libQuantlibPlugin.so] Error 1

For compiling Quantlib I have followed the commands given on http://quantlib.org/git.shtml

1. sh ./autogen.sh
2. ./configure --with-boost-include=$BOOST_INCLUDE
3. make

Is there any other parameter is need to pass while building quantlib?

the project QuantLib_vc14 do not include lgm.cpp and thus during the linking of the project the line
test->add(LgmTest::suite());
can not correctly managed as soon as the linker fails to find the specified class & method.

Hello,
I got this error message when running Tests:

Error in "QuantLib test suite/NoArbSabrModel tests/QuantLib::detail::quantlib_test_case(&NoArbSabrTest::testAbsorptionMatrix)": failed to verify the hash value of the absorption matrix testsuite C:\quantlib\QuantLib-1.8\test-suite\noarbsabr.cpp 82

Severity Code Description Project File Line Suppression State
Error MSB3073 The command ""C:\quantlib\QuantLib-1.8\test-suite\bin\QuantLib-test-suite-vc140-mt.exe" --log_level=message --build_info=yes --result_code=no --report_level=short
:VCEnd" exited with code -1. testsuite C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V140\Microsoft.CppCommon.targets 133

win10 64bit
quantlib 1.80
boost 1.62 32bit
Visual studio 14
Build: Release / Win32

Thanks,

Stefano

Windows 10 SDK
VC++19
cmake 3.2
boost 1.60.0

tried to build the project by default, no any changes , just clone and build using cmake.
got the error message:
NMAKE:-1: error: U1073: don't know how to make 'ql\QuantLib.lib'
dll, pdb and ilk generated successfully, just import lib is missed

If you set up a PiecewiseYieldCurve (or similar structures for Inflation, Default, etc.) with a fixed reference date, the object still reacts to changes in the evaluation date. This is because most of the rate helpers (like Swap, FRA, Deposit) are relative date helpers and there is no version that does not register with the evaluation date. Thus, the curve will be re-bootstrapped with shifted helpers, but still having the old reference date. I would expect the curve only to react on quote changes in the helpers, but it should behave independently of the global evaluation date. The solution could go in the direction to expose the moving_ flag in TermStructure as an inspector and make the bootstrap helpers moving or not depending on this flag. But this is not easy, since the helpers might be used in several term structures, some of them moving, others not. One could also provide different versions of the rate helpers (fixed / float date) and check that only consistent ones are used to bootstrap a curve. Or skip the check and just provide them.

In the end I want to be able to set up a PiecewiseYieldCurve with fixed reference date that wouldn't re-bootstrap on evaluation date changes. Today the only workaround seems to be to make a copy of the bootstrapped curve as a InterpolatedDiscountCurve or the like.