quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] Re: RPM spec file for QuantLib-0.3.3

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

At 07:09 AM 8/26/03 -0500, Dirk Eddelbuettel wrote:
>Actually, it already does:
>
>test:     test-stamp build
>test-stamp: build-stamp
>         -$(MAKE) check
>         touch test-stamp
>[...]
>binary-common: build test install
>[...]
>
>so test should be visited when a binary is built.  Not sure why it doesn't /
>didn't. Will need to check.

Dirk,
         from the logs, it looks as though the library is build, installed, 
removed, and finally tested---so that the test suite doesn't find the 
shared library to load. Maybe it should be build, test, install, remove?

Later,
         Luigi

[Quantlib-dev] Re: debian platform

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

On Tue, Aug 26, 2003 at 01:16:27PM +0200, Ferdinando Ametrano wrote:
> Hi Dirk
> 
> glad to know that our release candidate compiled on all Debian platforms: 
> even if Luigi made few more commits lately I don't expect them to make the 
> compilation fail... at least I hope so :)
> 
> I wonder if the test-suite was also compiled and run. If I'm not wrong the 
> configure stage should detect if CPP_UNIT is installed and compile the 
> suite. It would be a great point to be sure that the suite run 
> successfully. Any chance?

I added cppunit as Depends during the last iteration:

quantlib (0.3.2.20030727-1) unstable; urgency=low

  * Upgraded to 'golden master' pre-release of 0.3.3 dated 2003-07-27
    [ N.B.: there was no 0.3.2 release ]
  * debian/control: Section changed to libdevel for libquantlib0-dev
  * debian/control: Added cppunit to Build-Depends to obtain unit testing
  * debian/quantlib-examples.files: Added AmericanOption binary and man page
  * debian/libquantlib0-dev.files: Added quantlib-test-suite binary and man page
  * debian/quantlib-test-suite.1: Added new manual page
  * debian/AmericanOption.1: Added new manual page
  * debian/control: Standards-Version upgraded to 3.6.0
  * debian/rules: Install quantlib.el in -dev package examples/ directory
  * debian/rules: Install test-suite/ in -dev package examples/ directory
  
 -- Dirk Eddelbuettel <ed...@de...>  Sun, 27 Jul 2003 09:24:09 -0500
   
I lost the build log from that upload from my own machine, no I can't check
that they run.

But looking at the build daemon site
    http://buildd.debian.org/build.php?pkg=quantlib
and randomly picking the alpha arch, I see fairly far down the file
    http://buildd.debian.org/fetch.php?&pkg=quantlib&ver=0.3.2.20030727-1&arch=alpha&stamp=1059399648&file=log&as=raw

Making check in test-suite
make[3]: Entering directory /build/buildd/quantlib-0.3.2.20030727/test-suite'
/usr/bin/make  check-TESTS
make[4]: Entering directory /build/buildd/quantlib-0.3.2.20030727/test-suite'
lt-quantlib-test-suite: error while loading shared libraries:
libQuantLib.so.0: cannot open shared object file: No such file or directory
FAIL: quantlib-test-suite
===================================================
1 of 1 tests failed
Please report to qua...@li...
===================================================

so it looks like we're having a logic error. The dyn. libs are being built,
installed into tmp directory from the deb is built ... but not found by the
dyn. loader.

Do cppunit / libtool have a way around that?

Dirk

-- 
Those are my principles, and if you don't like them... well, I have others.
                                                -- Groucho Marx

[Quantlib-dev] Re: RPM spec file for QuantLib-0.3.3

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

On Tue, Aug 26, 2003 at 12:38:53PM +0200, Luigi Ballabio wrote:
> At 09:39 AM 8/23/03 -0500, Dirk Eddelbuettel wrote:
> >This will be a mighty fine release.  BTW, all the Debian packages on all 
> >the
> >architectures built fine for the golden master from last month:
> >
> >-- QuantLib itself was built on ten additional architectures by July 29
> >   http://buildd.debian.org/build.php?pkg=quantlib
> 
> Dirk,
>         I guess the test-suite wasn't included in the workflow. When the 
> final tarballs are ready (any day now) could you add a "make check" to the 
> thing?

Actually, it already does:

test:	  test-stamp build
test-stamp: build-stamp
	-$(MAKE) check
	touch test-stamp
[...]
binary-common: build test install 
[...]

so test should be visited when a binary is built.  Not sure why it doesn't /
didn't. Will need to check.

Dirk


