quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] c++0x

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

following up the topic below: I missed to look at the test-suite, where some more
auto_ptr would have to be replaced by unique_ptr.

https://github.com/pcaspers/quantlib/commit/466fbfbc423312eb7c4536ab59d861689cde70a0

Furthermore the header ql/utilities/clone.hpp has to be changed.

https://github.com/pcaspers/quantlib/commit/fe5a87dcfb60c10f1d8600b1511037e200915e4c
https://github.com/pcaspers/quantlib/commit/7a12fc4c62b44d175dc794b487db0582803ef6a5

The test-suite now compiles and runs using g++ (with and without -std=c++0x)
which is the main thing I guess. The whole thing does not look very
nice though. Also I am not c++ expert enough to say that the upgrade of
clone.hpp to unique_ptr should be done like this. Luigi ?

Thank you
 Peter

Peter Caspers <pca...@gm...> writes:

> Hi Luigi, all,
>
> we discussed compiling the core lib under the c++11 standard (e.g. with
> g++ -std=c++0x). This produces some errors which can be fixed easily
> (keeping backward compatibility):
>
> https://github.com/pcaspers/quantlib/commit/5b32b7705530264551e0622d0a2673813067be5b
>
> What is left is a bunch of warnings saying that std::auto_ptr is
> depricated under c++11, the replacement being std::unique_ptr. A
> possible solution is to replace the auto_ptr in the source by unique_ptr
> (thus upgrading the code to c++11 already) and replace the unique_ptr by
> auto_ptr again in case that compilation is done under c++ versions <
> 11. I have done this here
>
> https://github.com/pcaspers/quantlib/commit/3e47a82a936112f12e3bb502292833d860f5aac9
>
> with a #define in qldefines.hpp resetting the pointers to auto_ptr again
> based on the boost macro BOOST_NO_CXX_SMART_PTR. Unfortunately this
> macro is available only in later boost versions so if one uses an older
> one and provides no c++11 support he or she will get errors. Therefore
> the following solution might be better
>
> https://github.com/pcaspers/quantlib/commit/6db965375b02094a7ea0da4e48efd7e0a1b8fd85
>
> using the __cplusplus macro to identify c++11. However since gcc sets
> this macro simply to 1 in versions 4.6 (should be solved starting in
> 4.7), I had to add another criterion for gcc based on
> __GXX_EXPERIMENTAL_CXX0X_.
>
> For msvc 2010 the __cplusplus is also not 201103L but still 199711L. This
> seems also to be the case in 2012 and this specific case was reported as a bug to
> Microsoft,
>
> http://connect.microsoft.com/VisualStudio/feedback/details/763051/a-value-of-predefined-macro-cplusplus-is-still-199711l
>
> though not solved yet. Therefore I added a direct test on msvc 2010 or
> higher versions based on _MSC_VER 
>
> https://github.com/pcaspers/quantlib/commit/796beb89e2a707f951b77869bf869694e67ac769
>
> This final solution should work for all versions of msvc and gcc. I can not check other
> compilers however.
>
> Since the #define seems a bit like a dirty hack we also thought of a
> typedef. But then we would need a template typedef which is available only in
> c++11 again and a metaprogramming-like workaround a la
>
> template<class T> struct PTR {
>     typedef std::unique_ptr<T> Type;
> };
>
> PTR<double>::Type a(new double(0.0));
>
> does not seem to improve the code either.
>
> Do you think we should do the upgrade to c++11 like propsed above or is there
> maybe a better solution (I bet there is...). Or should we defer the
> upgrade until a later release ? I personally would very much like to be
> able to compile under c++11 without warnings already now.
>
> Thank you
>  Peter
>
>
>
>   

[Quantlib-dev] VC9

[Mark j. <mar...@gm...>]

OK I checked out and did a full build of QuantLib for the first time in a
long time today.

The testsuite built and passed with VC11

With VC9 I get

1>.\markovfunctional.cpp(1015) : error C2039: 'at' : is not a member of
'std::map<_Kty,_Ty>'
1>        with
1>        [
1>            _Kty=std::string,
1>            _Ty=boost::any
1>        ]

Are we still targeting VC9?

best

Mark


-- 

Prof Mark Joshi
Centre for Actuarial Studies
University of Melbourne
My website is www.markjoshi.com

Re: [Quantlib-dev] Mortgage backed securities [was:Jamshidian engine with start delay]

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

If your model lets you forecast a series of notionals, you might try
using the classes in <ql/experimental/amortizingbonds/>.  I'm not sure
how far they can go as a proxy for MBS, but they might be a starting
point of sorts that you can modify to include additional features you
need.

Luigi


On Tue, May 21, 2013 at 6:11 PM, Navtej Singh-Riyait
<Nav...@fi...> wrote:
> Yes we do want to model the prepayments using PSA. Also want to implement PACs and TACs.
>
> -----Original Message-----
> From: Luigi Ballabio [mailto:lui...@gm...]
> Sent: 21 May 2013 16:27
> To: Navtej Singh-Riyait; qua...@li...
> Subject: Re: [Quantlib-dev] Mortgage backed securities [was:Jamshidian engine with start delay]
>
> So you don't want to model prepayment? Or maybe you model it elsewhere, and have a forecast stream of notionals? If that's the case, you can use a simple bond (possibly amortized) as a proxy for the MBS.
>
> Luigi
>
> [Note: cc'd to the list again, as the issue is of common interest]
>
>
> On Tue, May 21, 2013 at 5:23 PM, Navtej Singh-Riyait <Nav...@fi...> wrote:
>> What I am interested in the calculation of accrued interest and price/yield or average yield for MBSs not sophisticated pricing.
>>
>> -----Original Message-----
>> From: Luigi Ballabio [mailto:lui...@gm...]
>> Sent: 21 May 2013 16:21
>> To: Navtej Singh-Riyait
>> Cc: qua...@li...
>> Subject: Re: [Quantlib-dev] Mortgage backed securities [was:Jamshidian
>> engine with start delay]
>>
>> Hello,
>>     there's no support for MBS at this time.  What pricing model do you have in mind?
>>
>> Luigi
>>
>> On Fri, May 17, 2013 at 2:40 PM, Navtej Singh-Riyait <Nav...@fi...> wrote:
>>> Is there a way I can incorporate accrued interest and yield
>>> calculations for incorporate Mortgaged Backed Securities in QuantLib ?
>>>
>>>
>>>
>>> From: Ferdinando Ametrano [mailto:na...@am...]
>>> Sent: 15 May 2013 09:19
>>> To: Peter Caspers
>>> Cc: qua...@li...
>>> Subject: Re: [Quantlib-dev] Jamshidian engine with start delay
>>>
>>>
>>>
>>> I'm ok with your extension provided that the new values collapse back
>>> to the old ones (with a reasonable tolerance) in the case of expiry
>>> date being equal the value date.
>>>
>>> Is the data you've posted related to this case?
>>>
>>>
>>>
>>> It's a while now I do not work for a vol desk, but I would never
>>> underestimate the huge difference of analytic vs numerical methods
>>> when it comes to calibration.
>>>
>>>
>>>
>>> This said I would also add that I'm always amazed how poor the
>>> production setup is, even in very sophisticated banks. Old models
>>> stick around for very long time, just because of the huge effort
>>> required to update them in production systems. The multi-curve
>>> framework updates I've seen so far rival with Mary Shelley's
>>> Frankenstein approach
>>>
>>>
>>>
>>>
>>>
>>> On Sat, May 11, 2013 at 1:37 PM, Peter Caspers
>>> <pca...@gm...>
>>> wrote:
>>>
>>> Hello,
>>>
>>> in the JamshidianSwaptionEngine the option expiry date and the value
>>> date of the underlying swap are handled a bit simplified assuming
>>> both dates equal (see the warning in the code). Though the impact is
>>> usually not very big we might want to improve this detail in the
>>> library ? See below for a possible approach. Thank you Sebastian for our discussions on the topic.
>>>
>>> Aside I would be interested whether the Jamshidian method is still in
>>> use for model calibration in the world of multi curve enhanced models
>>> (where by enhanced I mean something simple like a static spread
>>> correction) because I believe the generalization of the method to
>>> this setting is not straightforward. Also I feel that numerical
>>> integration does nearly a just as efficient and accurate job and it
>>> directly allows for multiple curve computations. Or do you ignore
>>> multi curve in the calibration phase and only adjust the curves for the actual pricing ?
>>>
>>> Back to Jamshidian and the start delay. Some theoretical background
>>> and numerical examples can be found here
>>>
>>> http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2246054
>>>
>>> A possible implementation goes as follows. First we need to provide
>>> an extended zerobond option method, which we can add to AffineModel
>>> in model.hpp
>>>
>>> https://github.com/pcaspers/quantlib/commit/e16b4ea5ffbfe33bd6acd0ee6
>>> c
>>> b3ecd8a43f72a4
>>>
>>> The default implementation uses the same simplification as mentioned
>>> above ignoring the bond start delay. To improve the pricing in the
>>> JamshidianEngine we have to overwrite this method in the model
>>> implementations for which we want it. For the Hull White model I did
>>> it here
>>>
>>> https://github.com/pcaspers/quantlib/commit/e8b5912cac2e236fe59a885e8
>>> c
>>> d1e2ed9243cc47
>>>
>>> Finally we have to modify the Jamshidian engine a bit
>>>
>>> https://github.com/pcaspers/quantlib/commit/019f37a498846d9a6e89a8973
>>> 0
>>> 0f126c01d6ef86
>>>
>>> (maybe we should keep some warning in the code because you are not
>>> forced to support the start delay in your model implementations)
>>>
>>> Not suprisingly the test suite breaks when comparing computation
>>> results to cached values computed with the simplified engine, so the
>>> cached values should be updated (given that we believe in the new
>>> engine)
>>>
>>> 1>  Testing Hull-White calibration against cached values...
>>> 1>  shortratemodels.cpp(126): error in
>>> "QuantLib::detail::quantlib_test_case(&ShortRateModelTest::testCachedHullWhite)":
>>> Failed to reproduce cached calibration results:
>>> 1>  calculated: a = 0.0464041, sigma = 0.00579912, f(a) = 0.1158,
>>> 1>  expected:   a = 0.0488565, sigma = 0.00593662, f(a) = 0.121599,
>>> 1>  difference: a = -0.00245242, sigma = -0.000137495, f(a) =
>>> 1> -0.00579896,  end criteria = StationaryFunctionValue
>>>
>>> regards
>>>   Peter
>>>
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> -------- Learn Graph Databases - Download FREE O'Reilly Book "Graph
>>> Databases" is the definitive new guide to graph databases and their
>>> applications. This 200-page book is written by three acclaimed
>>> leaders in the field. The early access version is available now.
>>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>
>>>
>>>
>>>
>>>
>>> This message is intended only for the stated addressee(s) and may be
>>> confidential. Access to this email by anyone else is unauthorised.
>>> Any opinions expressed in this email do not necessarily reflect the
>>> opinions of Fidessa. Any unauthorised disclosure, use or
>>> dissemination, either whole or in part is prohibited. If you are not
>>> the intended recipient of this message, please notify the sender immediately.
>>> Fidessa plc registered in England and Wales no. 3781700. VAT
>>> registration no. GB688900878. Registered office - Dukes Court, Duke
>>> Street, Woking, Surrey, GU21 5BH, UK Fidessa buy-side ltd registered
>>> in England and Wales no. 3656437. VAT registration no. GB688900878.
>>> Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21
>>> 5BH, UK Fidessa group plc registered in England and Wales no. 3234176.
>>> VAT registration no. GB688900878. Registered office - Dukes Court,
>>> Duke Street, Woking, Surrey, GU21 5BH, UK
>>>
>>>
>>> ---------------------------------------------------------------------
>>> -
>>> -------- AlienVault Unified Security Management (USM) platform
>>> delivers complete security visibility with the essential security
>>> capabilities. Easily and efficiently configure, manage, and operate
>>> all of your security controls from a single console and one unified
>>> framework. Download a free trial.
>>> http://p.sf.net/sfu/alienvault_d2d
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>
>>
>>
>> This message is intended only for the stated addressee(s) and may be confidential. Access to this email by anyone else is unauthorised. Any opinions expressed in this email do not necessarily reflect the opinions of Fidessa. Any unauthorised disclosure, use or dissemination, either whole or in part is prohibited. If you are not the intended recipient of this message, please notify the sender immediately.
>> Fidessa plc registered in England and Wales no. 3781700. VAT
>> registration no. GB688900878. Registered office - Dukes Court, Duke
>> Street, Woking, Surrey, GU21 5BH, UK Fidessa buy-side ltd registered
>> in England and Wales no. 3656437. VAT registration no. GB688900878.
>> Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21
>> 5BH, UK Fidessa group plc registered in England and Wales no. 3234176.
>> VAT registration no. GB688900878. Registered office - Dukes Court,
>> Duke Street, Woking, Surrey, GU21 5BH, UK

Re: [Quantlib-dev] c++0x

[Klaus S. <kl...@sp...>]

Hi

Opps, sorry everyone. I've chosen the from receiver. Please ignore the email 
below.

sorry
 Klaus

On Sunday, May 26, 2013 12:12:38 PM Klaus Spanderen wrote:

5.6. ist gemacht, 18:30 in der Pommes Bude bei euch. (Genau Uhrzeit können wir 
noch am 5.6 ausmachen)

Gut, dass du das zusammengefasst hast und auf die Mailing-Liste gesetzt hast. 
Ich wäre ja für QL-1.3 release mit den alten settings und dann QL-2.0 
aufmachen, was unter c++11 läuft;-)

