quantlib-users — QuantLib users discussion list

[Quantlib-users] it has been quiet

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

Hi all

it has been quiet on the list, even if there has been a huge number of 
commit into the cvs repository. I understand that having 6 active 
developers in RiskMap have trapped many design discussions inside our 
office, and I commit to have a more open approach in the following months.

QuantLib probably needs more frequent releases, but the problems 
experienced with Sourceforge stopped the release process. We plan a new 
release by the end of March, which will include all the latest works.

I hope the new release will significantly enlarge our user base.
We're doing some consulting for an Italian bank: their quants are the only 
non-RiskMap users I know of.
If you're using QuantLib (or plan to use it), please get in touch.

We at RiskMap will try to summarize in the next weeks all the new addition 
and improvements of the last months, and we will provide updated documentation.

Many people subscribed to the list (we reached 50 subscribers): I urge all 
interested people to use this list to make proposals, requests, 
suggestions, etc.
I will try to be as responsive as possible.

In the last months the development has been focused mainly on basic 
building blocks, anyway as  Patrick Henaff suggested it would be useful to 
publish a white paper describing the object model for trades, instruments, 
market data and models.
I still have to do my homework (starting with few chapters of Martin 
Fowler's book, "Analysis Patterns"), but if someone as a proposal please 
submit it.


ciao -- Nando

RE: [Quantlib-users] activity...

[Kloss, B. <Bur...@kb...>]

Okay, great - I'll grab the latest release from CVS then and play with that
instead.

Burkhard Kloss
KBC Financial Products
http://www.kbcfp.com/ 
+44 20 7614 6283

-----Original Message-----
From: Luigi Ballabio [mailto:lui...@ri...]
Sent: 27 February 2001 09:29
To: Kloss, Burkhard
Cc: QuantlibUsers (E-mail)
Subject: Re: [Quantlib-users] activity...



Hi Burkhard,
         what Enrico meant was that the current cvs snapshot compiles under 
Linux - the release on sourceforge doesn't.

Bye (and thanks for the kind words),
                                         Luigi

At 07:09 PM 2/27/01 +0100, Enrico Sirola wrote:
> >>>>> "KB" == Kloss, Burkhard <Bur...@kb...> writes:
>
>     KB> Hi!  I've just started exploring quantlib on sourceforge - and
>     KB> it looks quite impressive! I'll probably start trying to get
>     KB> it to compile on Linux sometime this week - just wondering if
>     KB> anyone else is already working on that.  BTW, I've found using
>     KB> STLport's library with gcc extremely effective!
>
>Hi Burkhard,
>the sources should actually compile under linux, if you have gcc
>2.95.2 (trying to compile it with previous versions is probably
>hopeless). There's a configure script you should run to create
>necessary makefiles, then everything should work.





_______________________________________________
Quantlib-users mailing list
Qua...@li...
http://lists.sourceforge.net/lists/listinfo/quantlib-users

Re: [Quantlib-users] activity...

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

Hi Burkhard,
         what Enrico meant was that the current cvs snapshot compiles under 
Linux - the release on sourceforge doesn't.

Bye (and thanks for the kind words),
                                         Luigi

At 07:09 PM 2/27/01 +0100, Enrico Sirola wrote:
> >>>>> "KB" == Kloss, Burkhard <Bur...@kb...> writes:
>
>     KB> Hi!  I've just started exploring quantlib on sourceforge - and
>     KB> it looks quite impressive! I'll probably start trying to get
>     KB> it to compile on Linux sometime this week - just wondering if
>     KB> anyone else is already working on that.  BTW, I've found using
>     KB> STLport's library with gcc extremely effective!
>
>Hi Burkhard,
>the sources should actually compile under linux, if you have gcc
>2.95.2 (trying to compile it with previous versions is probably
>hopeless). There's a configure script you should run to create
>necessary makefiles, then everything should work.

Re: [Quantlib-users] activity...

[Enrico S. <si...@ri...>]

>>>>> "KB" == Kloss, Burkhard <Bur...@kb...> writes:

    KB> Hi!  I've just started exploring quantlib on sourceforge - and
    KB> it looks quite impressive! I'll probably start trying to get
    KB> it to compile on Linux sometime this week - just wondering if
    KB> anyone else is already working on that.  BTW, I've found using
    KB> STLport's library with gcc extremely effective!

Hi Burkhard,
the sources should actually compile under linux, if you have gcc
2.95.2 (trying to compile it with previous versions is probably
hopeless). There's a configure script you should run to create
necessary makefiles, then everything should work.
Regards,
Enrico
-- 
Enrico Sirola <en...@us...>

     Key fingerprint = B446 7332 ED55 BC68 5FE8  DE0F 98DF EC86 377F E07F

[Quantlib-users] activity...

[Kloss, B. <Bur...@kb...>]

Hi!  I've just started exploring quantlib on sourceforge - and it looks
quite impressive! I'll probably start trying to get it to compile on Linux
sometime this week - just wondering if anyone else is already working on
that.  BTW, I've found using STLport's library with gcc extremely effective!

Regards,

Burkhard Kloss
KBC Financial Products
http://www.kbcfp.com/ 
+44 20 7614 6283

RE: [Quantlib-users] Coding Practice Guidelines

[Gilbert P. <gi...@ci...>]

>
> It's ok with me. I assume you would be in charge of the thing, right? :)
>

My previous boss always managed, and never worked ;-) Yes, I will do the
typing ...