-- 
Those are my principles, and if you don't like them... well, I have others.
                                                -- Groucho Marx

Re: [Quantlib-dev] Re: RPM spec file for QuantLib-0.3.3

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

>         I guess the test-suite wasn't included in the workflow. When the 
> final tarballs are ready (any day now) could you add a "make check" to 
> the thing?

Luigi: we're in synch! Incredible, isn't it?

[I wouldn't even dare to cite "great minds think alike" since it's clear 
one of us isn't a great mind :) ]


------------
ciao -- Nando 

Re: [Quantlib-dev] Re: RPM spec file for QuantLib-0.3.3

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

>>     4. A relative minor point about the name, is quantlib better than
>>QuantLib? As the Unix name of the project is quantlib.
>
>As you like it.

SourceForge project Unix name had to be lowercase, at least at the time 
when the QuantLib project was created


------------
ciao -- Nando 

[Quantlib-dev] debian platform

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

Hi Dirk

glad to know that our release candidate compiled on all Debian platforms: 
even if Luigi made few more commits lately I don't expect them to make the 
compilation fail... at least I hope so :)

I wonder if the test-suite was also compiled and run. If I'm not wrong the 
configure stage should detect if CPP_UNIT is installed and compile the 
suite. It would be a great point to be sure that the suite run 
successfully. Any chance?

thank you in advance


------------
ciao -- Nando 

[Quantlib-dev] Re: RPM spec file for QuantLib-0.3.3

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

At 09:39 AM 8/23/03 -0500, Dirk Eddelbuettel wrote:
>This will be a mighty fine release.  BTW, all the Debian packages on all the
>architectures built fine for the golden master from last month:
>
>-- QuantLib itself was built on ten additional architectures by July 29
>    http://buildd.debian.org/build.php?pkg=quantlib

Dirk,
         I guess the test-suite wasn't included in the workflow. When the 
final tarballs are ready (any day now) could you add a "make check" to the 
thing?

Just curious,
                 Luigi

[Quantlib-dev] Re: RPM spec file for QuantLib-0.3.3

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

At 09:22 PM 8/22/03 -0500, Liguo Song wrote:
>The first working RPM spec file for QuantLib-0.3.3 is attached.

Hi Liguo,
         I've been trying to add the spec to the cvs tree. My question is, 
does it need to include the version number in its name? I wouldn't want to 
remove it from cvs and add it again each time we release...


>There are still a lot to improve with this spec file, and I'd like to hear
>some opinions about the following issues:
>     1. It is conventional to separate the dynamic libs, static libs, and
>header files into separate packages. Should we do the same thing here?

As you like it.

>     2. Cppunit is only needed for the test-suite, so should we still make it
>required? Or just drop the test-suite if no cppunit is available?

I would just drop the test-suite.

>     3. The documents for QuantLib is not included in the tar ball right now,
>should I put the docs into the RPM package?

Maybe it might be another package? (or packages?)

>     4. A relative minor point about the name, is quantlib better than
>QuantLib? As the Unix name of the project is quantlib.

As you like it.

Later,
         Luigi

[Quantlib-dev] [ quantlib-Feature Requests-528758 ] QuantLib.py OptionEngine-s

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

Feature Requests item #528758, was opened at 2002-03-12 02:23
Message generated for change (Settings changed) made by lballabio
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=528758&group_id=12740

Category: None
Group: None
>Status: Closed
Priority: 5
Submitted By: Gábor Lipták (gliptak)
Assigned to: Nobody/Anonymous (nobody)
Summary: QuantLib.py  OptionEngine-s

Initial Comment:
In QuantLib.py there is a EuropeanEngine defined, but
not an AmericanEngine. Is this by design?

Thanks

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

Comment By: Luigi Ballabio (lballabio)
Date: 2002-03-12 09:19

Message:
Logged In: YES 
user_id=75450

AmericanEngine is not yet implemented in the C++ library. Engines are 
planned for American, Asians, and all other options since the new Option 
framework will eventually supersede the current pricers. However, this 
will take a bit of time.


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

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

[Quantlib-dev] [ quantlib-Bugs-528757 ] 'QuantLib.QuantLib' module has no attrib

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Out of Date
Priority: 5
Submitted By: Gábor Lipták (gliptak)
Assigned to: Nobody/Anonymous (nobody)
Summary: 'QuantLib.QuantLib' module has no attrib

Initial Comment:
running:



http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/quantlib/QuantLib-Python/QuantLib/test/implied_volatility.py