gruß
 Klaus

On Saturday, May 25, 2013 08:13:12 PM Peter Caspers wrote:
> Hi Luigi, all,
> 
> we discussed compiling the core lib under the c++11 standard (e.g. with
> g++ -std=c++0x). This produces some errors which can be fixed easily
> (keeping backward compatibility):
> 
> https://github.com/pcaspers/quantlib/commit/5b32b7705530264551e0622d0a267381
> 3067be5b
> 
> What is left is a bunch of warnings saying that std::auto_ptr is
> depricated under c++11, the replacement being std::unique_ptr. A
> possible solution is to replace the auto_ptr in the source by unique_ptr
> (thus upgrading the code to c++11 already) and replace the unique_ptr by
> auto_ptr again in case that compilation is done under c++ versions <
> 11. I have done this here
> 
> https://github.com/pcaspers/quantlib/commit/3e47a82a936112f12e3bb502292833d8
> 60f5aac9
> 
> with a #define in qldefines.hpp resetting the pointers to auto_ptr again
> based on the boost macro BOOST_NO_CXX_SMART_PTR. Unfortunately this
> macro is available only in later boost versions so if one uses an older
> one and provides no c++11 support he or she will get errors. Therefore
> the following solution might be better
> 
> https://github.com/pcaspers/quantlib/commit/6db965375b02094a7ea0da4e48efd7e0
> a1b8fd85
> 
> using the __cplusplus macro to identify c++11. However since gcc sets
> this macro simply to 1 in versions 4.6 (should be solved starting in
> 4.7), I had to add another criterion for gcc based on
> __GXX_EXPERIMENTAL_CXX0X_.
> 
> For msvc 2010 the __cplusplus is also not 201103L but still 199711L. This
> seems also to be the case in 2012 and this specific case was reported as a
> bug to Microsoft,
> 
> http://connect.microsoft.com/VisualStudio/feedback/details/763051/a-value-of
> -predefined-macro-cplusplus-is-still-199711l
> 
> though not solved yet. Therefore I added a direct test on msvc 2010 or
> higher versions based on _MSC_VER
> 
> https://github.com/pcaspers/quantlib/commit/796beb89e2a707f951b77869bf869694
> e67ac769
> 
> This final solution should work for all versions of msvc and gcc. I can not
> check other compilers however.
> 
> Since the #define seems a bit like a dirty hack we also thought of a
> typedef. But then we would need a template typedef which is available only
> in c++11 again and a metaprogramming-like workaround a la
> 
> template<class T> struct PTR {
>     typedef std::unique_ptr<T> Type;
> };
> 
> PTR<double>::Type a(new double(0.0));
> 
> does not seem to improve the code either.
> 
> Do you think we should do the upgrade to c++11 like propsed above or is
> there maybe a better solution (I bet there is...). Or should we defer the
> upgrade until a later release ? I personally would very much like to be
> able to compile under c++11 without warnings already now.
> 
> Thank you
>  Peter
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------------
> -- Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] c++0x

[Klaus S. <kl...@sp...>]

5.6. ist gemacht, 18:30 in der Pommes Bude bei euch. (Genau Uhrzeit können wir 
noch am 5.6 ausmachen)

Gut, dass du das zusammengefasst hast und auf die Mailing-Liste gesetzt hast. 
Ich wäre ja für QL-1.3 release mit den alten settings und dann QL-2.0 
aufmachen, was unter c++11 läuft;-)

gruß
 Klaus

On Saturday, May 25, 2013 08:13:12 PM Peter Caspers wrote:
> Hi Luigi, all,
> 
> we discussed compiling the core lib under the c++11 standard (e.g. with
> g++ -std=c++0x). This produces some errors which can be fixed easily
> (keeping backward compatibility):
> 
> https://github.com/pcaspers/quantlib/commit/5b32b7705530264551e0622d0a267381
> 3067be5b
> 
> What is left is a bunch of warnings saying that std::auto_ptr is
> depricated under c++11, the replacement being std::unique_ptr. A
> possible solution is to replace the auto_ptr in the source by unique_ptr
> (thus upgrading the code to c++11 already) and replace the unique_ptr by
> auto_ptr again in case that compilation is done under c++ versions <
> 11. I have done this here
> 
> https://github.com/pcaspers/quantlib/commit/3e47a82a936112f12e3bb502292833d8
> 60f5aac9
> 
> with a #define in qldefines.hpp resetting the pointers to auto_ptr again
> based on the boost macro BOOST_NO_CXX_SMART_PTR. Unfortunately this
> macro is available only in later boost versions so if one uses an older
> one and provides no c++11 support he or she will get errors. Therefore
> the following solution might be better
> 
> https://github.com/pcaspers/quantlib/commit/6db965375b02094a7ea0da4e48efd7e0
> a1b8fd85
> 
> using the __cplusplus macro to identify c++11. However since gcc sets
> this macro simply to 1 in versions 4.6 (should be solved starting in
> 4.7), I had to add another criterion for gcc based on
> __GXX_EXPERIMENTAL_CXX0X_.
> 
> For msvc 2010 the __cplusplus is also not 201103L but still 199711L. This
> seems also to be the case in 2012 and this specific case was reported as a
> bug to Microsoft,
> 
> http://connect.microsoft.com/VisualStudio/feedback/details/763051/a-value-of
> -predefined-macro-cplusplus-is-still-199711l
> 
> though not solved yet. Therefore I added a direct test on msvc 2010 or
> higher versions based on _MSC_VER
> 
> https://github.com/pcaspers/quantlib/commit/796beb89e2a707f951b77869bf869694
> e67ac769
> 
> This final solution should work for all versions of msvc and gcc. I can not
> check other compilers however.
> 
> Since the #define seems a bit like a dirty hack we also thought of a
> typedef. But then we would need a template typedef which is available only
> in c++11 again and a metaprogramming-like workaround a la
> 
> template<class T> struct PTR {
>     typedef std::unique_ptr<T> Type;
> };
> 
> PTR<double>::Type a(new double(0.0));
> 
> does not seem to improve the code either.
> 
> Do you think we should do the upgrade to c++11 like propsed above or is
> there maybe a better solution (I bet there is...). Or should we defer the
> upgrade until a later release ? I personally would very much like to be
> able to compile under c++11 without warnings already now.
> 
> Thank you
>  Peter
> 
> 
> 
> 
> 
> 
> ----------------------------------------------------------------------------
> -- Try New Relic Now & We'll Send You this Cool Shirt
> New Relic is the only SaaS-based application performance monitoring service
> that delivers powerful full stack analytics. Optimize and monitor your
> browser, app, & servers with just a few lines of code. Try New Relic
> and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] SwapIndex::clone

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