> Bye,
>          Luigi
>

RE: [Quantlib-users] Coding Practice Guidelines

[Gilbert P. <gi...@ci...>]

Hi Luigi,
Since the guidelines are not comlpete, what are your thoughts on the idea to
complete them together with the guys in Norway?
Gilbert

> -----Mensaje original-----
> De: qua...@li...
> [mailto:qua...@li...]En nombre de Luigi
> Ballabio
> Enviado el: 24 January 2001 15:43
> Para: QuantLib Users
> Asunto: Re: [Quantlib-users] Coding Practice Guidelines
>
>
> At 12:39 PM 1/24/01 +0100, Gilbert Peffer wrote:
> >Beside the coding style guidelines, Jacob Dreyer from
> Geotechnical Software
> >Services has started writing C++ coding practice guidelines. You can find
> >them in http://geosoft.no/cpp.html.
> >
> >His comment was that these guidlines are not yet finished and
> suggested that
> >one could finish this in a joint effort. The guidelines are
> mostly based on
> >Meyers.
> >
> >What are your thoughts on this?
>
> I had a look at the thing and I agree with the recommendations -
> I actually
> use them already, which wasn't true for the previous batch :)
>
> The only thing I would correct is the "must" in
>
> 28. A public member function must never return a non-const reference or
> pointer to member data
>
> which doesn't take into account members like Array::operator[](int).
> While the above might violate encapsulation as argued,
> a[4] = 3.5
> is _much_ clearer than
> a.setElement(4,3.5)
> or whatever other name you give it.
>
> Bye,
>          Luigi
>
>
> _______________________________________________
> Quantlib-users mailing list
> Qua...@li...
> http://lists.sourceforge.net/lists/listinfo/quantlib-users
>

Re: [Quantlib-users] Coding Practice Guidelines

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

At 12:39 PM 1/24/01 +0100, Gilbert Peffer wrote:
>Beside the coding style guidelines, Jacob Dreyer from Geotechnical Software
>Services has started writing C++ coding practice guidelines. You can find
>them in http://geosoft.no/cpp.html.
>
>His comment was that these guidlines are not yet finished and suggested that
>one could finish this in a joint effort. The guidelines are mostly based on
>Meyers.
>
>What are your thoughts on this?

I had a look at the thing and I agree with the recommendations - I actually 
use them already, which wasn't true for the previous batch :)

The only thing I would correct is the "must" in

28. A public member function must never return a non-const reference or 
pointer to member data

which doesn't take into account members like Array::operator[](int).
While the above might violate encapsulation as argued,
a[4] = 3.5
is _much_ clearer than
a.setElement(4,3.5)
or whatever other name you give it.

Bye,
         Luigi

[Quantlib-users] rules

[Gilbert P. <gi...@ci...>]

Hi everybody,

Please find below the suggestions for changing the style guidelines in
http://geosoft.no/style.html. I marked those suggestions with CONTENTIOUS
where people didn't agree.

Please have another look at this list and provide some suggestions for the
still contentious bits.

Thanks, Gilbert

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


Luigi Ballabio
--------------

5) Ok for having #defines in uppercase. I'd prefer enumerations inside
classes and static const class variables in mixed case starting with lower
case.


8) [...] We could relax rule 8, and leave it to the judgment of the
programmer whether a fully specified name would help. If not, the
single-character rule applies.


17) CONTENTIOUS ok for employee.setName(). However, employee.getName() seems
a bit
redundant to me - employee.name() is just as clear. Unfortunately this
would conflict with 6) since name() is not a verb (well, not in this case).
What the hey, you decide and tell me. [Nando argued against it. Shall we
leave the rule as it is?]


49) I would make an exception for static const variables, for which I see
no reason for access through a get() method.


69) I find an indentation of 4 more readable than 2. But hey, that's just
me, I can get used to it.


70) I like better example 1 for classes and functions too. But again,
that's just me.


83) f (x) looks very strange to me with the space in the middle. Then
again...


90) We'll have to stick to /* ... */ when comments are to be extracted by
Doxygen.

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


Gilbert Peffer

22. I often call variable or object containers <set>, although for a
mathematical purist, this can provoke considerable grief


24. I usually use <num>, but <no> is as good. One may as well permit both


36. This is currently in contradiction to some of the code in Quantlib. I
myself are not too consistent in this particular style case. What do you
think?


38. CONTENTIOUS: ...TABs should be avoided. Does anybody have an idea of the
real impact
the use of TABs can have? [Shall we delete this rule?]


69. I prefer 4 spaces


73. I prefer the SUN recommendation, but this has no big impact anyway, I
think


87. CONTENTIOUS  I would like to add a suggestion for function/subroutine
definitions.
For long argument lists (and for short ones as well), I prefer to stack the
arguments

    runThisRoutine (int     numNodes,
                    int     numElements,
                    double* coordinateSet,
                    int*    connectivityList) {
        blah blah
    }
[I still prefer argument stacking for readability. What are your thoughts?]

RE: [Quantlib-users] Response from Geotechnical Software Services

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

Hi all