gets:



Traceback (most recent call last):

  File

"C:\Python21\Pythonwin\pywin\framework\scriptutils.py",

line 301, in RunScript

    exec codeObject in __main__.__dict__

  File

"C:\Python21\QuantLib\doc\tests\implied_volatility.py",

line 112, in ?

    print 'testing QuantLib', QuantLib.__version__

AttributeError: 'QuantLib.QuantLib' module has no

attribute '__version__'



It seems this have been fixed in CVS.

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

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

[Quantlib-dev] [ quantlib-Bugs-528736 ] building QuantLib CVS under Cygwin

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

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

Category: None
Group: None
>Status: Closed
>Resolution: Invalid
Priority: 5
Submitted By: Gábor Lipták (gliptak)
Assigned to: Nobody/Anonymous (nobody)
Summary: building QuantLib CVS under Cygwin

Initial Comment:
As per the INSTALL.txt one should run configure in the

directory.



But there does not seem to be a configure in the directory:



http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/quantlib/QuantLib/



When I run autoconf, I get these errors:



$ autoconf --version

autoconf (GNU Autoconf) 2.52

Written by David J. MacKenzie.

~/QuantLib

$ autoconf

configure.in:12: error: possibly undefined macro:

AM_CONFIG_HEADER

configure.in:13: error: possibly undefined macro:

AM_INIT_AUTOMAKE

configure.in:22: error: possibly undefined macro:

AM_PROG_LIBTOOL

configure.in:31: error: possibly undefined macro:

AM_CONDITIONAL



Do I need to have some more cygwin packages installed?



Thanks

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

Comment By: Nobody/Anonymous (nobody)
Date: 2003-02-19 17:50

Message:
Logged In: NO 

In my case on cygwin, all has been ok.

Did you install dev utils provided in cygwin ?

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

Comment By: Ferdinando Ametrano (nando)
Date: 2002-03-13 10:03

Message:
Logged In: YES 
user_id=34616

The INSTALL.TXT is there to be distributed with the official

source tarball distribution. In the official source

distribution configure is available.



If you check out the source code from the CVS then you need

the GNU tools that developers use, and which are not

required to build QuantLib from tarballs. These are

automake, autoconf, libtool, GNU m4, GNU make, and others

which might escape me now. They all come with recent

GNU/Linux distributions, cygwin included.

To begin the build process from a CVS checkout, start with:



sh ./bootstrap



which will prepare the package for compilation. You can then

use ./configure and make in the usual way.



these info are available at http://quantlib.org/cvs.html



I currently compile QuantLib under cygwin, both tarball and CVS



Please let me know if this solves your problem



thank you for your feedback



ciao -- Nando

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

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

Re: [Quantlib-dev] bug showed up in AmericanOption example

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

At 02:14 PM 7/29/2003 +0200, Luigi Ballabio wrote:
>At 01:48 PM 7/29/03 +0200, Ferdinando Ametrano wrote:
>>the AmericanOption example shows a bug related to matrix/vector product, 
>>originating from a bad SVD decomposition triggered by the valuation of an 
>>OTM option with very few ITM paths.
>
>Can you elaborate on this?

I'm toying with the next release in my ten minutes spare time at work ;-)

The AmericanOption example as it is available now in the CVS branch fails. 
It is the valuation of out-of-the-money option, where only 1 path finishes 
in the money. The SingularValueDecomposition applies to a 1x3 matrix (first 
question: isn't standard to implement SVD for MxN matrix with M>=N? Ok it's 
just matter of transposing...). Whatever it does, it returns 
matrices/vectors that cannot be multiplied in the MC American engines. This 
failed multiplication raise the exception.

hope it helps.
it's short, sorry but I'm leaving...


------------
ciao -- Nando 

Re: [Quantlib-dev] bug showed up in AmericanOption example

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

At 01:48 PM 7/29/03 +0200, Ferdinando Ametrano wrote:
>the AmericanOption example shows a bug related to matrix/vector product, 
>originating from a bad SVD decomposition triggered by the valuation of an 
>OTM option with very few ITM paths.

Can you elaborate on this?

Later,
         Luigi

[Quantlib-dev] bug showed up in AmericanOption example

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

Hi all

the AmericanOption example shows a bug related to matrix/vector product, 
originating from a bad SVD decomposition triggered by the valuation of an 
OTM option with very few ITM paths.

Any idea Neil?

BTW We badly need test case for SVD...


------------
ciao -- Nando 