Hi, 

can we add another clone method to SwapIndex which allows to change
the tenor ? I think this could make life easier in some situations. At
least I often create a new swap index from an existing one only changing
the tenor.

https://github.com/pcaspers/quantlib/commit/416713b23fd855b64f6c51824304f2524744b185

regards
 Peter

[Quantlib-dev] c++0x

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

Hi Luigi, all,

we discussed compiling the core lib under the c++11 standard (e.g. with
g++ -std=c++0x). This produces some errors which can be fixed easily
(keeping backward compatibility):

https://github.com/pcaspers/quantlib/commit/5b32b7705530264551e0622d0a2673813067be5b

What is left is a bunch of warnings saying that std::auto_ptr is
depricated under c++11, the replacement being std::unique_ptr. A
possible solution is to replace the auto_ptr in the source by unique_ptr
(thus upgrading the code to c++11 already) and replace the unique_ptr by
auto_ptr again in case that compilation is done under c++ versions <
11. I have done this here

https://github.com/pcaspers/quantlib/commit/3e47a82a936112f12e3bb502292833d860f5aac9

with a #define in qldefines.hpp resetting the pointers to auto_ptr again
based on the boost macro BOOST_NO_CXX_SMART_PTR. Unfortunately this
macro is available only in later boost versions so if one uses an older
one and provides no c++11 support he or she will get errors. Therefore
the following solution might be better

https://github.com/pcaspers/quantlib/commit/6db965375b02094a7ea0da4e48efd7e0a1b8fd85

using the __cplusplus macro to identify c++11. However since gcc sets
this macro simply to 1 in versions 4.6 (should be solved starting in
4.7), I had to add another criterion for gcc based on
__GXX_EXPERIMENTAL_CXX0X_.

For msvc 2010 the __cplusplus is also not 201103L but still 199711L. This
seems also to be the case in 2012 and this specific case was reported as a bug to
Microsoft,

http://connect.microsoft.com/VisualStudio/feedback/details/763051/a-value-of-predefined-macro-cplusplus-is-still-199711l

though not solved yet. Therefore I added a direct test on msvc 2010 or
higher versions based on _MSC_VER 

https://github.com/pcaspers/quantlib/commit/796beb89e2a707f951b77869bf869694e67ac769

This final solution should work for all versions of msvc and gcc. I can not check other
compilers however.

Since the #define seems a bit like a dirty hack we also thought of a
typedef. But then we would need a template typedef which is available only in
c++11 again and a metaprogramming-like workaround a la

template<class T> struct PTR {
    typedef std::unique_ptr<T> Type;
};

PTR<double>::Type a(new double(0.0));

does not seem to improve the code either.

Do you think we should do the upgrade to c++11 like propsed above or is there
maybe a better solution (I bet there is...). Or should we defer the
upgrade until a later release ? I personally would very much like to be
able to compile under c++11 without warnings already now.

Thank you
 Peter



  

[Quantlib-dev] Example of yield curve fitting in Excel

[Grześ A. <gan...@gm...>]

Hi,

Where could I find an example of yield curve bootstrapping from market data
in Excel? And ideally including a graph of the fitted curve.

Cheers,
Grzegorz

[Quantlib-dev] Compiling quantlib on Solaris X86 using Workshop

[<Pau...@de...>]

Hello!

We compiled quantlib on a SunOS 5.10, using Sun Workshop 12.2 (cc: Sun C 
5.11 SunOS_i386 2010/08/13) for 64bit.
We used the latest boost  (1.53.0).
Our configure was not special:
./configure --with-boost-include=../boost_1_53_0 
--with-boost-lib=../boost_1_53_0/libs

However we used:
CXXFLAGS=-library=stlport4 -m64

We managed to compile the lib, but had to do some changes:
a) includes
We had to include "math.h and stdlib.h" to cpicoupon.cpp

We had to include math.h to:
riskyassetswapoption.cpp
blackdeltacalculator.cpp
cpicapfloorengines.cpp
zigguratrng.cpp
analyticvariancegammaengine.cpp
fftvanillaengine.cpp
fftvariancegammaengine.cpp
cpiswap.cpp
cpibond.cpp
analyticgjrgarchengine.cpp
seasonality.hpp

b) Unresolved external
We had a problem with the linker for 
const long *const PrimitivePolynomials[N_MAX_DEGREE];

 coming from "primitivepolynonimals.h" / "primitivepolynominals.c"

Somehow the linker didn't linke the function to the sobolrsg.cpp
Couldn't find out why, but the nm-command showed the symbol twice: once 
defined and once undefined. 

After changing the file to .hpp and .cpp all worked fine.

We addidionaly compiled the Swig for java, because we'll call from java to 
calc theo option prices.
For java we additionaly had to include -Kpic for the linker.

I wanted to let you know of the these problems.
Maybe there is a better way or maybe the ql can be adepted? I think the 
changes don't harm for other compilers?