Gilbert wrote:
>Although copying the HTML code of the list is a matter of seconds, there is
>the disadvantage of maintenance. So to get this done, I we should indeed
>just link to the original list. I'll create an HTML document with that link
>and upload it into the Porject Documentation Area, if that's OK with
>everybody.

I would suggest you post here (in plain text) the summary of the topics 
where we have a different opinion. So everybody get a chance to review them.

Then we can submit our changes to Geotechnical for inclusion into their 
page. If they accept them we can link to their page, or even better get a 
permission to copy their page so to freeze the version we like.

If they reject them we'll just create a page with our modified topics and a 
link to their original page.

I'm not enough qualified to fully answer their questions:
 > I am sure you guys have more experience than me regarding
 > copyrights and open source and the various issues in that
 > respect, and I whould be grateful for any advices you could
 > give me regarding the different options I/you have and what
 > this will mean for me, my guide, you and your version of the
 > guide now and in the future.


ciao -- Nando

[Quantlib-users] Coding Practice Guidelines

[Gilbert P. <gi...@ci...>]

Hi everybody,

Beside the coding style guidelines, Jacob Dreyer from Geotechnical Software
Services has started writing C++ coding practice guidelines. You can find
them in http://geosoft.no/cpp.html.

His comment was that these guidlines are not yet finished and suggested that
one could finish this in a joint effort. The guidelines are mostly based on
Meyers.

What are your thoughts on this?

Thanks in advance

Gilbert

RE: [Quantlib-users] Response from Geotechnical Software Services

[Gilbert P. <gi...@ci...>]

Hi,
Sorry it took that long to pick up on this issue.

Although copying the HTML code of the list is a matter of seconds, there is
the disadvantage of maintenance. So to get this done, I we should indeed
just link to the original list. I'll create an HTML document with that link
and upload it into the Porject Documentation Area, if that's OK with
everybody.
Best regards

Gilbert

> -----Mensaje original-----
> De: Marco Marchioro [mailto:Mar...@ri...]
> Enviado el: 17 January 2001 14:15
> Para: Gilbert Peffer
> Asunto: Re: [Quantlib-users] Response from Geotechnical Software
> Services
>
>
> Hi all,
>          to resolve the question of the copyright I think it is better to
> write a page in which we
> link to the guideline page and then we just give list of topics where we
> have a different
> opinion. Otherwise, somebody would have to rewrite completely
> that long page.
>          ciao,
>                  Marco.
>
> At 15:12 01/01/15 +0100, you wrote:
> >Hi Nando,
> >I received this reply to my queries about copyright issues for the style
> >guidelines. Unfortunately I don't know much about copyright
> issues either,
> >so I welcome any comment to the reply I attach below.
> >Best regards
> >Gilbert
> >
> >
> > > -----Mensaje original-----
> > > De: ja...@ey... [mailto:ja...@ey...]En
> nombre de Jacob
> > > Dreyer
> > > Enviado el: 06 January 2001 06:24
> > > Para: Gilbert Peffer
> > > Asunto: Re: guideline copyright
> > >
> > >
> > > Hi Gilbert,
> > >
> > > Thanks for your interest in the coding guideline project.
> > >
> > > I am sure you guys have more experience than me regarding
> > > copyrights and open source and the various issues in that
> > > respect, and I whould be grateful for any advices you could
> > > give me regarding the different options I/you have and what
> > > this will mean for me, my guide, you and your version of the
> > > guide now and in the future.
> > >
> > > As you might have noticed there is also a related "coding
> > > practice" guideline which I have great belief in, but that
> > > I unfortunately not have had the time to complete. It whould
> > > have been great to have a joint project started to work on
> > > that guide, but as it is to some degree build on the advices
> > > of Scott Meyers, I am sure there could be some copyright twist
> > > there as well?
> > >
> > > Regards,
> > >
> > > Jacob Dreyer
> > > General Manager
> > > Geotechnical Software Services
> > > Stavanger - Norway
> > >
> > >
> > >
> > > Gilbert Peffer wrote:
> > > >
> > > > Hi there,
> > > >
> > > > We have been reading your C++ Programming Style Guidelines
> with great
> > > > interest and would like to use them in an open-source project
> > > as our base
> > > > guidelines for the C++ part of that project.
> > > >
> > > > However, some of the software developers would want to add
> > > rules or alter a
> > > > few of the rules. We were thinking of reproducing your
> > > guidelines and adapt
> > > > them to our needs, but this obviously requires your permission
> > > because of
> > > > the copyright status. Could you please let me know if you were
> > > prepared to
> > > > grant us this permission, and under what conditions.
> > > >
> > > > The open source project is called QuantLib and is hosted by
> SourceForge,
> > > > more details of which you can find at its home page
> > > > http://sourceforge.net/projects/quantlib/.
> > > >
> > > > Best regards
> > > >
> > > > The QuantLib Development Team
> > >
> >
> >
> >_______________________________________________
> >Quantlib-users mailing list
> >Qua...@li...
> >http://lists.sourceforge.net/lists/listinfo/quantlib-users
>

[Quantlib-users] MonteCarlo alpha version.

[Marco M. <Mar...@ri...>]

Hi QuantLib people,
	I finished the first draft for the Monte Carlo tools. You will find the 