Re: Examples ? (Was: [Quantlib-dev] tarballs)

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

On 2003.07.26 17:31, Dirk Eddelbuettel wrote:
> Err, earth to quantlib, earth to quantlib, ...

Roger, earth.

> The examples have been available (as binaries) in a separate package 
> quantlib-examples for as long as there have been Debian packages.

Oh, I see. You're a traditionalist :)

> As 'make examples' builds them, could we settle on 'make install-
> examples' to install them?

Ok, I'll do it. Or, I could add an option to configure to have them 
built and installed by default. I'll see what I can do.


> Well, so do I understand this as emacs now beeing a build requirement?

No, I don't think that would be nice. I'll try and figure out how to 
inhibit that part of the installation when emacs is missing. 
Later,
	Luigi

Re: Examples ? (Was: [Quantlib-dev] tarballs)

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

On Sat, Jul 26, 2003 at 05:03:30PM +0200, Luigi Ballabio wrote:
> On 2003.07.26 15:15, Dirk Eddelbuettel wrote:
> >
> >Another point:  the examples no longer build as part of 'make', and
> >they don't seem to respont, once built, to 'make install'.
> >
> >Is that intentional?
> 
> It is. They build only if you say "make examples", and don't get 
> installed---there's no much use for them as installed binaries, as
> you can't even pass them any parameters. The sources are
> the really useful part. Maybe you can add them to the docs package?

Err, earth to quantlib, earth to quantlib, ...  The examples have been
available (as binaries) in a separate package quantlib-examples for as long
as there have been Debian packages. [1]  They are useful, see e.g. the
screenshot of my Quantian 'open mosix and apps on a bootable cd' project
where the BermudanSwaption is used to test openMosix :) So that said, I
would like to see 'make' build them and 'make install' install them. As
'make examples' builds them, could we settle on 'make install-examples' to
install them?

And yes, the example sources have always been installed as examples in the
-dev package.
 
> As for quantlib.el, I uploaded new tarballs. I don't really know what 
> automake will say when it'll see that you don't have emacs. If it 
> complains loudly and stops, I'll have to try and add a conditional in 
> there...

Well, so do I understand this as emacs now beeing a build requirement? No
sweat, I will simply add it. That said, you should still add code to have it
behave gracefully in case a vi addict tries to build QL ....  :)

Ciao, Dirk


[1] 

edd@homebud:~> apt-cache search quantlib
libquantlib0 - Quantitative Finance Library -- development package
libquantlib0-dev - Quantitative Finance Library -- library package
quantlib-examples - Quantitative Finance Library -- example binaries
quantlib-python - Python bindings for the Quantlib Quantitative Finance library
quantlib-refman - Quantitative Finance Library -- reference manual
quantlib-ruby - Ruby bindings for the Quantlib Quantitative Finance library
r-cran-rquantlib - GNU R package interfacing the QuantLib finance library


-- 
Those are my principles, and if you don't like them... well, I have others.
                                                -- Groucho Marx

Re: Examples ? (Was: [Quantlib-dev] tarballs)

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

On 2003.07.26 15:15, Dirk Eddelbuettel wrote:
> 
> Another point:  the examples no longer build as part of 'make', and
> they don't seem to respont, once built, to 'make install'.
> 
> Is that intentional?

It is. They build only if you say "make examples", and don't get 
installed---there's no much use for them as installed binaries, as
you can't even pass them any parameters. The sources are
the really useful part. Maybe you can add them to the docs package?

As for quantlib.el, I uploaded new tarballs. I don't really know what 
automake will say when it'll see that you don't have emacs. If it 
complains loudly and stops, I'll have to try and add a conditional in 
there...

Later,
	Luigi

Examples ? (Was: [Quantlib-dev] tarballs)

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

Another point:  the examples no longer build as part of 'make', and they
don't seem to respont, once built, to 'make install'.

Is that intentional?

Dirk

-- 
Those are my principles, and if you don't like them... well, I have others.
                                                -- Groucho Marx

quantlib.el ? (Was: [Quantlib-dev] tarballs)

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

I get 

make[2]: Entering directory /home/edd/src/debian/QuantLib-0.3.3'
make[2]: *** No rule to make target quantlib.el', needed by all-am'.  Stop.
make[2]: Leaving directory /home/edd/src/debian/QuantLib-0.3.3'

but as make says, there is no quantlib.el (or .elc) anywhere. I am building
in a chroot without emacs or xemacs, which configure duly noted. Do I really
need either one?  And was it the mystery elisp file quantlib.el?