(By the way: we didn't have any problems on Windows)

And thanx for the great work. We're using the lib only in a sample up to 
now, but that might change in the future...

Best regards,
Paul Rädle





-------------------------------------------------------------------------
Deutsche Börse AG
Chairman of the Supervisory Board/
Vorsitzender des Aufsichtsrats:
Dr. Joachim Faber
Executive Board/Vorstand:
Dr. Reto Francioni (Chief Executive Officer/Vorsitzender),
Andreas Preuss (Deputy Chief Executive Officer/
stellv. Vorsitzender), Gregor Pottmeyer,
Hauke Stars, Jeffrey Tessler.
Aktiengesellschaft with registered seat in/mit Sitz in
Frankfurt am Main.
Commercial register/Handelsregister: HRB 32232
Local court/Amtsgericht Frankfurt am Main.
-----------------------------------------
Diese E-Mail enthaelt vertrauliche oder rechtlich geschuetzte Informationen.
Wenn Sie nicht der beabsichtigte Empfaenger sind, informieren Sie bitte
sofort den Absender und loeschen Sie diese E-Mail. Das unbefugte Kopieren
dieser E-Mail oder die unbefugte Weitergabe der enthaltenen Informationen
ist nicht gestattet.

The information contained in this message is confidential or protected by
law. If you are not the intended recipient, please contact the sender and
delete this message. Any unauthorised copying of this message or
unauthorised distribution of the information contained herein is prohibited.

Legally required information for business correspondence/
Gesetzliche Pflichtangaben fuer Geschaeftskorrespondenz:
http://deutsche-boerse.com/letterhead

Re: [Quantlib-dev] Mortgage backed securities [was:Jamshidian engine with start delay]

[Navtej Singh-R. <Nav...@fi...>]

Yes we do want to model the prepayments using PSA. Also want to implement PACs and TACs.

-----Original Message-----
From: Luigi Ballabio [mailto:lui...@gm...] 
Sent: 21 May 2013 16:27
To: Navtej Singh-Riyait; qua...@li...
Subject: Re: [Quantlib-dev] Mortgage backed securities [was:Jamshidian engine with start delay]

So you don't want to model prepayment? Or maybe you model it elsewhere, and have a forecast stream of notionals? If that's the case, you can use a simple bond (possibly amortized) as a proxy for the MBS.

Luigi

[Note: cc'd to the list again, as the issue is of common interest]


On Tue, May 21, 2013 at 5:23 PM, Navtej Singh-Riyait <Nav...@fi...> wrote:
> What I am interested in the calculation of accrued interest and price/yield or average yield for MBSs not sophisticated pricing.
>
> -----Original Message-----
> From: Luigi Ballabio [mailto:lui...@gm...]
> Sent: 21 May 2013 16:21
> To: Navtej Singh-Riyait
> Cc: qua...@li...
> Subject: Re: [Quantlib-dev] Mortgage backed securities [was:Jamshidian 
> engine with start delay]
>
> Hello,
>     there's no support for MBS at this time.  What pricing model do you have in mind?
>
> Luigi
>
> On Fri, May 17, 2013 at 2:40 PM, Navtej Singh-Riyait <Nav...@fi...> wrote:
>> Is there a way I can incorporate accrued interest and yield 
>> calculations for incorporate Mortgaged Backed Securities in QuantLib ?
>>
>>
>>
>> From: Ferdinando Ametrano [mailto:na...@am...]
>> Sent: 15 May 2013 09:19
>> To: Peter Caspers
>> Cc: qua...@li...
>> Subject: Re: [Quantlib-dev] Jamshidian engine with start delay
>>
>>
>>
>> I'm ok with your extension provided that the new values collapse back 
>> to the old ones (with a reasonable tolerance) in the case of expiry 
>> date being equal the value date.
>>
>> Is the data you've posted related to this case?
>>
>>
>>
>> It's a while now I do not work for a vol desk, but I would never 
>> underestimate the huge difference of analytic vs numerical methods 
>> when it comes to calibration.
>>
>>
>>
>> This said I would also add that I'm always amazed how poor the 
>> production setup is, even in very sophisticated banks. Old models 
>> stick around for very long time, just because of the huge effort 
>> required to update them in production systems. The multi-curve 
>> framework updates I've seen so far rival with Mary Shelley's 
>> Frankenstein approach
>>
>>
>>
>>
>>
>> On Sat, May 11, 2013 at 1:37 PM, Peter Caspers 
>> <pca...@gm...>
>> wrote:
>>
>> Hello,
>>
>> in the JamshidianSwaptionEngine the option expiry date and the value 
>> date of the underlying swap are handled a bit simplified assuming 
>> both dates equal (see the warning in the code). Though the impact is 
>> usually not very big we might want to improve this detail in the 
>> library ? See below for a possible approach. Thank you Sebastian for our discussions on the topic.
>>
>> Aside I would be interested whether the Jamshidian method is still in 
>> use for model calibration in the world of multi curve enhanced models 
>> (where by enhanced I mean something simple like a static spread
>> correction) because I believe the generalization of the method to 
>> this setting is not straightforward. Also I feel that numerical 
>> integration does nearly a just as efficient and accurate job and it 
>> directly allows for multiple curve computations. Or do you ignore 
>> multi curve in the calibration phase and only adjust the curves for the actual pricing ?
>>
>> Back to Jamshidian and the start delay. Some theoretical background 
>> and numerical examples can be found here
>>
>> http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2246054
>>
>> A possible implementation goes as follows. First we need to provide 
>> an extended zerobond option method, which we can add to AffineModel 
>> in model.hpp
>>
>> https://github.com/pcaspers/quantlib/commit/e16b4ea5ffbfe33bd6acd0ee6
>> c
>> b3ecd8a43f72a4
>>
>> The default implementation uses the same simplification as mentioned 
>> above ignoring the bond start delay. To improve the pricing in the 
>> JamshidianEngine we have to overwrite this method in the model 
>> implementations for which we want it. For the Hull White model I did 
>> it here
>>
>> https://github.com/pcaspers/quantlib/commit/e8b5912cac2e236fe59a885e8
>> c
>> d1e2ed9243cc47
>>
>> Finally we have to modify the Jamshidian engine a bit
>>
>> https://github.com/pcaspers/quantlib/commit/019f37a498846d9a6e89a8973
>> 0
>> 0f126c01d6ef86
>>
>> (maybe we should keep some warning in the code because you are not 
>> forced to support the start delay in your model implementations)
>>
>> Not suprisingly the test suite breaks when comparing computation 
>> results to cached values computed with the simplified engine, so the 
>> cached values should be updated (given that we believe in the new
>> engine)
>>
>> 1>  Testing Hull-White calibration against cached values...
>> 1>  shortratemodels.cpp(126): error in
>> "QuantLib::detail::quantlib_test_case(&ShortRateModelTest::testCachedHullWhite)":
>> Failed to reproduce cached calibration results:
>> 1>  calculated: a = 0.0464041, sigma = 0.00579912, f(a) = 0.1158,
>> 1>  expected:   a = 0.0488565, sigma = 0.00593662, f(a) = 0.121599,
>> 1>  difference: a = -0.00245242, sigma = -0.000137495, f(a) = 
>> 1> -0.00579896,  end criteria = StationaryFunctionValue
>>
>> regards
>>   Peter
>>
>>
>> ---------------------------------------------------------------------
>> -
>> -------- Learn Graph Databases - Download FREE O'Reilly Book "Graph 
>> Databases" is the definitive new guide to graph databases and their 
>> applications. This 200-page book is written by three acclaimed 
>> leaders in the field. The early access version is available now.
>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>>
>>
>>
>>
>> This message is intended only for the stated addressee(s) and may be 
>> confidential. Access to this email by anyone else is unauthorised. 
>> Any opinions expressed in this email do not necessarily reflect the 
>> opinions of Fidessa. Any unauthorised disclosure, use or 
>> dissemination, either whole or in part is prohibited. If you are not 
>> the intended recipient of this message, please notify the sender immediately.
>> Fidessa plc registered in England and Wales no. 3781700. VAT 
>> registration no. GB688900878. Registered office - Dukes Court, Duke 
>> Street, Woking, Surrey, GU21 5BH, UK Fidessa buy-side ltd registered 
>> in England and Wales no. 3656437. VAT registration no. GB688900878.
>> Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 
>> 5BH, UK Fidessa group plc registered in England and Wales no. 3234176.
>> VAT registration no. GB688900878. Registered office - Dukes Court, 
>> Duke Street, Woking, Surrey, GU21 5BH, UK
>>
>>
>> ---------------------------------------------------------------------
>> -
>> -------- AlienVault Unified Security Management (USM) platform 
>> delivers complete security visibility with the essential security 
>> capabilities. Easily and efficiently configure, manage, and operate 
>> all of your security controls from a single console and one unified 
>> framework. Download a free trial.
>> http://p.sf.net/sfu/alienvault_d2d
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>
>
> This message is intended only for the stated addressee(s) and may be confidential. Access to this email by anyone else is unauthorised. Any opinions expressed in this email do not necessarily reflect the opinions of Fidessa. Any unauthorised disclosure, use or dissemination, either whole or in part is prohibited. If you are not the intended recipient of this message, please notify the sender immediately.
> Fidessa plc registered in England and Wales no. 3781700. VAT 
> registration no. GB688900878. Registered office - Dukes Court, Duke 
> Street, Woking, Surrey, GU21 5BH, UK Fidessa buy-side ltd registered 
> in England and Wales no. 3656437. VAT registration no. GB688900878. 
> Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 
> 5BH, UK Fidessa group plc registered in England and Wales no. 3234176. 
> VAT registration no. GB688900878. Registered office - Dukes Court, 
> Duke Street, Woking, Surrey, GU21 5BH, UK

Re: [Quantlib-dev] Mortgage backed securities [was:Jamshidian engine with start delay]

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

So you don't want to model prepayment? Or maybe you model it
elsewhere, and have a forecast stream of notionals? If that's the
case, you can use a simple bond (possibly amortized) as a proxy for
the MBS.

Luigi

[Note: cc'd to the list again, as the issue is of common interest]


On Tue, May 21, 2013 at 5:23 PM, Navtej Singh-Riyait
<Nav...@fi...> wrote:
> What I am interested in the calculation of accrued interest and price/yield or average yield for MBSs not sophisticated pricing.
>
> -----Original Message-----
> From: Luigi Ballabio [mailto:lui...@gm...]
> Sent: 21 May 2013 16:21
> To: Navtej Singh-Riyait
> Cc: qua...@li...
> Subject: Re: [Quantlib-dev] Mortgage backed securities [was:Jamshidian engine with start delay]
>
> Hello,
>     there's no support for MBS at this time.  What pricing model do you have in mind?
>
> Luigi
>
> On Fri, May 17, 2013 at 2:40 PM, Navtej Singh-Riyait <Nav...@fi...> wrote:
>> Is there a way I can incorporate accrued interest and yield
>> calculations for incorporate Mortgaged Backed Securities in QuantLib ?
>>
>>
>>
>> From: Ferdinando Ametrano [mailto:na...@am...]
>> Sent: 15 May 2013 09:19
>> To: Peter Caspers
>> Cc: qua...@li...
>> Subject: Re: [Quantlib-dev] Jamshidian engine with start delay
>>
>>
>>
>> I'm ok with your extension provided that the new values collapse back
>> to the old ones (with a reasonable tolerance) in the case of expiry
>> date being equal the value date.
>>
>> Is the data you've posted related to this case?
>>
>>
>>
>> It's a while now I do not work for a vol desk, but I would never
>> underestimate the huge difference of analytic vs numerical methods
>> when it comes to calibration.
>>
>>
>>
>> This said I would also add that I'm always amazed how poor the
>> production setup is, even in very sophisticated banks. Old models
>> stick around for very long time, just because of the huge effort
>> required to update them in production systems. The multi-curve
>> framework updates I've seen so far rival with Mary Shelley's
>> Frankenstein approach
>>
>>
>>
>>
>>
>> On Sat, May 11, 2013 at 1:37 PM, Peter Caspers
>> <pca...@gm...>
>> wrote:
>>
>> Hello,
>>
>> in the JamshidianSwaptionEngine the option expiry date and the value
>> date of the underlying swap are handled a bit simplified assuming both
>> dates equal (see the warning in the code). Though the impact is
>> usually not very big we might want to improve this detail in the
>> library ? See below for a possible approach. Thank you Sebastian for our discussions on the topic.
>>
>> Aside I would be interested whether the Jamshidian method is still in
>> use for model calibration in the world of multi curve enhanced models
>> (where by enhanced I mean something simple like a static spread
>> correction) because I believe the generalization of the method to this
>> setting is not straightforward. Also I feel that numerical integration
>> does nearly a just as efficient and accurate job and it directly
>> allows for multiple curve computations. Or do you ignore multi curve
>> in the calibration phase and only adjust the curves for the actual pricing ?
>>
>> Back to Jamshidian and the start delay. Some theoretical background
>> and numerical examples can be found here
>>
>> http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2246054
>>
>> A possible implementation goes as follows. First we need to provide an
>> extended zerobond option method, which we can add to AffineModel in
>> model.hpp
>>
>> https://github.com/pcaspers/quantlib/commit/e16b4ea5ffbfe33bd6acd0ee6c
>> b3ecd8a43f72a4
>>
>> The default implementation uses the same simplification as mentioned
>> above ignoring the bond start delay. To improve the pricing in the
>> JamshidianEngine we have to overwrite this method in the model
>> implementations for which we want it. For the Hull White model I did
>> it here
>>
>> https://github.com/pcaspers/quantlib/commit/e8b5912cac2e236fe59a885e8c
>> d1e2ed9243cc47
>>
>> Finally we have to modify the Jamshidian engine a bit
>>
>> https://github.com/pcaspers/quantlib/commit/019f37a498846d9a6e89a89730
>> 0f126c01d6ef86
>>
>> (maybe we should keep some warning in the code because you are not
>> forced to support the start delay in your model implementations)
>>
>> Not suprisingly the test suite breaks when comparing computation
>> results to cached values computed with the simplified engine, so the
>> cached values should be updated (given that we believe in the new
>> engine)
>>
>> 1>  Testing Hull-White calibration against cached values...
>> 1>  shortratemodels.cpp(126): error in
>> "QuantLib::detail::quantlib_test_case(&ShortRateModelTest::testCachedHullWhite)":
>> Failed to reproduce cached calibration results:
>> 1>  calculated: a = 0.0464041, sigma = 0.00579912, f(a) = 0.1158,
>> 1>  expected:   a = 0.0488565, sigma = 0.00593662, f(a) = 0.121599,
>> 1>  difference: a = -0.00245242, sigma = -0.000137495, f(a) =
>> 1> -0.00579896,  end criteria = StationaryFunctionValue
>>
>> regards
>>   Peter
>>
>>
>> ----------------------------------------------------------------------
>> -------- Learn Graph Databases - Download FREE O'Reilly Book "Graph
>> Databases" is the definitive new guide to graph databases and their
>> applications. This 200-page book is written by three acclaimed leaders
>> in the field. The early access version is available now.
>> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>>
>>
>>
>>
>> This message is intended only for the stated addressee(s) and may be
>> confidential. Access to this email by anyone else is unauthorised. Any
>> opinions expressed in this email do not necessarily reflect the
>> opinions of Fidessa. Any unauthorised disclosure, use or
>> dissemination, either whole or in part is prohibited. If you are not
>> the intended recipient of this message, please notify the sender immediately.
>> Fidessa plc registered in England and Wales no. 3781700. VAT
>> registration no. GB688900878. Registered office - Dukes Court, Duke
>> Street, Woking, Surrey, GU21 5BH, UK Fidessa buy-side ltd registered
>> in England and Wales no. 3656437. VAT registration no. GB688900878.
>> Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21
>> 5BH, UK Fidessa group plc registered in England and Wales no. 3234176.
>> VAT registration no. GB688900878. Registered office - Dukes Court,
>> Duke Street, Woking, Surrey, GU21 5BH, UK
>>
>>
>> ----------------------------------------------------------------------
>> -------- AlienVault Unified Security Management (USM) platform
>> delivers complete security visibility with the essential security
>> capabilities. Easily and efficiently configure, manage, and operate
>> all of your security controls from a single console and one unified
>> framework. Download a free trial.
>> http://p.sf.net/sfu/alienvault_d2d
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>
>
> This message is intended only for the stated addressee(s) and may be confidential. Access to this email by anyone else is unauthorised. Any opinions expressed in this email do not necessarily reflect the opinions of Fidessa. Any unauthorised disclosure, use or dissemination, either whole or in part is prohibited. If you are not the intended recipient of this message, please notify the sender immediately.
> Fidessa plc registered in England and Wales no. 3781700. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK
> Fidessa buy-side ltd registered in England and Wales no. 3656437. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK
> Fidessa group plc registered in England and Wales no. 3234176. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK

Re: [Quantlib-dev] Mortgage backed securities [was:Jamshidian engine with start delay]

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

Hello,
    there's no support for MBS at this time.  What pricing model do
you have in mind?

Luigi

On Fri, May 17, 2013 at 2:40 PM, Navtej Singh-Riyait
<Nav...@fi...> wrote:
> Is there a way I can incorporate accrued interest and yield calculations for
> incorporate Mortgaged Backed Securities in QuantLib ?
>
>
>
> From: Ferdinando Ametrano [mailto:na...@am...]
> Sent: 15 May 2013 09:19
> To: Peter Caspers
> Cc: qua...@li...
> Subject: Re: [Quantlib-dev] Jamshidian engine with start delay
>
>
>
> I'm ok with your extension provided that the new values collapse back to the
> old ones (with a reasonable tolerance) in the case of expiry date being
> equal the value date.
>
> Is the data you've posted related to this case?
>
>
>
> It's a while now I do not work for a vol desk, but I would never
> underestimate the huge difference of analytic vs numerical methods when it
> comes to calibration.
>
>
>
> This said I would also add that I'm always amazed how poor the production
> setup is, even in very sophisticated banks. Old models stick around for very
> long time, just because of the huge effort required to update them in
> production systems. The multi-curve framework updates I've seen so far rival
> with Mary Shelley's Frankenstein approach
>
>
>
>
>
> On Sat, May 11, 2013 at 1:37 PM, Peter Caspers <pca...@gm...>
> wrote:
>
> Hello,
>
> in the JamshidianSwaptionEngine the option expiry date and the value date of
> the underlying swap are handled a bit simplified assuming both dates equal
> (see the warning in the code). Though the impact is usually not very big we
> might want to improve this detail in the library ? See below for a possible
> approach. Thank you Sebastian for our discussions on the topic.
>
> Aside I would be interested whether the Jamshidian method is still in use
> for model calibration in the world of multi curve enhanced models (where by
> enhanced I mean something simple like a static spread correction) because I
> believe the generalization of the method to this setting is not
> straightforward. Also I feel that numerical integration does nearly a just
> as efficient and accurate job and it directly allows for multiple curve
> computations. Or do you ignore multi curve in the calibration phase and only
> adjust the curves for the actual pricing ?
>
> Back to Jamshidian and the start delay. Some theoretical background and
> numerical examples can be found here
>
> http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2246054
>
> A possible implementation goes as follows. First we need to provide an
> extended zerobond option method, which we can add to AffineModel in
> model.hpp
>
> https://github.com/pcaspers/quantlib/commit/e16b4ea5ffbfe33bd6acd0ee6cb3ecd8a43f72a4
>
> The default implementation uses the same simplification as mentioned above
> ignoring the bond start delay. To improve the pricing in the
> JamshidianEngine we have to overwrite this method in the model
> implementations for which we want it. For the Hull White model I did it here
>
> https://github.com/pcaspers/quantlib/commit/e8b5912cac2e236fe59a885e8cd1e2ed9243cc47
>
> Finally we have to modify the Jamshidian engine a bit
>
> https://github.com/pcaspers/quantlib/commit/019f37a498846d9a6e89a897300f126c01d6ef86
>
> (maybe we should keep some warning in the code because you are not forced to
> support the start delay in your model implementations)
>
> Not suprisingly the test suite breaks when comparing computation results to
> cached values computed with the simplified engine, so the cached values
> should be updated (given that we believe in the new engine)
>
> 1>  Testing Hull-White calibration against cached values...
> 1>  shortratemodels.cpp(126): error in
> "QuantLib::detail::quantlib_test_case(&ShortRateModelTest::testCachedHullWhite)":
> Failed to reproduce cached calibration results:
> 1>  calculated: a = 0.0464041, sigma = 0.00579912, f(a) = 0.1158,
> 1>  expected:   a = 0.0488565, sigma = 0.00593662, f(a) = 0.121599,
> 1>  difference: a = -0.00245242, sigma = -0.000137495, f(a) = -0.00579896,
> 1>  end criteria = StationaryFunctionValue
>
> regards
>   Peter
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
>
>
>
> This message is intended only for the stated addressee(s) and may be
> confidential. Access to this email by anyone else is unauthorised. Any
> opinions expressed in this email do not necessarily reflect the opinions of
> Fidessa. Any unauthorised disclosure, use or dissemination, either whole or
> in part is prohibited. If you are not the intended recipient of this
> message, please notify the sender immediately.
> Fidessa plc registered in England and Wales no. 3781700. VAT registration
> no. GB688900878. Registered office - Dukes Court, Duke Street, Woking,
> Surrey, GU21 5BH, UK
> Fidessa buy-side ltd registered in England and Wales no. 3656437. VAT
> registration no. GB688900878. Registered office - Dukes Court, Duke Street,
> Woking, Surrey, GU21 5BH, UK
> Fidessa group plc registered in England and Wales no. 3234176. VAT
> registration no. GB688900878. Registered office - Dukes Court, Duke Street,
> Woking, Surrey, GU21 5BH, UK
>
>
> ------------------------------------------------------------------------------
> AlienVault Unified Security Management (USM) platform delivers complete
> security visibility with the essential security capabilities. Easily and
> efficiently configure, manage, and operate all of your security controls
> from a single console and one unified framework. Download a free trial.
> http://p.sf.net/sfu/alienvault_d2d
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

Re: [Quantlib-dev] Jamshidian engine with start delay

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

ok, I have extended the test suite here

https://github.com/pcaspers/quantlib/commit/4e5a10ef9c45e940965316a3c7c4d698b3906e1b

(the commits regarding the changes in the library were

https://github.com/pcaspers/quantlib/commit/e8b5912cac2e236fe59a885e8cd1e2ed9243cc47
https://github.com/pcaspers/quantlib/commit/019f37a498846d9a6e89a897300f126c01d6ef86
https://github.com/pcaspers/quantlib/commit/e16b4ea5ffbfe33bd6acd0ee6cb3ecd8a43f72a4

and the doc was here

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2246054

)

please just tell me if I can do anything else.

regards
 Peter

Ferdinando Ametrano <na...@am...> writes:

> On Wed, May 15, 2013 at 9:03 PM, Peter Caspers <pca...@gm...> wrote:
>
>     We could maybe produce cached
>     values with the old engine for a test case with expiry = start date
>     before moving to the new engine.
>
>
> agreed, as far as I am concerned

Re: [Quantlib-dev] Jamshidian engine with start delay

[Ferdinando A. <na...@am...>]

On Wed, May 15, 2013 at 9:03 PM, Peter Caspers <pca...@gm...>wrote:

> We could maybe produce cached
> values with the old engine for a test case with expiry = start date
> before moving to the new engine.
>

agreed, as far as I am concerned

Re: [Quantlib-dev] Jamshidian engine with start delay

[Navtej Singh-R. <Nav...@fi...>]

Is there a way I can incorporate accrued interest and yield calculations for incorporate Mortgaged Backed Securities in QuantLib ?

From: Ferdinando Ametrano [mailto:na...@am...]
Sent: 15 May 2013 09:19
To: Peter Caspers
Cc: qua...@li...
Subject: Re: [Quantlib-dev] Jamshidian engine with start delay

I'm ok with your extension provided that the new values collapse back to the old ones (with a reasonable tolerance) in the case of expiry date being equal the value date.
Is the data you've posted related to this case?

It's a while now I do not work for a vol desk, but I would never underestimate the huge difference of analytic vs numerical methods when it comes to calibration.

This said I would also add that I'm always amazed how poor the production setup is, even in very sophisticated banks. Old models stick around for very long time, just because of the huge effort required to update them in production systems. The multi-curve framework updates I've seen so far rival with Mary Shelley's Frankenstein approach


On Sat, May 11, 2013 at 1:37 PM, Peter Caspers <pca...@gm...<mailto:pca...@gm...>> wrote:
Hello,

in the JamshidianSwaptionEngine the option expiry date and the value date of the underlying swap are handled a bit simplified assuming both dates equal (see the warning in the code). Though the impact is usually not very big we might want to improve this detail in the library ? See below for a possible approach. Thank you Sebastian for our discussions on the topic.

Aside I would be interested whether the Jamshidian method is still in use for model calibration in the world of multi curve enhanced models (where by enhanced I mean something simple like a static spread correction) because I believe the generalization of the method to this setting is not straightforward. Also I feel that numerical integration does nearly a just as efficient and accurate job and it directly allows for multiple curve computations. Or do you ignore multi curve in the calibration phase and only adjust the curves for the actual pricing ?

Back to Jamshidian and the start delay. Some theoretical background and numerical examples can be found here

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2246054

A possible implementation goes as follows. First we need to provide an extended zerobond option method, which we can add to AffineModel in model.hpp

https://github.com/pcaspers/quantlib/commit/e16b4ea5ffbfe33bd6acd0ee6cb3ecd8a43f72a4
<https://github.com/pcaspers/quantlib/commit/b65c50a1147d6ea386b33e4e09b09901200d71ac>
The default implementation uses the same simplification as mentioned above ignoring the bond start delay. To improve the pricing in the JamshidianEngine we have to overwrite this method in the model implementations for which we want it. For the Hull White model I did it here

https://github.com/pcaspers/quantlib/commit/e8b5912cac2e236fe59a885e8cd1e2ed9243cc47

Finally we have to modify the Jamshidian engine a bit

https://github.com/pcaspers/quantlib/commit/019f37a498846d9a6e89a897300f126c01d6ef86

(maybe we should keep some warning in the code because you are not forced to support the start delay in your model implementations)

Not suprisingly the test suite breaks when comparing computation results to cached values computed with the simplified engine, so the cached values should be updated (given that we believe in the new engine)

1>  Testing Hull-White calibration against cached values...
1>  shortratemodels.cpp(126): error in "QuantLib::detail::quantlib_test_case(&ShortRateModelTest::testCachedHullWhite)": Failed to reproduce cached calibration results:
1>  calculated: a = 0.0464041, sigma = 0.00579912, f(a) = 0.1158,
1>  expected:   a = 0.0488565, sigma = 0.00593662, f(a) = 0.121599,
1>  difference: a = -0.00245242, sigma = -0.000137495, f(a) = -0.00579896,
1>  end criteria = StationaryFunctionValue

regards
  Peter

------------------------------------------------------------------------------
Learn Graph Databases - Download FREE O'Reilly Book
"Graph Databases" is the definitive new guide to graph databases and
their applications. This 200-page book is written by three acclaimed
leaders in the field. The early access version is available now.
Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
_______________________________________________
QuantLib-dev mailing list
Qua...@li...<mailto:Qua...@li...>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev




This message is intended only for the stated addressee(s) and may be confidential. Access to this email by anyone else is unauthorised. Any opinions expressed in this email do not necessarily reflect the opinions of Fidessa. Any unauthorised disclosure, use or dissemination, either whole or in part is prohibited. If you are not the intended recipient of this message, please notify the sender immediately.
Fidessa plc registered in England and Wales no. 3781700. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK
Fidessa buy-side ltd registered in England and Wales no. 3656437. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK
Fidessa group plc registered in England and Wales no. 3234176. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK

Re: [Quantlib-dev] Jamshidian engine with start delay

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

For zero days between option and start date the results are identical up to
1E-14, for example the old engine resp. new engine gives

0.06257488979659526
0.06257488979659394

for a 5y into 5y atm swaption vs. Euribor 6m, 3% forward flat yts, 1% volatility and
reversion, asof 30-04-2013.

The differences in the test suite displayed below are much bigger because there
a start delay of 2 business days applies. We could maybe produce cached
values with the old engine for a test case with expiry = start date
before moving to the new engine.

Thanks for your comments.

regards
 Peter


Ferdinando Ametrano <na...@am...> writes:

> I'm ok with your extension provided that the new values collapse back to the
> old ones (with a reasonable tolerance) in the case of expiry date being equal
> the value date.
> Is the data you've posted related to this case?
>
> It's a while now I do not work for a vol desk, but I would never underestimate
> the huge difference of analytic vs numerical methods when it comes to
> calibration.
>
> This said I would also add that I'm always amazed how poor the production setup
> is, even in very sophisticated banks. Old models stick around for very long
> time, just because of the huge effort required to update them in production
> systems. The multi-curve framework updates I've seen so far rival with Mary
> Shelley's Frankenstein approach
>
>
> On Sat, May 11, 2013 at 1:37 PM, Peter Caspers <pca...@gm...> wrote:
>
>     Hello,
>
>     in the JamshidianSwaptionEngine the option expiry date and the value date
>     of the underlying swap are handled a bit simplified assuming both dates
>     equal (see the warning in the code). Though the impact is usually not very
>     big we might want to improve this detail in the library ? See below for a
>     possible approach. Thank you Sebastian for our discussions on the topic.
>
>     Aside I would be interested whether the Jamshidian method is still in use
>     for model calibration in the world of multi curve enhanced models (where by
>     enhanced I mean something simple like a static spread correction) because I
>     believe the generalization of the method to this setting is not
>     straightforward. Also I feel that numerical integration does nearly a just
>     as efficient and accurate job and it directly allows for multiple curve
>     computations. Or do you ignore multi curve in the calibration phase and
>     only adjust the curves for the actual pricing ?
>
>     Back to Jamshidian and the start delay. Some theoretical background and
>     numerical examples can be found here
>
>     http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2246054
>
>     A possible implementation goes as follows. First we need to provide an
>     extended zerobond option method, which we can add to AffineModel in
>     model.hpp
>
>     https://github.com/pcaspers/quantlib/commit/
>     e16b4ea5ffbfe33bd6acd0ee6cb3ecd8a43f72a4
>
>     The default implementation uses the same simplification as mentioned above
>     ignoring the bond start delay. To improve the pricing in the
>     JamshidianEngine we have to overwrite this method in the model
>     implementations for which we want it. For the Hull White model I did it
>     here
>
>     https://github.com/pcaspers/quantlib/commit/
>     e8b5912cac2e236fe59a885e8cd1e2ed9243cc47
>
>     Finally we have to modify the Jamshidian engine a bit
>
>     https://github.com/pcaspers/quantlib/commit/
>     019f37a498846d9a6e89a897300f126c01d6ef86
>
>     (maybe we should keep some warning in the code because you are not forced
>     to support the start delay in your model implementations)
>
>     Not suprisingly the test suite breaks when comparing computation results to
>     cached values computed with the simplified engine, so the cached values
>     should be updated (given that we believe in the new engine)
>
>     1>  Testing Hull-White calibration against cached values...
>     1>  shortratemodels.cpp(126): error in
>     "QuantLib::detail::quantlib_test_case(&
>     ShortRateModelTest::testCachedHullWhite)": Failed to reproduce cached
>     calibration results:
>     1>  calculated: a = 0.0464041, sigma = 0.00579912, f(a) = 0.1158,
>     1>  expected:   a = 0.0488565, sigma = 0.00593662, f(a) = 0.121599,
>     1>  difference: a = -0.00245242, sigma = -0.000137495, f(a) = -0.00579896,
>     1>  end criteria = StationaryFunctionValue
>
>     regards
>       Peter
>
>    
>     ------------------------------------------------------------------------------
>     Learn Graph Databases - Download FREE O'Reilly Book
>     "Graph Databases" is the definitive new guide to graph databases and
>     their applications. This 200-page book is written by three acclaimed
>     leaders in the field. The early access version is available now.
>     Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
>     _______________________________________________
>     QuantLib-dev mailing list
>     Qua...@li...
>     https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Jamshidian engine with start delay

[Ferdinando A. <na...@am...>]

I'm ok with your extension provided that the new values collapse back to
the old ones (with a reasonable tolerance) in the case of expiry date being
equal the value date.
Is the data you've posted related to this case?

It's a while now I do not work for a vol desk, but I would never
underestimate the huge difference of analytic vs numerical methods when it
comes to calibration.

This said I would also add that I'm always amazed how poor the production
setup is, even in very sophisticated banks. Old models stick around for
very long time, just because of the huge effort required to update them in
production systems. The multi-curve framework updates I've seen so far
rival with Mary Shelley's Frankenstein approach


On Sat, May 11, 2013 at 1:37 PM, Peter Caspers <pca...@gm...>wrote:

>  Hello,
>
> in the JamshidianSwaptionEngine the option expiry date and the value date
> of the underlying swap are handled a bit simplified assuming both dates
> equal (see the warning in the code). Though the impact is usually not very
> big we might want to improve this detail in the library ? See below for a
> possible approach. Thank you Sebastian for our discussions on the topic.
>
> Aside I would be interested whether the Jamshidian method is still in use
> for model calibration in the world of multi curve enhanced models (where by
> enhanced I mean something simple like a static spread correction) because I
> believe the generalization of the method to this setting is not
> straightforward. Also I feel that numerical integration does nearly a just
> as efficient and accurate job and it directly allows for multiple curve
> computations. Or do you ignore multi curve in the calibration phase and
> only adjust the curves for the actual pricing ?
>
> Back to Jamshidian and the start delay. Some theoretical background and
> numerical examples can be found here
>
> http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2246054
>
> A possible implementation goes as follows. First we need to provide an
> extended zerobond option method, which we can add to AffineModel in
> model.hpp
>
>
> https://github.com/pcaspers/quantlib/commit/e16b4ea5ffbfe33bd6acd0ee6cb3ecd8a43f72a4
> <https://github.com/pcaspers/quantlib/commit/b65c50a1147d6ea386b33e4e09b09901200d71ac>
> The default implementation uses the same simplification as mentioned above
> ignoring the bond start delay. To improve the pricing in the
> JamshidianEngine we have to overwrite this method in the model
> implementations for which we want it. For the Hull White model I did it here
>
>
> https://github.com/pcaspers/quantlib/commit/e8b5912cac2e236fe59a885e8cd1e2ed9243cc47
>
> Finally we have to modify the Jamshidian engine a bit
>
>
> https://github.com/pcaspers/quantlib/commit/019f37a498846d9a6e89a897300f126c01d6ef86
>
> (maybe we should keep some warning in the code because you are not forced
> to support the start delay in your model implementations)
>
> Not suprisingly the test suite breaks when comparing computation results
> to cached values computed with the simplified engine, so the cached values
> should be updated (given that we believe in the new engine)
>
> 1>  Testing Hull-White calibration against cached values...
> 1>  shortratemodels.cpp(126): error in
> "QuantLib::detail::quantlib_test_case(&ShortRateModelTest::testCachedHullWhite)":
> Failed to reproduce cached calibration results:
> 1>  calculated: a = 0.0464041, sigma = 0.00579912, f(a) = 0.1158,
> 1>  expected:   a = 0.0488565, sigma = 0.00593662, f(a) = 0.121599,
> 1>  difference: a = -0.00245242, sigma = -0.000137495, f(a) = -0.00579896,
> 1>  end criteria = StationaryFunctionValue
>
> regards
>   Peter
>
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and
> their applications. This 200-page book is written by three acclaimed
> leaders in the field. The early access version is available now.
> Download your free book today! http://p.sf.net/sfu/neotech_d2d_may
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>

[Quantlib-dev] Jamshidian engine with start delay

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

Hello,

in the JamshidianSwaptionEngine the option expiry date and the value 
date of the underlying swap are handled a bit simplified assuming both 
dates equal (see the warning in the code). Though the impact is usually 
not very big we might want to improve this detail in the library ? See 
below for a possible approach. Thank you Sebastian for our discussions 
on the topic.

Aside I would be interested whether the Jamshidian method is still in 
use for model calibration in the world of multi curve enhanced models 
(where by enhanced I mean something simple like a static spread 
correction) because I believe the generalization of the method to this 
setting is not straightforward. Also I feel that numerical integration 
does nearly a just as efficient and accurate job and it directly allows 
for multiple curve computations. Or do you ignore multi curve in the 
calibration phase and only adjust the curves for the actual pricing ?

Back to Jamshidian and the start delay. Some theoretical background and 
numerical examples can be found here

http://papers.ssrn.com/sol3/papers.cfm?abstract_id=2246054

A possible implementation goes as follows. First we need to provide an 
extended zerobond option method, which we can add to AffineModel in 
model.hpp

https://github.com/pcaspers/quantlib/commit/e16b4ea5ffbfe33bd6acd0ee6cb3ecd8a43f72a4
<https://github.com/pcaspers/quantlib/commit/b65c50a1147d6ea386b33e4e09b09901200d71ac>
The default implementation uses the same simplification as mentioned 
above ignoring the bond start delay. To improve the pricing in the 
JamshidianEngine we have to overwrite this method in the model 
implementations for which we want it. For the Hull White model I did it here

https://github.com/pcaspers/quantlib/commit/e8b5912cac2e236fe59a885e8cd1e2ed9243cc47

Finally we have to modify the Jamshidian engine a bit

https://github.com/pcaspers/quantlib/commit/019f37a498846d9a6e89a897300f126c01d6ef86

(maybe we should keep some warning in the code because you are not 
forced to support the start delay in your model implementations)

Not suprisingly the test suite breaks when comparing computation results 
to cached values computed with the simplified engine, so the cached 
values should be updated (given that we believe in the new engine)

1>  Testing Hull-White calibration against cached values...
1>  shortratemodels.cpp(126): error in 
"QuantLib::detail::quantlib_test_case(&ShortRateModelTest::testCachedHullWhite)": 
Failed to reproduce cached calibration results:
1>  calculated: a = 0.0464041, sigma = 0.00579912, f(a) = 0.1158,
1>  expected:   a = 0.0488565, sigma = 0.00593662, f(a) = 0.121599,
1>  difference: a = -0.00245242, sigma = -0.000137495, f(a) = -0.00579896,
1>  end criteria = StationaryFunctionValue

regards
   Peter

Re: [Quantlib-dev] Pricing engines in Excel

[Grześ A. <gan...@gm...>]

Also,
I get the error while trying to compile the product I added:
Error    1    error LNK2019: unresolved external symbol "void __cdecl
registerCatbonds(struct xloper const &)"
(?registerCatbonds@@YAXABUxloper@@@Z) referenced in function "void
__cdecl registerQlFunctions(struct xloper const &)"
(?registerQlFunctions@@YAXABUxloper@@@Z)
C:\Users\ga1009\Documents\QuantLib\QuantLibXL\qlxl\register_all.obj
Error    2    error LNK2019: unresolved external symbol "void __cdecl
unregisterCatbonds(struct xloper const &)"
(?unregisterCatbonds@@YAXABUxloper@@@Z) referenced in function "void
__cdecl unregisterQlFunctions(struct xloper const &)"
(?unregisterQlFunctions@@YAXABUxloper@@@Z)
C:\Users\ga1009\Documents\QuantLib\QuantLibXL\qlxl\register_all.obj

What do I need to do to have these register methods generated?

Regards,
Grzegorz

On 2 May 2013 16:17, Grześ Andruszkiewicz <gan...@gm...> wrote:
> Hi,
>
> I am trying to extend the XL QuantLib project to handle CatBonds. I
> added the bond class as described in the tutorial:
> http://quantlib.org/quantlibaddin/extend_tutorial.html
>
> I am struggling to add the corresponding pricing engine though. Where
> can I find information on how to do it?
>
> Cheers,
> Grzegorz

[Quantlib-dev] Pricing engines in Excel

[Grześ A. <gan...@gm...>]

Hi,

I am trying to extend the XL QuantLib project to handle CatBonds. I
added the bond class as described in the tutorial:
http://quantlib.org/quantlibaddin/extend_tutorial.html

I am struggling to add the corresponding pricing engine though. Where
can I find information on how to do it?

Cheers,
Grzegorz

Re: [Quantlib-dev] Excel interface

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

Not yet, but I think notifications might be sent out daily or
something.  Thanks, I'll have a look.

Later,
    Luigi


On Thu, May 2, 2013 at 4:18 PM, Grześ Andruszkiewicz <gan...@gm...> wrote:
> Hi Luigi,
>
> I am doing just that at this very moment :).
>
> Also, I submitted a patch with the actual code to source forge earlier
> today, I hope you received the notification.
>
> Cheers,
> Grzegorz
>
> On 2 May 2013 15:15, Luigi Ballabio <lui...@gm...> wrote:
>> Hi Grzegorz,
>>     for the addin we use in-house, we ended up extending the existing
>> project.  We tried creating a new project, but it caused us a lot of
>> headaches.
>>
>> Luigi
>>
>> On Fri, Apr 12, 2013 at 5:47 PM, Grześ Andruszkiewicz
>> <gan...@gm...> wrote:
>>> Thanks! I haven't actually seen these before!
>>>
>>> After having a quick look: is it possible to extend the Excel
>>> interface by creating a new project rather than extending the main
>>> one?
>>>
>>> Regards,
>>> Grzegorz
>>>
>>> On 12 April 2013 16:28,  <ja...@fr...> wrote:
>>>> Hi,
>>>> did you look at these ones?
>>>> http://quantlib.org/quantlibaddin/extend_tutorial.html
>>>> http://quantlib.org/quantlibaddin/extend_template_tutorial.html
>>>>
>>>> Also theres the QLXL-docs coming along the release.
>>>>
>>>> I learned also by starting with simple classes and reverse eng/debugging the thing. Its not as bad as it sounds.
>>>>
>>>> Best
>>>> pp
>>>>
>>>>
>>>> ----- Original Message -----
>>>> From: "Grześ Andruszkiewicz" <gan...@gm...>
>>>> To: qua...@li...
>>>> Cc: "Lorenzo Pitotti" <l.p...@im...>
>>>> Sent: Friday, 12 April, 2013 5:08:41 PM
>>>> Subject: [Quantlib-dev] Excel interface
>>>>
>>>> Hi,
>>>>
>>>> I would like to use the instrument I developed in QuantLib in Excel. I
>>>> was looking at the QuantLibXL project, but it is not obvious how to
>>>> use it nor extend it. Also, I haven't actually used the Excel add-in
>>>> even with the standard instruments...
>>>>
>>>> 1). Where can I find a tutorial to see how to use the existing add-in,
>>>> run the example workbooks, etc.?
>>>> 2). Is there any documentation on how to add new stuff to the project?
>>>>
>>>> I would be grateful for any other hints.
>>>>
>>>> Regards,
>>>> Grzegorz
>>>>
>>>> ------------------------------------------------------------------------------
>>>> Precog is a next-generation analytics platform capable of advanced
>>>> analytics on semi-structured data. The platform includes APIs for building
>>>> apps and a phenomenal toolset for data science. Developers can use
>>>> our toolset for easy data analysis & visualization. Get a free account!
>>>> http://www2.precog.com/precogplatform/slashdotnewsletter
>>>> _______________________________________________
>>>> QuantLib-dev mailing list
>>>> Qua...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>>
>>> ------------------------------------------------------------------------------
>>> Precog is a next-generation analytics platform capable of advanced
>>> analytics on semi-structured data. The platform includes APIs for building
>>> apps and a phenomenal toolset for data science. Developers can use
>>> our toolset for easy data analysis & visualization. Get a free account!
>>> http://www2.precog.com/precogplatform/slashdotnewsletter
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Excel interface

