quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Installation of Quantlib 0.9.9 fails under cygwin (gcc 4.3.4)

[Jose Aparicio-N. <ja...@fr...>]

Quoting Luigi Ballabio <lui...@gm...>:

> On Sat, 2010-01-09 at 08:04 -0800, Richard Stanton wrote:
> > I just downloaded Quantlib 0.9.9 and am trying to install it using the
> > latest version of cygwin/gcc under Windows Vista (cygwin 1.7.1, gcc
> > version 4.3.4). I have boost 1.41.0 installed, and ./configure finds
> > this OK and runs to completion.
>
> > Unfortunately, when I then run “make”, the compilation seems to run
> > fine for quite some while, but dies at the following point: [...]
>
> Richard,
> 	do you have the same problem with the 1.0 beta I've just released?
>

Hi all
Funny, looks like I have an orthogonal set of problems.

My kit:
QuantLib-1.0b1
CYGWIN_NT-5.0 1.5.18(0.132/4/2)

gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
/gcc/i686-pc-cygwin/3.4.4

boost_1_41_0

doxygen 1.6.2

----
./configure  --with-boost-include=/cygdrive/c/Boost/boost_1_41_0/

--with-boost-lib=/cygdrive/c/Boost/boost_1_41_0/stage/lib/
make