related
files in the MonteCarlo folders. So far only the one dimensional tools are
available. Soon, but this time I don't want to give a schedule, I will add some
multidimensional tools.
The tools are in the QuantLib spirit of "if you know templates is better, 
otherwise
you can do it anyway," therefore there are some typedef to define simple 
defaults like,
for example, GaussianRandomGenerator.
The basic idea is that of a "sample generator" that have the following, 
simple,
interface:

	SampleType next()  const;	// Gives the next sample
	double weight() const;		// Giving the weight of the last sample

where SampleType is the particular type of sample which for a random
generator is a double and for a path generator is a Path.

The sample accumulator used now is Statistics. However using RiskTool instead
it is possible to have a MonteCarlo method for other risk measure like VaR.

Two pricers were added as examples. McEuropeanPricer, that is very basic
and McAsianPricer that also implements a control variate.

I am available for questions. Let me know if you see a way to
improve the design.
	greetings,
			Marco Marchioro.

[Quantlib-users] Response from Geotechnical Software Services

[Gilbert P. <gi...@ci...>]

Hi Nando,
I received this reply to my queries about copyright issues for the style
guidelines. Unfortunately I don't know much about copyright issues either,
so I welcome any comment to the reply I attach below.
Best regards
Gilbert


> -----Mensaje original-----
> De: ja...@ey... [mailto:ja...@ey...]En nombre de Jacob
> Dreyer
> Enviado el: 06 January 2001 06:24
> Para: Gilbert Peffer
> Asunto: Re: guideline copyright
>
>
> Hi Gilbert,
>
> Thanks for your interest in the coding guideline project.
>
> I am sure you guys have more experience than me regarding
> copyrights and open source and the various issues in that
> respect, and I whould be grateful for any advices you could
> give me regarding the different options I/you have and what
> this will mean for me, my guide, you and your version of the
> guide now and in the future.
>
> As you might have noticed there is also a related "coding
> practice" guideline which I have great belief in, but that
> I unfortunately not have had the time to complete. It whould
> have been great to have a joint project started to work on
> that guide, but as it is to some degree build on the advices
> of Scott Meyers, I am sure there could be some copyright twist
> there as well?
>
> Regards,
>
> Jacob Dreyer
> General Manager
> Geotechnical Software Services
> Stavanger - Norway
>
>
>
> Gilbert Peffer wrote:
> >
> > Hi there,
> >
> > We have been reading your C++ Programming Style Guidelines with great
> > interest and would like to use them in an open-source project
> as our base
> > guidelines for the C++ part of that project.
> >
> > However, some of the software developers would want to add
> rules or alter a
> > few of the rules. We were thinking of reproducing your
> guidelines and adapt
> > them to our needs, but this obviously requires your permission
> because of
> > the copyright status. Could you please let me know if you were
> prepared to
> > grant us this permission, and under what conditions.
> >
> > The open source project is called QuantLib and is hosted by SourceForge,
> > more details of which you can find at its home page
> > http://sourceforge.net/projects/quantlib/.
> >
> > Best regards
> >
> > The QuantLib Development Team
>

Re: [Quantlib-users] programming styles

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

Just a thought I had writing some code, regarding rule 8 of the guidelines 
(i.e., Names representing template types should be a single uppercase letter).

It is true that, for instance,

template <class Type> class Handle;

does not give any information more than

template <class T> class Handle;

does, so that in this case rule 8 holds.

However, there are cases where a longer name does add information. Namely,

template <class RandomAccessIterator> class SteppingIterator;
template <class Iterator, class UnaryPredicate> class FilteringIterator;

are in my opinion more understandable even at a superficial glance than

template <class I> class SteppingIterator;
template <class I, class P> class FilteringIterator;

because in the former case the names express the requirements for the 
template arguments with single terms which are clear enough to any one that 
happened to browse through the C++ standard.

Bottom line: we could relax rule 8, and leave it to the judgment of the 
programmer whether a fully specified name would help. If not, the 
single-character rule applies.

What do you think?

Bye,
	Luigi

[Quantlib-users] QuantLib autoconfiscation