[Grześ A. <gan...@gm...>]

Hi Luigi,

I am doing just that at this very moment :).

Also, I submitted a patch with the actual code to source forge earlier
today, I hope you received the notification.

Cheers,
Grzegorz

On 2 May 2013 15:15, Luigi Ballabio <lui...@gm...> wrote:
> Hi Grzegorz,
>     for the addin we use in-house, we ended up extending the existing
> project.  We tried creating a new project, but it caused us a lot of
> headaches.
>
> Luigi
>
> On Fri, Apr 12, 2013 at 5:47 PM, Grześ Andruszkiewicz
> <gan...@gm...> wrote:
>> Thanks! I haven't actually seen these before!
>>
>> After having a quick look: is it possible to extend the Excel
>> interface by creating a new project rather than extending the main
>> one?
>>
>> Regards,
>> Grzegorz
>>
>> On 12 April 2013 16:28,  <ja...@fr...> wrote:
>>> Hi,
>>> did you look at these ones?
>>> http://quantlib.org/quantlibaddin/extend_tutorial.html
>>> http://quantlib.org/quantlibaddin/extend_template_tutorial.html
>>>
>>> Also theres the QLXL-docs coming along the release.
>>>
>>> I learned also by starting with simple classes and reverse eng/debugging the thing. Its not as bad as it sounds.
>>>
>>> Best
>>> pp
>>>
>>>
>>> ----- Original Message -----
>>> From: "Grześ Andruszkiewicz" <gan...@gm...>
>>> To: qua...@li...
>>> Cc: "Lorenzo Pitotti" <l.p...@im...>
>>> Sent: Friday, 12 April, 2013 5:08:41 PM
>>> Subject: [Quantlib-dev] Excel interface
>>>
>>> Hi,
>>>
>>> I would like to use the instrument I developed in QuantLib in Excel. I
>>> was looking at the QuantLibXL project, but it is not obvious how to
>>> use it nor extend it. Also, I haven't actually used the Excel add-in
>>> even with the standard instruments...
>>>
>>> 1). Where can I find a tutorial to see how to use the existing add-in,
>>> run the example workbooks, etc.?
>>> 2). Is there any documentation on how to add new stuff to the project?
>>>
>>> I would be grateful for any other hints.
>>>
>>> Regards,
>>> Grzegorz
>>>
>>> ------------------------------------------------------------------------------
>>> Precog is a next-generation analytics platform capable of advanced
>>> analytics on semi-structured data. The platform includes APIs for building
>>> apps and a phenomenal toolset for data science. Developers can use
>>> our toolset for easy data analysis & visualization. Get a free account!
>>> http://www2.precog.com/precogplatform/slashdotnewsletter
>>> _______________________________________________
>>> QuantLib-dev mailing list
>>> Qua...@li...
>>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>> ------------------------------------------------------------------------------
>> Precog is a next-generation analytics platform capable of advanced
>> analytics on semi-structured data. The platform includes APIs for building
>> apps and a phenomenal toolset for data science. Developers can use
>> our toolset for easy data analysis & visualization. Get a free account!
>> http://www2.precog.com/precogplatform/slashdotnewsletter
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] Excel interface

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