gcc took ages, but life as usual.
The QL lib and the examples build ok (no errs no warns). All the examples run
fine. Linking the test-suite reports missing refs though:
======================================================
[...]
libtool: link: g++ -g -O2 -o .libs/quantlib-test-suite.exe quantlibtestsuite.o a
mericanoption.o array.o
[...objects test suite blah blah...]
transformedgrid.o tqre
igendecomposition.o tracing.o utilities.o varianceoption.o varianceswaps.o volat
ilitymodels.o  -L/cygdrive/c/Boost/boost_1_41_0/stage/lib -lboost_unit_test_fram
ework ./.libs/libUnitMain.a ../ql/.libs/libQuantLib.a
./.libs/libUnitMain.a(libUnitMain_la-main.o): In function `_Z13init_functionv':
/cygdrive/c/QuantLib-1.0b1/test-suite/main.cpp:7: undefined reference to `boost:
:unit_test::framework::master_test_suite()'
./.libs/libUnitMain.a(libUnitMain_la-main.o): In function `main':
/cygdrive/c/QuantLib-1.0b1/test-suite/main.cpp:11: undefined reference to `boost
::unit_test::unit_test_main(bool (*)(), int, char**)'
Info: resolving vtable for boost::unit_test::unit_test_log_tby linking to __imp_
__ZTVN5boost9unit_test15unit_test_log_tE (auto-import)
collect2: ld returned 1 exit status
make[1]: *** [quantlib-test-suite.exe] Error 1
make[1]: Leaving directory `/cygdrive/c/QuantLib-1.0b1/test-suite'
make: *** [all-recursive] Error 1

======================================================

I always had problems with the test-suite (and other boost libs that require
compilation). This time I managed to get the unit test framework built with a
dirty hack of
'boost/test/execution_monitor.ipp'
nm of the boost test libs looks fine but I will blame the missing ref to the
change I made.

I still have to try harder but how do you build boost under cygwin? Or someone
else, Nando? I have seen in the archives some of you managed to built on cygwin
without problems.

I have also generated the docs ok. Some classes (e.g. see
SpreadedSwaptionVolatility and
SwaptionVolatilityDiscrete but not ConstantSwaptionVolatility) are not shown
in the class hierarchy. Is it possible to add just one quick line or change
the doxy settings so it generates docs? For instance, in that same example
looks like SwaptionVolatilityStructure only had one derived class.

Ill try to continue playing with it over the weekend and possibly upgrade gcc

Best regards
Pepe

Re: [Quantlib-dev] QuantLib 1.0 beta 1 available

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

On Wed, 2010-01-13 at 08:55 -0600, Dirk Eddelbuettel wrote:
> My $0.02:  'triplets' give us more rope for intermediary releases like
> 1.0.1, 1.0.2, etc.  If you as release manager don't plan to do those
> but rather want to jump to 1.1, 1.2, 1.3 -- fine. 

Dirk,
	I'd do both.  I'm not discarding triplets; I'm just writing 1.0 instead
of 1.0.0 for brevity.  From there, new work would lead to 1.1 (short for
1.1.0); but if there were bug fixes, I'd make a 1.0.1 release to address
them.

Luigi


-- 

Do the right thing. It will gratify some people and astonish the rest. 
-- Mark Twain 

Re: [Quantlib-dev] QuantLib 1.0 beta 1 available

[Dirk E. <ed...@de...>]

My $0.02:  'triplets' give us more rope for intermediary releases like 1.0.1,
1.0.2, etc.  If you as release manager don't plan to do those but rather want
to jump to 1.1, 1.2, 1.3 -- fine.   I'd say that the empirical evidence
across open source projects is in favour of 'triplets', but hey, beauty is in
the eye of the beholder.  Your call.  We all will just whine.

On 13 January 2010 at 14:52, Luigi Ballabio wrote:
| On Wed, 2010-01-13 at 06:30 -0600, Dirk Eddelbuettel wrote:
| >  ii)  the dynamic library major is still '0' as in /usr/lib/libQuantLib.so.0
| >       -- but the long anticipated API freeze should probably make that 1, no?
| 
| I thought we could go for a fresh start---previous versions had names
| such as libQuantLib-0.9.9.so, so they counted as different, right? Or
| was there a libQuantLib.so.0 symbolic link as well?

Here is what my Debian box has:

edd@ron:~> ls -ltr /usr/lib/libQuantLib*
-rw-r--r-- 1 root root 12042164 2009-10-11 07:02 /usr/lib/libQuantLib-0.9.7.so
-rw-r--r-- 1 root root 13386964 2009-12-11 20:19 /usr/lib/libQuantLib-0.9.9.so
-rw-r--r-- 1 root root 13636428 2010-01-13 00:41 /usr/lib/libQuantLib.so.0.0.0
-rw-r--r-- 1 root root 50923590 2010-01-13 00:41 /usr/lib/libQuantLib.a
lrwxrwxrwx 1 root root       20 2010-01-13 06:21 /usr/lib/libQuantLib.so.0 -> libQuantLib.so.0.0.0
lrwxrwxrwx 1 root root       20 2010-01-13 06:21 /usr/lib/libQuantLib.so -> libQuantLib.so.0.0.0
edd@ron:~> 

We keep just the .so of older release; code built against those stills
runs. Libtool (which I still know too little about) in its magic uses three
values anyway so we have the 'active' version libQuantlib.so.0.0.0 with two
softlinks use while building code.  I think that major number ought to be '1'
as in 

   /usr/lib/libQuantLib.so.1 -> libQuantLib.so.1.0.0

to signal the long-awaited API freeze for 1.0.  No?

With that I'd also make the Debian package name 'libquantlib1-dev' rather the
current 'libquantlib0-dev'.  But that is all cosmetic at then end of the
day.  What mattered is that we have distinct packages allowing distinct
versions to co-exist:

edd@ron:~> dpkg -l | grep libquantlib-
ii  libquantlib-0.9.7       0.9.7-1+b2              Quantitative Finance Library -- development package
ii  libquantlib-0.9.9       0.9.9-3                 Quantitative Finance Library -- development package
ii  libquantlib-1.0.0       1.0.0~20100112-1        Quantitative Finance Library -- development package
edd@ron:~> 

And whether that is libquantlib-1.0.0 or libquantlib-1.0 doesn't really
matter.  Apart from the fact that I created precedent (:-/) but I can always
fall back in line for libquantlib-1.1 if you really really howl.

| >  iii) MarketModels needs a man pages, I will cook something up and commit it
| >       (with integration to the examples Makefile etc) unless someone beats
| >       me to it.
| 
| Right. Please go ahead.

Will do if I get a few moments.

Dirk

-- 
Three out of two people have difficulties with fractions.

Re: [Quantlib-dev] QuantLib 1.0 beta 1 available

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

On Wed, Jan 13, 2010 at 2:49 PM, Luigi Ballabio
<lui...@gm...> wrote:
>    1.0.0 is ugly.

I agree and I would write about "releasing 1.0" keeping 1.0.0 in the code

code is ugly anyway... isn't it?

ciao -- Nando

Re: [Quantlib-dev] QuantLib 1.0 beta 1 available

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

On Wed, 2010-01-13 at 06:30 -0600, Dirk Eddelbuettel wrote:
>  ii)  the dynamic library major is still '0' as in /usr/lib/libQuantLib.so.0
>       -- but the long anticipated API freeze should probably make that 1, no?

I thought we could go for a fresh start---previous versions had names
such as libQuantLib-0.9.9.so, so they counted as different, right? Or
was there a libQuantLib.so.0 symbolic link as well?

>  iii) MarketModels needs a man pages, I will cook something up and commit it
>       (with integration to the examples Makefile etc) unless someone beats
>       me to it.

Right. Please go ahead.

Luigi



-- 

Newton's Law of Gravitation: 
What goes up must come down. But don't expect it to come down 
where you can find it. Murphy's Law applies to Newton's. 

Re: [Quantlib-dev] QuantLib 1.0 beta 1 available

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

On Wed, 2010-01-13 at 13:53 +0100, Ferdinando Ametrano wrote:
> On Wed, Jan 13, 2010 at 1:30 PM, Dirk Eddelbuettel <ed...@de...> wrote:
> >  i)   the version number propagated from configure.ac is not of the a.b.c
> >      form, maybe we should stick with that (eg. 1.0.0 ?)
> 
> I would prefer to stick with 1.0.0 too, but I look forward to Luigi's
> 1.0 arguments

Looking forward to it? You won't be disappointed. I have a rational,
well-thought and cogent argument for the 1.0 form. It goes like this:

    1.0.0 is ugly.

But maybe I'm missing something. What would the explicit second 0 give
us that an implied one doesn't?

Later,
	Luigi


-- 

There is no such thing as public opinion. There is only published
opinion. 
-- Winston Churchill 

Re: [Quantlib-dev] QuantLib 1.0 beta 1 available

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

On Wed, Jan 13, 2010 at 1:30 PM, Dirk Eddelbuettel <ed...@de...> wrote:
>  i)   the version number propagated from configure.ac is not of the a.b.c
>      form, maybe we should stick with that (eg. 1.0.0 ?)

I would prefer to stick with 1.0.0 too, but I look forward to Luigi's
1.0 arguments

ciao -- Nando

Re: [Quantlib-dev] QuantLib 1.0 beta 1 available

[Dirk E. <ed...@de...>]

On 12 January 2010 at 17:25, Luigi Ballabio wrote:
| Hi all,
| 	we're almost there.  A beta for version 1.0 is available at
| <https://sourceforge.net/projects/quantlib/files/prerelease/>.
| 
| In everybody's interest, please give this version a try and report any
| problems you might have. Reports can be either sent here on the list or
| filed on the Sourceforge bug tracker.

Debian builds also passed with flying colours.  A few quick remarks though

 i)   the version number propagated from configure.ac is not of the a.b.c
      form, maybe we should stick with that (eg. 1.0.0 ?)

 ii)  the dynamic library major is still '0' as in /usr/lib/libQuantLib.so.0
      -- but the long anticipated API freeze should probably make that 1, no?

 iii) MarketModels needs a man pages, I will cook something up and commit it
      (with integration to the examples Makefile etc) unless someone beats
      me to it.

Dirk

-- 
Three out of two people have difficulties with fractions.

Re: [Quantlib-dev] Serialisation change

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

Hi Plamen

> I'd like to commit a small change to the serialisation code in
> QuantLibAddin.

glad to see you back in action !

> It will remove the dependency of the serialised objects
> to the order in which the ValueObjects are registered in the code so
> that additions of new classes or removal of old ones will not break
> the compatibility of existing xml archives.

this would be a GREAT improvement.

> The down side is that this will break all existing exports - however
> those exports are anyway not very stable because chances are that they
> get broken with any new class being added in QLA.

this is not an issue in my book, since as you said existing archives
are not stable anyway

> How this works is very
> simple - a class id gets generated only when this class appears in the
> archive for the very first time. This ensures that id's are local to
> the archive and are only dependant on the classes serialised in this
> archive.

please help me to better understand what kind of compatibility we
would achieve, and what remaining dependencies we would have to deal
with.
I do understand that as active developer I would gain archive
compatibility between different build of the QLXL addin when exporting
/removing classes, at least when using the same compiler and Boost
Serialization library
Would archives be also compatible across different compilers using the
same Boost? (this might be already true)
Across different Boost libs? (this is probably not true)
Across different QLXL releases? (I'm not sure if other exogenous
elements might compromise compatibility)

Depending on your answer I'm willing to consider this as relevant (or
even mandatory :-) for the QLXL 1.0 release

ciao -- Nando

PS any chance you might also add support these 2 relevant features:
1) coercion from string of comma separated numbers to vector<Quote>,
equivalent to the one available for vector<Real>
2) returning valarray<type> as alternative to vector<type>

Re: [Quantlib-dev] QuantLib 1.0 beta 1 available

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

On Tue, 2010-01-12 at 21:18 -0200, Piter Dias wrote:
> > In everybody's interest, please give this version a try and report any
> > problems you might have. Reports can be either sent here on the list or
> > filed on the Sourceforge bug tracker.
> 
> Is there a problem if we report good news too?

No problem. Just don't file them on the tracker :)

> Test suite run successfully for Windows 7, Boost 1.41 and Visual C+ 2008
> Express Edition.

Ok, thanks.

Luigi


-- 

Father's got the sack from the water-works 
For smoking of his old cherry-briar; 
Father's got the sack from the water-works 
'Cos he might set the water-works on fire. 

[Quantlib-dev] F# version of QuantLib

[N.Cao <ca...@fi...>]

Hi all,

I am currently developing the F# version of QuantLib on SourgeForge and it
is ranked no.1 among F# free/open-source softwares.

I am here looking for more developers to join this project. If you are
interested, please send an email to me. For more information, please visit
www.quantifa.org.

Cheers,
Ning Cao

[Quantlib-dev] QuantLib 1.0 beta 1 available

[Piter D. <pit...@pi...>]

> In everybody's interest, please give this version a try and report any
> problems you might have. Reports can be either sent here on the list or
> filed on the Sourceforge bug tracker.

Is there a problem if we report good news too?

Test suite run successfully for Windows 7, Boost 1.41 and Visual C+ 2008
Express Edition.

14>Tests completed in 28 m 58 s
14>Test suite "Master Test Suite" passed with:
14>  1689 assertions out of 1689 passed
14>  446 test cases out of 446 passed
14>Build log was saved at
"file://c:\Users\piterdias\develop\src\QuantLib-1.0b1\test-suite\build\vc90\Win32\Release
(static runtime)\BuildLog.htm"
14>testsuite - 0 error(s), 0 warning(s)
========== Build: 15 succeeded, 0 failed, 0 up-to-date, 0 skipped
==========


-------------------------

Piter Dias
pit...@pi...

[Quantlib-dev] Serialisation change

[Plamen N. <pla...@re...>]

Hi all,

I'd like to commit a small change to the serialisation code in  
QuantLibAddin. It will remove the dependency of the serialised objects  
to the order in which the ValueObjects are registered in the code so  
that additions of new classes or removal of old ones will not break  
the compatibility of existing xml archives. How this works is very  
simple - a class id gets generated only when this class appears in the  
archive for the very first time. This ensures that id's are local to  
the archive and are only dependant on the classes serialised in this  
archive.

The down side is that this will break all existing exports - however  
those exports are anyway not very stable because chances are that they  
get broken with any new class being added in QLA.

Please let me know what you guys think...

cheers,
Plamen





----------------------------------------------------------------
This message was sent using IMP, the Internet Messaging Program.

Re: [Quantlib-dev] Installation of Quantlib 0.9.9 fails under cygwin (gcc 4.3.4)

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

On Sat, 2010-01-09 at 08:04 -0800, Richard Stanton wrote:
> I just downloaded Quantlib 0.9.9 and am trying to install it using the
> latest version of cygwin/gcc under Windows Vista (cygwin 1.7.1, gcc
> version 4.3.4). I have boost 1.41.0 installed, and ./configure finds
> this OK and runs to completion. 

> Unfortunately, when I then run “make”, the compilation seems to run
> fine for quite some while, but dies at the following point: [...]

Richard,
	do you have the same problem with the 1.0 beta I've just released?

Thanks,
	Luigi



-- 

Ogden's Law: 
The sooner you fall behind, the more time you have to catch up. 

[Quantlib-dev] QuantLib 1.0 beta 1 available

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

Hi all,
	we're almost there.  A beta for version 1.0 is available at
<https://sourceforge.net/projects/quantlib/files/prerelease/>.

In everybody's interest, please give this version a try and report any
problems you might have. Reports can be either sent here on the list or
filed on the Sourceforge bug tracker.

Thanks,
	Luigi


-- 

Everything that can be invented has been invented. 
-- Charles Duell, Director of U.S. Patent Office, 1899 

Re: [Quantlib-dev] Finite difference implementation of continuously sampled arithmetic Asian option

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

On Sun, 2010-01-10 at 17:17 -0500, Stephen Tse wrote:
>   It's mentioned in the archive(reproduced below) that FD pricing
> engine for continuously sampled arithmetic Asian option has not been
> implemented in QuantLib. [...] I'm
> wondering if the current framework allows its pricing using Jan
> Vecer's PDE which involves only one variable plus time.

I think it does.

>  If the current
> framework allows it, I'd like to give it a try. What do you think?

Sure, please go ahead.

Luigi


-- 

Lubarsky's Law of Cybernetic Entomology: 
There is _always_ one more bug. 

[Quantlib-dev] [ quantlib-Bugs-2930481 ] #define directive in swapforwardbasissystem.hpp

[SourceForge.net <no...@so...>]

Bugs item #2930481, was opened at 2010-01-12 10:05
Message generated for change (Settings changed) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2930481&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: leibniz777 (leibniz777)
>Assigned to: Luigi Ballabio (lballabio)
Summary: #define directive in swapforwardbasissystem.hpp

Initial Comment:
In the file swapforwardbasissystem.hpp in the trunk there are he following directives:
#ifndef quantlib_swap_forward_basis_system_hpp
#define quantlib_swap_basis_system_hpp

This leads to an error C2011 when using the library.

----------------------------------------------------------------------

Comment By: Luigi Ballabio (lballabio)
Date: 2010-01-12 12:40

Message:
The bug is now fixed in the Subversion repository.
Thank you for the report.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2930481&group_id=12740

[Quantlib-dev] [ quantlib-Bugs-2930481 ] #define directive in swapforwardbasissystem.hpp

[SourceForge.net <no...@so...>]

Bugs item #2930481, was opened at 2010-01-12 10:05
Message generated for change (Tracker Item Submitted) made by leibniz777
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2930481&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: leibniz777 (leibniz777)
Assigned to: Nobody/Anonymous (nobody)
Summary: #define directive in swapforwardbasissystem.hpp

Initial Comment:
In the file swapforwardbasissystem.hpp in the trunk there are he following directives:
#ifndef quantlib_swap_forward_basis_system_hpp
#define quantlib_swap_basis_system_hpp

This leads to an error C2011 when using the library.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=2930481&group_id=12740

Re: [Quantlib-dev] QuantLib orphaned on ArchLinux User Repository

[Dirk E. <ed...@de...>]

On 11 January 2010 at 17:08, Ferdinando Ametrano wrote:
| Hi all
| 
| I have no idea how relevant it is, anyway it seems like QuantLib was
| orphaned on ArchLinux User Repository

Interesting.  Do we have a handle on which other linux distros include QL?  

| http://www.linux-archive.org/archlinux-user-repository/64500-orphan-request-4.html
| 
| any *nix guru willing to take a look into it?

Do we have any Arch Linux users here?

Dirk
(Debian QL maintainer since QL version 0.1.9 in 2001 :)

-- 
Three out of two people have difficulties with fractions.

[Quantlib-dev] QuantLib orphaned on ArchLinux User Repository

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

Hi all

I have no idea how relevant it is, anyway it seems like QuantLib was
orphaned on ArchLinux User Repository

http://www.linux-archive.org/archlinux-user-repository/64500-orphan-request-4.html

any *nix guru willing to take a look into it?

ciao -- Nando

[Quantlib-dev] Finite difference implementation of continuously sampled arithmetic Asian option

[Stephen T. <ko...@gm...>]

Hello,

  It's mentioned in the archive(reproduced below) that FD pricing
engine for continuously sampled arithmetic Asian option has not been
implemented in QuantLib. The archive message also mentioned that "one
needs to evolve two variables plus time. We have no support for that
yet (the current framework manages one variable plus the time.)" I'm
wondering if the current framework allows its pricing using Jan
Vecer's PDE which involves only one variable plus time. (Please see
equation (3.9), (3.10) and Table 1 in
http://www.stat.columbia.edu/~vecer/asian.pdf) If the current
framework allows it, I'd like to give it a try. What do you think?

Thanks a lot,
Stephen
http://www.cs.uwaterloo.ca/~sttse/


On Wed, 2008-07-23 at 12:48 -0400, Robert Buchanan wrote:
> I see there are pricing engines for continuously sampled,
> geometrically averaged asian options (an analytic engine), for
> discretely sampled, geometrically averaged asian options (an analytic
> engine), and for discretely sampled, arithmetically averaged asian
> options (a Monte Carlo engine). However, I did not see a pricing
> engine for continuously sampled, arithmetically averaged asian
> options. Why is that?

There is no closed formula for continuously sampled, arithmetically
averaged options. The continuous case can be approximated by increasing
the number of fixing dates in the discrete case.

> Is the developer group waiting for someone to volunteer to implement
> that? Are there any PDE, perhaps finite difference-based pricing
> engines for these types of asian options?

They can be solved with finite-differences, but one needs to evolve two
variables plus time. We have no support for that yet (the current
framework manages one variable plus the time.)

Luigi

[Quantlib-dev] Installation of Quantlib 0.9.9 fails under cygwin (gcc 4.3.4)

[Richard S. <st...@ha...>]

I just downloaded Quantlib 0.9.9 and am trying to install it using the latest version of cygwin/gcc under Windows Vista (cygwin 1.7.1, gcc version 4.3.4). I have boost 1.41.0 installed, and ./configure finds this OK and runs to completion.

Unfortunately, when I then run "make", the compilation seems to run fine for quite some while, but dies at the following point:

/bin/sh ../../libtool --tag=CC --mode=link gcc  -g -O2   -o libExperimental.la
  amortizingbonds/libAmortizingBonds.la barrieroption/libBarrierOption.la callab
lebonds/libCallableBonds.la commodities/libCommodities.la compoundoption/libComp
oundOption.la coupons/libCoupons.la credit/libCredit.la finitedifferences/libMul
tiDimFDM.la inflation/libInflation.la lattices/libLattices.la mcbasket/libMcBask
et.la processes/libProcesses.la risk/libRisk.la varianceoption/libVarianceOption
.la volatility/libVolatility.la
libtool: link: (cd .libs/libExperimental.lax/libAmortizingBonds.a && ar x "/RHS/
QuantLib-0.9.9/ql/experimental/amortizingbonds/.libs/libAmortizingBonds.a")
libtool: link: object name conflicts in archive: .libs/libExperimental.lax/libAm
ortizingBonds.a//RHS/QuantLib-0.9.9/ql/experimental/amortizingbonds/.libs/libAmo
rtizingBonds.a
make[4]: *** [libExperimental.la] Error 1
make[4]: Leaving directory `/RHS/QuantLib-0.9.9/ql/experimental'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/RHS/QuantLib-0.9.9/ql/experimental'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/RHS/QuantLib-0.9.9/ql'
make[1]: *** [all] Error 2
make[1]: Leaving directory `/RHS/QuantLib-0.9.9/ql'
make: *** [all-recursive] Error 1
bash-3.2$

The only slightly odd thing during the configuration phase that might be relevant was the following:

checking command to parse /usr/bin/nm -B output from gcc object... failed

Thanks for checking into this.

[Quantlib-dev] [ quantlib-Patches-2925351 ] CDX

[SourceForge.net <no...@so...>]

Patches item #2925351, was opened at 2010-01-03 21:51
Message generated for change (Comment added) made by japaricio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=2925351&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Aparicio-Navarro Jose (japaricio)
Assigned to: Nobody/Anonymous (nobody)
Summary: CDX

Initial Comment:
Trash for the iTraxx,
I am sending an example in the CDX.cpp file. It covers the flat engine and the options. To test the intrinsic engine, compute basis etc I use a worksheet add-in because the amount of data is quite large; spread curves, default status, settlement data etc...

The option engine now owns the underlying swap. I have done this for two reasons, one is to make sure that the prob curve used to price the swap and the option are the same. Also because an outside swap was forcing me to make copies of the swap in the engines calculate to be exception safe (I could break an outside set up engine). Might be nice to change the CDS option in a similar way (but there for the first reason only).

I went for a very flexible index. For instance; the intrinsic spread can be computed at a forward date. This can be of some use (e.g. options) but keeps the code from using Lazyness to cache the intrinsic and average spreads. The index could have done without owning a schedule if they could only be constructed with the standard conventions and rule. This is comented in the code.

I have not updated the makefiles with the new files.
The code in the issuer and defaultType patches supersedes the fix I sent for Bug 2883169.

Best regards and a very happy 2010 to all of you.
Pepe

----------------------------------------------------------------------

>Comment By: Aparicio-Navarro Jose (japaricio)
Date: 2010-01-07 19:20

Message:
After suggestions from Toyin Akin who took the trouble of analysing the
code I 
have been taken out of my lazyness and code a proper TS bootstrap. The
result 
is now within 14 bp of error from the markit calculator result. 
The initial TS bootstrap was giving 71 bp difference. This code is 44 bp
away. 
You get 14 bp error by using a non flat hazard rate bootstrap (see MarkIt

calculator, I can send you a screenshot) and 0 days delay in the TS
instruments. 
I havent done this because the index quote has to be understood flat to
its tenor, 
the quotes do not represent a term structure, they are a price, not a fair
spread 
you can enter into a contract.

Markit NPV..............30454.88	
previous result.........30239.45.......-0.71%
res new bootstrap.......30587.93........0.44%
non flat and 0 days curve 
instrument settlement...30498.15........0.14%

Toyin also pointed me out about an unused local in the intrinsic index
engine 
'calculate' which I am removing now.

If you want to quickly try the non flat HR this is the curve (got it using
the 
CDS bootstrap):

vector<Natural> datesSN ;
datesSN += 
40074, 40257, 40349, 40441, 40532, 40897, 41263, 41628, 41993, 42724,
43819;

vector<Date> datesHRs;

for(Size i=0; i<datesSN.size(); i++) 
    datesHRs.push_back(Date(datesSN[i]));

vector<Real> hRsData;
hRsData += 
0.033278662, 0.033278662, 0.033278662, 0.033272456, 0.033252841,
0.033224688,
0.033194453, 0.033182468, 0.033160034, 0.033156331, 0.033147345;

const Handle<DefaultProbabilityTermStructure> flatHRdefaultProb(
    boost::shared_ptr<InterpolatedHazardRateCurve<BackwardFlat> >(new 
    InterpolatedHazardRateCurve<BackwardFlat>(datesHRs, hRsData, dayCtr,
calendar)
                ));

ok, the HR TS variable name is not adequate now....

Also, if anyone wants to test the probability curve shown in the Markit 
calculator use:

flatHRdefaultProb->enableExtrapolation();
for(Size i=0; i<datesSN.size(); i++) 
    cout<< datesHRs[i].serialNumber() << " , " << 
       flatHRdefaultProb->defaultProbability(datesHRs[i]) << endl;
cout<< Date(today + Period(15, Years)).serialNumber() << " , " << 
        flatHRdefaultProb->defaultProbability(Date(today + 
        Period(15, Years))) << endl;
cout<< Date(today + Period(20, Years)).serialNumber() << " , " << 
        flatHRdefaultProb->defaultProbability(Date(today + 
        Period(20, Years))) << endl;
cout<< Date(today + Period(30, Years)).serialNumber() << " , " << 
        flatHRdefaultProb->defaultProbability(Date(today + 
        Period(30, Years))) << endl;



I havent played the reverse engineering game to the full; interpolators,
CDS 
bootstrap parameters, schedules, index inception date (its a Saturday),
etc..

Also I am updating the basket patch file, I missed a disposability
opportunity.

Best regards
Pepe

----------------------------------------------------------------------

Comment By: Aparicio-Navarro Jose (japaricio)
Date: 2010-01-04 12:27

Message:
Hi again, 
I have been moving to a newer branch of the lib to find out the
FixedRateLeg helper I was using in the index swap was obsolete and the
files I sent were missing a patch for an extra function in imm.xpp 

Best regards
Pepe

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=2925351&group_id=12740

[Quantlib-dev] [ quantlib-Patches-2925351 ] CDX

[SourceForge.net <no...@so...>]

Patches item #2925351, was opened at 2010-01-03 21:51
Message generated for change (Comment added) made by japaricio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=2925351&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Aparicio-Navarro Jose (japaricio)
Assigned to: Nobody/Anonymous (nobody)
Summary: CDX

Initial Comment:
Trash for the iTraxx,
I am sending an example in the CDX.cpp file. It covers the flat engine and the options. To test the intrinsic engine, compute basis etc I use a worksheet add-in because the amount of data is quite large; spread curves, default status, settlement data etc...

The option engine now owns the underlying swap. I have done this for two reasons, one is to make sure that the prob curve used to price the swap and the option are the same. Also because an outside swap was forcing me to make copies of the swap in the engines calculate to be exception safe (I could break an outside set up engine). Might be nice to change the CDS option in a similar way (but there for the first reason only).

I went for a very flexible index. For instance; the intrinsic spread can be computed at a forward date. This can be of some use (e.g. options) but keeps the code from using Lazyness to cache the intrinsic and average spreads. The index could have done without owning a schedule if they could only be constructed with the standard conventions and rule. This is comented in the code.

I have not updated the makefiles with the new files.
The code in the issuer and defaultType patches supersedes the fix I sent for Bug 2883169.

Best regards and a very happy 2010 to all of you.
Pepe

----------------------------------------------------------------------

>Comment By: Aparicio-Navarro Jose (japaricio)
Date: 2010-01-04 12:27

Message:
Hi again, 
I have been moving to a newer branch of the lib to find out the
FixedRateLeg helper I was using in the index swap was obsolete and the
files I sent were missing a patch for an extra function in imm.xpp 

Best regards
Pepe

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=2925351&group_id=12740

[Quantlib-dev] [ quantlib-Patches-2925351 ] CDX

[SourceForge.net <no...@so...>]

Patches item #2925351, was opened at 2010-01-03 21:51
Message generated for change (Tracker Item Submitted) made by japaricio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=2925351&group_id=12740

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Aparicio-Navarro Jose (japaricio)
Assigned to: Nobody/Anonymous (nobody)
Summary: CDX

Initial Comment:
Trash for the iTraxx,
I am sending an example in the CDX.cpp file. It covers the flat engine and the options. To test the intrinsic engine, compute basis etc I use a worksheet add-in because the amount of data is quite large; spread curves, default status, settlement data etc...

The option engine now owns the underlying swap. I have done this for two reasons, one is to make sure that the prob curve used to price the swap and the option are the same. Also because an outside swap was forcing me to make copies of the swap in the engines calculate to be exception safe (I could break an outside set up engine). Might be nice to change the CDS option in a similar way (but there for the first reason only).

I went for a very flexible index. For instance; the intrinsic spread can be computed at a forward date. This can be of some use (e.g. options) but keeps the code from using Lazyness to cache the intrinsic and average spreads. The index could have done without owning a schedule if they could only be constructed with the standard conventions and rule. This is comented in the code.

I have not updated the makefiles with the new files.
The code in the issuer and defaultType patches supersedes the fix I sent for Bug 2883169.

Best regards and a very happy 2010 to all of you.
Pepe

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=312740&aid=2925351&group_id=12740