[Enrico S. <enr...@ri...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi all,
I committed the changes I made to autoconfiscate QuantLib. Basically,
I added some Makefile.am, the configure.in and few changes in the
qldefines.h
library header. The library (with these changes) is known to compile
on 
g++ 2.95.2 on Debian GNU/Linux 2.2 and on cygwin g++ 2.95.2 on NT4.0
Actually typing "./updateproject; ./configure; make; make install;"
you (should) 
build the static and shared libraries, while with "make python" you
generate the python wrapper. You have to intall automake, autoconf
and libtool to build
the configure script.

Python module:
to compile and install the python module too, you have to install the
library and have the distutils python package installed on your
system.
It comes with Python 2.0 and is available for Python 1.5.
Type these commands to build the module (on a sh-like shell):

$ cd Python
$ python setup.py build
$ python setup.py install
$ cd Tests
$ for i in *.py ; do python $i ; done; (to run all the tests)

known problems/missing features:
* real python support. The python module isn't generated directly by
the 
  configure-generated Makefiles
* docs target. 
* the build system compiles the library with a -DHAVE_CONFIG_H flag
  on command line enabling the use the set of macros defined in 
  Include/config.h (look at the structure of qldefines.h); when you
want
  to link a program you include /<prefix-dir>/QuantLib/qldefines.h,
but your
  compiler doesn't define HAVE_CONFIG_H, so you would use the
non-autoconfiscated
  part of the header. To make sure that the library user uses the
autoconfiscated
  part of the header, after installing qldefines.h I run a little sed
oneliner on
  it to change HAVE_CONFIG_H in QL_HAVE_CONFIG_H and defining
QL_HAVE_CONFIG_H at
  the beginning of the file. I'm not sure if this is a wise solution,
but it seems
  to work. Any alternative ideas?
* I've just read that automake 1.4b (released today) supports python!
  I think we should use its new features in the future.
* python module problem on cygwin: the default compiler for distutils
is VC++
  so you can't use the cygwin-g++ generated library to link the
modules. There
  are some hints on the web to use cygwin compiler with distutils,
but you
  need a cygwin-built python, so it doesn't seem very appealing
(anyway, let
  me know your opinion)

Many thanks to David Binderman, Bernd Wuebben and Peter Schmitteckert
who
helped/contributed some patches.
Please take a look at the files and send me some feedback
Cheers,
Enrico

-----BEGIN PGP SIGNATURE-----
Version: PGPfreeware 6.5.8 for non-commercial use <http://www.pgp.com>

iQA/AwUBOlwlB5jf7IY3f+B/EQIMpwCfZhW5L34jQXsfW+z4U1MRSl8KU/UAnjId
WyiIwZmmSpMQ0CIkxBc91qQ7
=MRWt
-----END PGP SIGNATURE-----

[Quantlib-users] guideline copyright

[Gilbert P. <gi...@ci...>]

Hi there,

We have been reading your C++ Programming Style Guidelines with great
interest and would like to use them in an open-source project as our base
guidelines for the C++ part of that project.

However, some of the software developers would want to add rules or alter a
few of the rules. We were thinking of reproducing your guidelines and adapt
them to our needs, but this obviously requires your permission because of
the copyright status. Could you please let me know if you were prepared to
grant us this permission, and under what conditions.

The open source project is called QuantLib and is hosted by SourceForge,
more details of which you can find at its home page
http://sourceforge.net/projects/quantlib/.

Best regards

The QuantLib Development Team

[Quantlib-users] SourceForge problems

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

SourceForge is fixing the problems we experienced in the last month.

Namely if you failed while trying to get a sourceforge account, try once 
again since this bug should have been fixed.

QuantLib-CVS mailing list is back at work.

ciao -- Nando

Re: [Quantlib-users] KQuantlib [Re: Quantlib design]

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

Hi all

Bernd  wrote:
>We have python for scripting (other such as perl, java etc can be
>added over time leveraging swig) As far as visual working with the data
>is concerned I prefer spread sheets (Excel to be precise and I will
>contribute the sceleton of an excel interface soon).
I really look forward to the skeleton of the excel interface. Have you 
considered to use SWIG core API for this task? I have no expertise on SWIG, 
but I like leveraging ;-)

>  Interfaces to matlab,
>octave, R, etc  are essentially trivial to write which will address
>another area of use.
That's interesting too since I've never used matlab/octave and I would like 
to start using them for/with QuantLib

>spread sheet interfaces (Excel, Applix,
>Star office, Gnumeric, Kspread).
I've used Applix API in the past for using C++ code, but from the little 
I've seen Excel is different. Is there any common pattern between Star 
office, Gnumeric, Kspread?

ciao -- Nando

Re: [Quantlib-users] Re: Quantlib design

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

Hi all

Mark wrote:
 > Is Quantlib going to be a full risk management system, or is the
 > goal to be a standard library of calculation routines that any
 > risk management system could use?