Hi Grzegorz,
    for the addin we use in-house, we ended up extending the existing
project.  We tried creating a new project, but it caused us a lot of
headaches.

Luigi

On Fri, Apr 12, 2013 at 5:47 PM, Grześ Andruszkiewicz
<gan...@gm...> wrote:
> Thanks! I haven't actually seen these before!
>
> After having a quick look: is it possible to extend the Excel
> interface by creating a new project rather than extending the main
> one?
>
> Regards,
> Grzegorz
>
> On 12 April 2013 16:28,  <ja...@fr...> wrote:
>> Hi,
>> did you look at these ones?
>> http://quantlib.org/quantlibaddin/extend_tutorial.html
>> http://quantlib.org/quantlibaddin/extend_template_tutorial.html
>>
>> Also theres the QLXL-docs coming along the release.
>>
>> I learned also by starting with simple classes and reverse eng/debugging the thing. Its not as bad as it sounds.
>>
>> Best
>> pp
>>
>>
>> ----- Original Message -----
>> From: "Grześ Andruszkiewicz" <gan...@gm...>
>> To: qua...@li...
>> Cc: "Lorenzo Pitotti" <l.p...@im...>
>> Sent: Friday, 12 April, 2013 5:08:41 PM
>> Subject: [Quantlib-dev] Excel interface
>>
>> Hi,
>>
>> I would like to use the instrument I developed in QuantLib in Excel. I
>> was looking at the QuantLibXL project, but it is not obvious how to
>> use it nor extend it. Also, I haven't actually used the Excel add-in
>> even with the standard instruments...
>>
>> 1). Where can I find a tutorial to see how to use the existing add-in,
>> run the example workbooks, etc.?
>> 2). Is there any documentation on how to add new stuff to the project?
>>
>> I would be grateful for any other hints.
>>
>> Regards,
>> Grzegorz
>>
>> ------------------------------------------------------------------------------
>> Precog is a next-generation analytics platform capable of advanced
>> analytics on semi-structured data. The platform includes APIs for building
>> apps and a phenomenal toolset for data science. Developers can use
>> our toolset for easy data analysis & visualization. Get a free account!
>> http://www2.precog.com/precogplatform/slashdotnewsletter
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
> ------------------------------------------------------------------------------
> Precog is a next-generation analytics platform capable of advanced
> analytics on semi-structured data. The platform includes APIs for building
> apps and a phenomenal toolset for data science. Developers can use
> our toolset for easy data analysis & visualization. Get a free account!
> http://www2.precog.com/precogplatform/slashdotnewsletter
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] XL bindings fail to build