Dirk

-- 
Those are my principles, and if you don't like them... well, I have others.
                                                -- Groucho Marx

[Quantlib-dev] Least Squares Monte Carlo - memory leak

[Neil P F. <fi...@ma...>]

Hi,

Thanks for fixing the BinomialEngine for Americans.

Having done most of my programming in Java I'm not too tidy on memory
management... There are only a couple of new's called, and they are not in
the loops. I guess the obvious place to look is the SVD class, as a lot of
the work is done there, and there are many containers used, but they
should all be on the stack and disposed of after each timestep.

I was wondering whether I should be using Disposable<> somewhere..

Looking at the code again, in SVD::getV() the Matrix is passed in by
reference, but another Matrix is constructed inside the function. If the
least squares problem is rank deficient the the matrices may be different
sizes.

It may also be due to my naive port of the TNT::Array2D to Math::Matrix.

Have you a tool like OptimizeIt for Java, that will show where the problem
is?

Hope that this is some help...

Neil

---------------------------------------------------
  Neil Firth
  Brasenose College Oxford OX1 4AJ United Kingdom
  Office: 01865 280616
  fi...@ma...
  http://www.maths.ox.ac.uk/~firth
---------------------------------------------------

[Quantlib-dev] Re: [Quantlib-users] Least Squares Monte Carlo

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

At 04:48 PM 7/24/03 +0100, Neil P Firth wrote:
>Finally, the Binomial PricingEngines don't give me the correct price.
>Presumably I haven't set them up correctly, but I can't see what's wrong.

Neil,
         I fixed the binomial engine---they give the correct price now in 
your example. Also, I've added the number of time steps as an input to your 
least-square engine. The changes are on the branch.

The remaining problem is, the least-square engine might be leaky, or at 
least a memory hog---on my Windows box the example runs with 200000 
samples, but on my Linux laptop it fails with bad allocation with as few as 
10000. Do you have any idea where all the memory could go?

Bye,
         Luigi


P.S. I have a few more data which might get you on track.

5000 samples, 3 time steps:   runs
10000 samples, 3 time steps:  not enough memory
5000 samples, 100 time steps: runs happily.

Which seems to suggest that the memory used depends more on the first 
parameter...

[Quantlib-dev] tarballs

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

Hi all,
	tarballs of the branch are available at http://quantlib.org/gm if you want 
to play with them.

Later,
	Luigi

[Quantlib-dev] Branch ready - please read

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

Hi all,
	the cvs branch tagged R000303f0-branch is ready, both in QuantLib and 
QuantLib-SWIG. We'll use it for drawing the line: from now on, bug-fixes to 
the present code base should be committed on the branch and will be 
included in release 0.3.3; new developments should be committed on the 
trunk and will go into the subsequent release. If you're not familiar with 
cvs, just send me a line and I'll sketch the steps to take.

Later,
	Luigi

[Quantlib-dev] Branching in a few minutes

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

Hi all,
	I'm creating the release branch in a few minutes. If you have anything to 
commit, please wait that I'm done---I'll send another mail when I am.

Later,
	Luigi

[Quantlib-dev] RE: MakeScheduler

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

At 12:28 PM 7/25/03 +0200, Andre Louw wrote:
>Sorry for not making myself clear, I realize I would not need to implement
>MakeScheduler.
>Yr example triggered me to think of something else I'm doing where a
>conversion operator would work very nicely.
>SWIG does not directly support the concept of conversion operators, is there
>another mechanism/hook I can use to get a similar result?

Andre,
         the problem is not SWIG, it's the semantics of Python.
In C++, if you write:

Foo f;
f = Bar();

the object "f" remains a Foo, and a conversion operator is called so that 
the Bar is transformed into a Foo. In Python, if you write:

f = Foo()
f = Bar()

what you are doing is discarding the Foo object and rebinding the variable 
"f" to the Bar object. The same applies to most other languages supported 
by SWIG.
Therefore, automatic conversion between any two types is simply not possible.

What you can do if you have two classes such as:

class Foo {};
class Bar {
   public:
     operator Foo() { ... }
};

is to export them to SWIG as:

class Bar {};

class Foo {
   public:
     %extend {
         Foo(const Bar& b) { return new Foo(b); }
     }
};

Be aware though that in Python you'll have to use explicit conversion, 
i.e., you'll have to write:

Bar b
f = Foo(b)

Later,
         Luigi