The latter.
I do think systems and GUIs based on QuantLib can be interesting (I actually
hope they will be the result of the QuantLib project): just don't expect 
such projects to be merged into QuantLib development.
Before we reach that point we need a way better and more stable library, 
and I don't think we'll get there in the near future.
Excel/Matlab/Octave/Python etc. are the suggested way to use QuantLib (see 
also http://quantlib.sourceforge.net/goals.html)

 > If you're interested, I've also started an open source risk
 > management system, called the Finicky Financial Trading System
 > (http://ffts.sourceforge.net).
 > Quantlib is interesting to me as a source of pricing functions,
 > so I wouldn't have to reinvent the wheel for Black-Scholes
 > pricing, stochastic vol models, etc. Or at least, I could
 > write some of those routines and make them available in Quantlib
 > for others to use and improve on.
Just go ahead, that's why I started the project!

I've took a quick look at your project to see if/how we can merge.
[BTW what "Finicky" does mean?]

As a preamble I have to say that the GPL licence you adopted does not allow 
QuantLib to borrow code from FFTS, unless you (the copyright holder) submit 
your contributions to our licence. The reverse is possible with no problem.
[If anyone wants more details on the licence issue please check 
http://quantlib.sourceforge.net/license.html]
Your mileage might vary, anyway I agree that GPL is a good choice for an 
application. Since QuantLib is a library I choose a more "liberal" XFree-86 
style licence that allows software company to use QuantLib in their 
projects, whatever the licence they adopt. I might reconsider this, but not 
in the near future and not without 100% consensus of all QuantLib 
developers and the majority of QuantLib users.
In any case I ask not to start a licence thread here, not for the time 
being please.

I select few issues I've found of immediate interest.
If you agree I hope you will consider reworking FFTS to link to QuantLib, 
merging into QuantLib additional features you have and we miss. This can be 
a gradual viable approach, that preserve our library nature and your 
application nature.


a) folder FFTS\analitics
a1) BSOption: I noticed that we have an approach more object oriented, FFTS 
has many function here.
This is not dramatic, especially since we'll work to produce Excel 
extension, so a well designed function list is on our way.
You just need to wrap our class methods into your existing function
a2) AmericanOption: the same as above. You may need some tuning to 
calibrate our finite difference approach to fit your speed/accuracy 
constraints. Anyway this could be better than your binomial tree approach.
a3) BSOneTouch: we don't have one-touch barrier yet just because we're 
lazy. It should be an easy task in the current framework.
What is important here is that we want to separate Model classes (trees, 
finite difference) from pricing code (american, barrier, etc.)
I need to clarify our proposal for a Model class asap, but this will take 
some time. Then I hope it will be clear how I would like FiniteDifference 
and trees to share the same interface. This is why I skip FFTS\tree and 
FFTS\PricingTree right now.
a4) instead of "int CallOrPut" we prefer enumerations. We have Straddle also.
a5) RandomLCG (Applied Cryptography random generator) and RandomGauss can 
easily be added to our "Random Number" framework. What is the license for 
Applied Cryptography?
a5) RootFinding: we already have Newton-Raphson and Brent. You may look at 
our 1Dsolver interface that is shared by all our 1dimensional solvers
a6) ExtraMath.cpp and .h: we already have NormalDistribution and 
CumulativeNormalDistribution functions. We miss the inversion of the 
cumulative function (that is your InvCNormDist function). We can add this 
(btw is it from the Abramowitz too?)
a7) interpolation: we need a more general object-oriented interpolation 
tool. We sketched something at RiskMap but it's not finished yet. QuantLib 
has a function newcubicspline for the time being, the non-sense name tells 
the whole story.
Once the tool is ready you can use it in your VolFunctions

b) folder FFTS\string
format utilities can merge into our dataformatters.cpp and .h

c) folder FFTS\types
c1) date class: we miss some date parsing methods - even though we wonder 
whether they belong to an external code layer rather than to the library. 
However, we can easily merge here smoothing our little differences.
c2) matrix class. We at RiskMap have a similar class that we have not 
contributed yet to QuantLib since it needs some work
c3) why you need a FractionalValue? (just wondering)
c4) class GenericCurve. Once again at RiskMap we have a similar class we're 
unhappy with. The requirements here is that we plan to have both "discrete" 
knot curves (that is function tabulated at selected values) and "continue" 
analytic curves (that is function described with analytic formula) sharing 
the same interface, so that they will be inter-operable at any level (e.g. 
a Nelson-Siegel analytic curve fitted on Treasury bonds can be used instead 
of knotted Libor curve). Anyone has such a piece of software ready to be 
contributed? ;-)
c5) class CTenor. We can add this, but I don't see the reason to 
discriminate between BusinessDay and Day. Day could be enough, it's the 
holiday that make the difference (LONDON calendar has its holidays, 
NOMARKET calendar has no holidays)

d) folder FFTS\holiday
we may work to merge here

Some general comment:
i) we prefer Exception instead of return( HUGE_VAL ).
ii) I've also seen your C++ test: C++ is better (more general) than our 
Python approach, so everybody is welcome to port the available tests from 
Python to C++.

As a final note I suggest you take a look at our coding guidelines: Gilbert 
is working on that, for the time being http://www.geosoft.no/style.html is 
a good starting point.
QuantLib itself is not conforming to its own coding guidelines, but we are 
working on that ;-)


ciao -- Nando

[Quantlib-users] Differential operators

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

Hi all,
	I added a few classes this morning in the Finite Differences framework, 
namely, DPlus, DMinus, DZero, and DPlusDMinus. Given a discrete function u 
on a grid with step h, the first three discretize the first derivative as:

D+ u[i] = (u[i+1]-u[i])/h
D- u[i] = (u[i]-u[i-1])/h
D0 u[i] = (u[i+1]-u[i-1])/2h

while the fourth discretizes the second derivative as

D+D- u[i] = (u[i+1]-2u[i]+u[i-1])/(h^2).

The release of these operators is meant to make easier for a programmer to 
create its own differential operator by combining them. Also, it is a step 
towards making one able to write finite differences code in Python.

For the time being, the side effect of this release is that one is now able 
to calculate numerical derivatives in C++ and Python. An example in Python 
(which I hope is understandable by non Python programmers also) is below.

Bye for now,
		Luigi


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

from QuantLib import *
from math import exp

# define a (not normalized) Gaussian with sigma = 1
def f(x):
	return exp(-x*x/2.0)

# discretize it on the range [-4,4] with step 0.01
xMin = -4.0
xMax = 4.0
h = 0.01
N = (xMax-xMin)/h + 1

# calculate the grid
x = [0]*N		# creates a list of N elements
for i in range(N):
	x[i] = xMin+h*i

# calculate the values on the grid by applying f to every x
y = map(f,x)

# most of the code of this example is above and dealt with
# creating the discretized function - which quite a few times
# you already have stored somewhere.

# the actual derivation takes a few lines only:
# define the first and second derivative operators