[Grześ A. <gan...@gm...>]

Hi,

I am trying to build the QL XL project (full, in VC10), but it fails.
It seems that the problem is this:

Build started 01/05/2013 16:14:01.
     1>Project "C:\Users\ga\Documents\dev\QuantLib\ObjectHandler\gensrc\ohgensrc_vc10.vcxproj"
on node 4 (rebuild target(s)).
     1>CoreClean:
         NMAKE /f Makefile.vc clean

         Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
         Copyright (C) Microsoft Corporation.  All rights reserved.

         C:\Users\ga\Documents\dev\QuantLib\ObjectHandler\gensrc\build\vc\ohgensrc_vc10.log
         The process cannot access the file because it is being used
by another process.
       Rebuild:
         NMAKE /f Makefile.vc /a

         Microsoft (R) Program Maintenance Utility Version 10.00.30319.01
         Copyright (C) Microsoft Corporation.  All rights reserved.

             if not exist build\vc mkdir build\vc
             ..\..\gensrc\gensrc.py -xdlv --oh_dir=..
           File "C:\Users\ga\Documents\dev\QuantLib\gensrc\gensrc.py", line 51
             print USAGE_ERROR % { 'scriptName' : sys.argv[0] }
                             ^
         SyntaxError: invalid syntax
     1>NMAKE : fatal error U1077: '..\..\gensrc\gensrc.py' : return code '0x1'
         Stop.
     1>C:\Program
Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.MakeFile.Targets(43,5):
error MSB3073: The command "NMAKE /f Makefile.vc /a" exited with code
2.
     1>Done Building Project