D = DZero(N,h)
D2 = DPlusDMinus(N,h)

# and calculate the derivatives

dy = D.applyTo(y)
d2y = D2.applyTo(y)

# simple as that. You can now use your favorite plotting
# tools to check that dy and d2y indeed contain the first
# and second derivative of the defined Gaussian, respectively.

[Quantlib-users] Re: Quantlib design

[Mark H. <mgh...@ya...>]

> Regarding design, as mentioned earlier, we mostly used the
> ideas found in Fowler's.

Is Quantlib going to be a full risk management system, or is the
goal to be a standard library of calculation routines that any
risk management system could use?

My impression from the project description was the latter, but
let me know if I'm wrong.

If you're interested, I've also started an open source risk
management system, called the Finicky Financial Trading System
(http://ffts.sourceforge.net). It's still very much in 
development, and I'd be very much interested in hearing design
ideas.

Quantlib is interesting to me as a source of pricing functions,
so I wouldn't have to reinvent the wheel for Black-Scholes 
pricing, stochastic vol models, etc. Or at least, I could
write some of those routines and make them available in Quantlib

for others to use and improve on.



=====
-------------------------------------------------------
Mark Higgins, mgh...@ya...
http://www.molala.net

Opinions expressed herein do not reflect my own views;
I haven't had free will since last year when aliens ate
my brain.

__________________________________________________
Do You Yahoo!?
Yahoo! Photos - Share your holiday photos online!
http://photos.yahoo.com/

[Quantlib-users] Full first Linux Port

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

Bernd replied to a message nobody received since the author (Enrico) posted 
it to the defunct quantlib-dev list.

I attach the original message here.

I'm back at work, I will take a look at the SourceForge status, I hope they 
fixed at least some problem.

ciao -- Nando

==========

From: "Enrico Sirola" <enr...@ri...>
Subject: RE: [Quantlib-dev] Full first Linux Port

Hi,
thanks a lot for your work. I'm working to "autoconfiscate" the whole
beast in these days, and the job is nearly finished. Actually, i have
a bunch of working Makefile.am and a configure.in who generates
(using libtool) the static and shared libraries and the python stuff.

There are some things to do/decide:
1) do the quantlib users prefer to have a single configure.in who
    generates all the stuff, python included?
2) The configure.in works and generates the right makefiles for
    a gnu/linux with gcc 2.95.2 and a recent libstdc++, but we need
    more serious checks nonstandard for c++ stuff (missing headers,
    things not in namespace std etc etc)
3) In my opinion, we should consider to use autotools to generate the
    *source* of the python<->c++ wrapper only, and to use distutils
    to create the python binary package (i've tried it on QL and it
seems
    to work quite well). This seems to have the drawback
    that we should come out with two packages: a
    pyQuantLib<foo>.[src|bin].tgz
    and a QuantLib<foo>.[src|bin].tgz. The "src" of pyQuantLib should
    contain the source of the wrapper and should require that you have
    QuantLib headers and shared library installed, while the bin
package
    is a final user ready-to-install package who requires the shared
library
    of quantlib only.
    In the meantime, i think we should provide a QuantLib-dev package
    (for those who would like to use the library for their
applications
    in c++) containing a compiled shared and static quantlib and the
    quantlib headers.
4) does any1 have some experience about libtool's version numbering?
We
    should agree on am policy for that too.
5) any volunteer to build .rpm? and .deb? In my opinion these could
be
    important for the linux world.

I didn't commit the autoconfiscated stuff yet becouse there aren't
checks in the configure.in, but let me know if you would like to try
it
(anyway, i think i should finish it for next week)

Ah, by the way, happy new year! :-)
enri

[Quantlib-users] RE: Quantlib design

[Henaff, P. <He...@ko...>]

First of all, apologies for perharps starting a thread in the wrong
direction. When I mentioned Qt, I didn't have a graphical interface in mind,
but was thinking of Qt as a foundation class library, to provide a de-facto
standard for low-level constructs (Lists, Dictionaries, date representation,
etc). Clearly, other libraries could fullfil the same role. 

Several members suggested that a spreadsheet interface is needed, and I
fully agree. It's the basic tool on a trading floor.
In any case, I would not think of a C++ graphical interface, but use Python,
Tcl, etc.

Integration with matlab is also mentioned. I've just spent the past couple
of years deploying matlab-based tools on a trading floor (C dlls, matlab
wrapper and front end). In a nutshell, deployment is a nightmare, because of
interactions between the local desktop environment, the dlls, and matlab.
Matlab graphics are nice, but the price to pay is too high. If this was to
be done again, I would write the front end in Python, or as Java applets.

Regarding design, as mentioned earlier, we mostly used the ideas found in
Fowler's. The most important aspects, in our view, are as follows:
*	The model for phenomenon, measurements and quantities. We model all
market data and all computed values as measurement of a particular
phenomenon on a financial instrument. A measurement yields a quantity, which
is an abstract type for all sorts of representations of market data (e.g.
forward curves, time series, volatility surfaces, etc).
*	Collections of market data are grouped into scenarios. This provides
a general framework for implementing simulations, and for easily switching
from a front office data set to a risk department data set, for example.
*	Portfolios defined by filtering rules on a set of trades, as opposed
to defining a fixed hierarchy of book/portfolio/trade.

I agree with several participants that at this stage, defining the design of
the object model is the most important step. In our experience, this was by
far the hardest portion of the project. In contrast, once this was done,
adding new valuation model became almost trivial. I would suggest to develop
a proof of principle of the object model that illustrates the following
points:
*	The hierarchy of instruments, which should include tradable assets
as well as indices, etc.
*	The relationships between a derivative and its underlying asset. 
*	The independence between valuation models and asset definition. For
example, illustrate how a bond option may be valuated using a simple BS
model, or a one-factor BDT model.
*	The model for defining cash flow schedules

	A sound design would make QuantLib very attractive to developpers,
and would set it apart from commercial pricing libraries. In particular, a
design that would make it easy to investigate the effect of alternate
valuation models. This would turn QuantLib into a financial lab that should
be attractive to researchers and graduate students, who, in turn would push
the acceptance of QuantLib into the corporate world. In fact I would focus
on this point as the competitive advantage of QuantLib over commercial
libraries. 

RV: [Quantlib-users] KQuantlib [Re: Quantlib design]

[Gilbert P. <gi...@ci...>]

Hi guys,
I would like to make a suggestion re Excel/StarOffice and
what-not-spreadsheet-Aps. At my previous job in, we used a very
flexible spreadsheet solution on the trading floor for
Excel/Applix, allowing us to export functionality as soon as we
added it to the quant libraries. The trick was to get away from
the old Addin approach, where you merely make available functions
on the spreadsheet level. The way we did this is to handle
objects rather than functions on the spreadsheet level. In fact,
this was done using only three addins: An <object-create> addin,
a <result> addin, and an <error> addin.

Although I have implemented this here at my office using only
VBA, I remember that our investment bank solution (allowing
proper real-time response for instance) needed some adjustments
at the Applix and Excel back-end. If any of you guys is very good
in office application and API programming, I wouldn't mind
working with that person on a spreadsheet interface. I totally
agree that this is will dramatically increase the attractiveness
of QuantLib to potential testers/users.

Please send me your comments and ideas.

All the best for the New Year

Gilbert

> > -----Mensaje original-----
> > De: qua...@li...
> > [mailto:qua...@li...]En nombre de Marco
> > Marchioro
> > Enviado el: 29 December 2000 10:41
> > Para: pe...@sc...; QuantLibUsers
> > Asunto: Re: [Quantlib-users] KQuantlib [Re: Quantlib design]
> >
> >
> > Dear All,
> >          I agree with Bernd that the time is not ripe for an hard-coded
> > KQuantLib
> > and that the spreadsheet interface is by far the most useful at
> > the moment.
> > I am also very interested in an Excel porting, therefore let me
> know when
> > I will be able to use the QuantLib basic functionalities on my
> spreadsheet
> >
> > have a nice ending and the happiest new year (century, millennium),
> >
> >                  Marco
> >
> > At 12:20 00/12/28 +0100, Peter Schmitteckert wrote:
> > >Dear Bernd,
> > >
> > >On Mit, 27 Dez 2000, you wrote:
> > >[...]
> > > >Where would an application build on the KDE libraries add
> value at this
> > > >point? We have python for scripting (other such as perl, java
> > etc can be
> > > >added over time leveraging swig) As far as visual working
> with the data
> > > >is concerned I prefer spread sheets (Excel to be precise and I will
> > > >contribute the sceleton of an excel interface soon).
> > Interfaces to matlab,
> > > >octave, R, etc  are essentially trivial to write which will address
> > > >another area of use. As far as hardcoded GUI applications are
> > concerned I
> > > >can only see a use in the back-office sector, which is light
> years way
> > > >from where we are now and frankly just looking at our
> sources in their
> > > >current embryonic state I consider it evident that we have much more
> > > >important  things to worry about at this point that the back office.
> > >I agree, that's why I asked which functionality a KQuantLib
> > could provide.
> > >To be specific, which benefits it could provide.
> > >
> > > >No, not gui interfaces, but rather spread sheet interfaces
> > (Excel, Applix,
> > > >Star office, Gnumeric, Kspread). GUI interfaces in the
> > classical sense of
> > > >the word, are IMHO virtually useless with the exception of certain
> > > >repetetive low level  back-office functions. Spread sheets are
> > the tools
> > > >used on the floor and without them we are nothing (as far as
> the reail
> > > >world is concerned) and with them we have an ideal tool to play/test/
> > > >document functionality.
> > >Again, I agree. I won't waste my time in writing  a spread like
> > application.
> > >I have to excuse that I'm not familiar with financial analysis.
> > Therefore I
> > >wonder if there are problems beyond spread applications. And that's why
> > >I'm resisting of getting too deeply involved in QuantLib at the
> > moment, since
> > >I want to do my homework in financial analysis first.
> > >(Note that antiquated programmers like me even prefer awk over
> > spread sheets,
> > >and TeX over Word, and still use xterms and console applications).
> > >
> > >Best wishes,
> > >Peter
> > >
> > >_______________________________________________
> > >Quantlib-users mailing list
> > >Qua...@li...
> > >http://lists.sourceforge.net/mailman/listinfo/quantlib-users
> >
> >
> > _______________________________________________
> > Quantlib-users mailing list
> > Qua...@li...
> > http://lists.sourceforge.net/mailman/listinfo/quantlib-users
> >