"C:\Users\ga\Documents\dev\QuantLib\ObjectHandler\gensrc\ohgensrc_vc10.vcxproj"
(rebuild target(s)) -- FAILED.

Build FAILED.


Any ideas?

Regards,
Grzegorz

Re: [Quantlib-dev] 64 bit QuantLib

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

Hi Johannes,
    yes, please contribute your vcproj files and I'll commit them.

Are the warnings still there in the trunk? I thought we removed some
of them, but I might be mistaken.  How many warnings are we talking
about?

Later,
    Luigi


On Tue, Apr 30, 2013 at 5:22 PM, Johannes Göttker-Schnetmann
<jsc...@gm...> wrote:
> Hi,
>
> since I am using QuantLib in a 64 bit environment (Visual Studio C++ 2010) I
> have to add the x64 configuration with each release/update. I have read
> Luigi's suggestion  to add such a configuration on the quantlib-users
> mailing list last december.
>
> The trunk still contains only 32 bit compilation for Windows - is someone
> working on a x64 configuration at the moment? Otherwise I could submit my
> *.vcproj- and *.sln-files (just straight-forward addition of the x64 build
> configuration in addition to the existing Win32 configuration).
>
> Related to that: The 64 bit compilation throws a lot of warnings. The bulk
> of those are caused by assigning QuantLib::Size to QuantLib::Integer. The
> first ends up as a __int64 on a 64 bit Windows systems, the latter as an
> int, which is 32 bit. This is a known issue when porting to 64 bit, at least
> on Windows
> (http://msdn.microsoft.com/en-us/library/3b2e7499(v=vs.100).aspx). All tests
> are passed nevertheless.
>
> Changing QL_INTEGER and QL_BIG_INTEGER to 64 bit cures most of the warnings,
> but causes some new ones when assigning integer types to QuantLib::Real.
> Changing QuantLib::Size to a 32 bit type is not a viable alternative because
> it causes loads of warnings again, mostly from using standard library
> methods which return std:size_t, not QuantLib::Size.
> The third possibility to get rid of the warnings is to use static_casts or
> dynamic_casts where appropriate.
>
> What do you think?
>
> Kind regards,
> Johannes
>
> ------------------------------------------------------------------------------
> Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET
> Get 100% visibility into your production application - at no cost.
> Code-level diagnostics for performance bottlenecks with <2% overhead
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap1
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>