QuantLib › quantlib-dev

Why not boost random numbers?

Classic

List

Threaded

7 messages Options

Dimathematician

Why not boost random numbers?

Hi all,

Boost has a random number library too and I was wondering, why this has never
been considered and why own classes have been set up which were not based
on the boost library. I did some simple tests regarding speed: 30.000.000 RN
generations via boost and quantlib. Both with Mersenne Twister and Box-Mueller.

Boost: 32 seconds
QuantLib: 53 seconds

Might be because I'm calling the numbers with .next().value?

------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Ferdinando Ametrano-4

Re: Why not boost random numbers?

On Sun, Jun 7, 2009 at 8:09 PM, Dima<[hidden email]> wrote:
> Boost has a random number library too and I was wondering, why this has
> never been considered and why own classes have been set up which were
> not based on the boost library.

If I remember right Luigi took a look at boost random number and
concluded it was not an half-hour switch.
Beside it's not just matter of abandoning the QuantLib random number
framework, but also porting to the boost framework some generator
which is not available in boost (and which might remain in QuantLib or
could be contributed back to boost)

Anyway you're right that a further "boostification" of the QuantLib
library would be a plus. Not only random numbers, but also math and
stats come to my mind, and there's probably more

As usual any contribution in this direction would be welcome

ciao -- Nando

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Dimathematician

Re: Why not boost random numbers?

Thanks for the reply.

One of the points of mentioning this was, that I liked the consistent architecture of
the random number generators in boost. Although it isn't that flexible in terms of
possible generation methods, since for instance the normal variables are always
created by Box Mueller.

However, I hope I won't affend anyone by saying that I didn't like the architecture for random
numbers in QuantLib. Then again I'm of course free to propose an alternative, which I think
would be a lot of work since the current architecture is implemented everywhere. A closer
alignment to the existing boost classes in future projects would definitely would be a good
idea. Then we can concentrate on the quant finance classes and get the updated standard
boost classes with each new version.

Anyways, just a few thoughts

2009/6/8 Ferdinando Ametrano <[hidden email]>

On Sun, Jun 7, 2009 at 8:09 PM, Dima<[hidden email]> wrote:
> Boost has a random number library too and I was wondering, why this has
> never been considered and why own classes have been set up which were
> not based on the boost library.

If I remember right Luigi took a look at boost random number and
concluded it was not an half-hour switch.
Beside it's not just matter of abandoning the QuantLib random number
framework, but also porting to the boost framework some generator
which is not available in boost (and which might remain in QuantLib or
could be contributed back to boost)

Anyway you're right that a further "boostification" of the QuantLib
library would be a plus. Not only random numbers, but also math and
stats come to my mind, and there's probably more

As usual any contribution in this direction would be welcome

ciao -- Nando

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Luigi Ballabio

Re: Why not boost random numbers?

On Wed, 2009-06-10 at 13:25 +0200, Dima wrote:
> A closer alignment to the existing boost classes in future projects
> would definitely would be a good idea.

Yes, it would---especially since they made it into TR1 and will probably
be part of the next C++ standard. As usual, we lacked time (and unless
I'm very mistaken, it's going to be hard to find it before 1.0 is
frozen.)

Luigi

--

Better to remain silent and be thought a fool than to speak out and
remove all doubt.
-- Abraham Lincoln

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Dimathematician

Re: Why not boost random numbers?

In reply to this post by Ferdinando Ametrano-4

Hi Christian, thanks for you interest.

Let's open this for a discussion? My first step would be to merge the boost distributions to QuantLib.

------------------
Advantages:
------------------

First of all, they have many more distributions, such as non central ones and weibull, triangular.
Then, I personally like the following syntax:

#include <boost/math/distributions.hpp>
using namespace boost::math;

normal_distribution<> nd;

cout << cdf(nd,0.2)            << endl;
cout << pdf(nd,0.0)            << endl;
cout << quantile(nd,0.1)     << endl;

for cdf, pdf and inverse cdf.

----------------------
Disadvantages:
----------------------

Basically I'm not sure if the implementation there suits our needs. I can immagine that boost
provides basic math classes, which are good enough for the standard user, but I'm not sure
if they are good enough for a library that relies a lot on this things and consequently needs
a high quality implementation. But again, I think its better to go with boost in the long run
as it will be improved on a regular basis by the community.

What would a possible merger look like? Either keep current classes such as "InverseCumulativeNormal"
and merge boost in the actual implementation, e.g. initialize a boost distribution in constructor and call
it, instead of the current one.

But I think a better Idea would be to replace the current occurrence of the other classes. This wouldn't be too
much work, since usually the initialization of the cdf is done once, eg.

CumulativeNormalDistribution f; // in the BlackCalculator

Then, f is used throughout the class as a functor. So, if you would replace f here with a boost
class, the merging is straightforward. Running the test_suite will show if there's any difference
to current implementation.

What do you think?


2009/6/18 Pfrang, Christian <[hidden email]>

Hi all,

I've been following the posts on boost and quantlib and I wanted to let you know that I'd be interested in contributing to the boostification of quantlib.

My background is in Applied Math (I'm a graduate student in Stochastic Processes/ Dynamical Systems), but I'm an open source newbie and I would need some guidance as to what would be a useful and doable starting point.

If anyone of you is interested/ has some time to give me an idea what you think could/ should be done that would be great!

Best and thank you,

Christian

-----Original Message-----
From: Ferdinando Ametrano [mailto:[hidden email]]
Sent: Mon 6/8/2009 11:18 AM
To: Dima
Cc: QuantLib developers
Subject: Re: [Quantlib-dev] Why not boost random numbers?

On Sun, Jun 7, 2009 at 8:09 PM, Dima<[hidden email]> wrote:
> Boost has a random number library too and I was wondering, why this has
> never been considered and why own classes have been set up which were
> not based on the boost library.

If I remember right Luigi took a look at boost random number and
concluded it was not an half-hour switch.
Beside it's not just matter of abandoning the QuantLib random number
framework, but also porting to the boost framework some generator
which is not available in boost (and which might remain in QuantLib or
could be contributed back to boost)

Anyway you're right that a further "boostification" of the QuantLib
library would be a plus. Not only random numbers, but also math and
stats come to my mind, and there's probably more

As usual any contribution in this direction would be welcome

ciao -- Nando

------------------------------------------------------------------------------
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables unlimited
royalty-free distribution of the report engine for externally facing
server and web deployment.
http://p.sf.net/sfu/businessobjects
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Pfrang, Christian

Re: Why not boost random numbers?

In reply to this post by Dimathematician

Hi all,

I was asked by Nando to state my interest in participating in the 'boostification' of quant lib on the mailing list to restart that discussion in the open.

I would need some guidance as to where one could get started and Dima already had a few ideas.

Best,

Christian

-----Original Message-----
From: Dima [mailto:[hidden email]]
Sent: Sun 6/7/2009 2:09 PM
To: QuantLib developers
Subject: [Quantlib-dev] Why not boost random numbers?

Hi all,

Boost has a random number library too and I was wondering, why this has
never
been considered and why own classes have been set up which were not based
on the boost library. I did some simple tests regarding speed: 30.000.000 RN
generations via boost and quantlib. Both with Mersenne Twister and
Box-Mueller.

Boost: 32 seconds
QuantLib: 53 seconds

Might be because I'm calling the numbers with .next().value?

------------------------------------------------------------------------------
Are you an open source citizen? Join us for the Open Source Bridge conference!
Portland, OR, June 17-19. Two days of sessions, one day of unconference: $250.
Need another reason to go? 24-hour hacker lounge. Register today!
http://ad.doubleclick.net/clk;215844324;13503038;v?http://opensourcebridge.org
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Luigi Ballabio

Re: Why not boost random numbers?

In reply to this post by Dimathematician

Dima and Christian,
sorry for the delay. The proposal is interesting---as Dima pointed
out, we'd better go with Boost distributions and random numbers in the
long run (especially, I would add, since they will be no longer only
part of Boost; they will also be included in the next C++ standard.)
However, my problem at this time is that we're finalizing the library
interfaces in order to release QuantLib 1.0 (we should be done in a
short while) and we'll freeze the interfaces afterwards. Therefore,
it's unlikely that we'll change random-number generation entirely.

However, there's much that can be done, even within the constraints of
the frozen interfaces. For instance, there are cases such as that shown
by Dima:

On Thu, 2009-06-18 at 12:16 +0200, Dima wrote:

> But I think a better Idea would be to replace the current
> occurrence of the other classes. This wouldn't be too
> much work, since usually the initialization of the cdf is done
> once, eg.
>
> CumulativeNormalDistribution f; // in the BlackCalculator
>
> Then, f is used throughout the class as a functor. So, if you
> would replace f here with a boost
> class, the merging is straightforward. Running the test_suite
> will show if there's any difference
> to current implementation.

Here, the distribution is not part of the interface, but rather just an
implementation detail---and can be replaced without problems.

In other places, the substitution wouldn't be that straightforward. For
instance, replacing the InverseCumulativeDistribution class in the path
generation would most likely cause an interface change, and is thus out.
However, there's hope for that, too; the Monte Carlo classes are modular
enough that one can replace the path-generator classes entirely and plug
new ones (using boost) in the existing Monte Carlo engines. The new
classes might then replace the old ones in version 2.0, whenever that
is. (Note: even if we found out that our algorithms were more precise,
at that point I'd change them to conform to the boost interface anyway,
since that would be the standard interface.)

Thoughs so far?

Luigi

--

This gubblick contains many nonsklarkish English flutzpahs, but the
overall pluggandisp can be glorked from context.
-- David Moser

------------------------------------------------------------------------------
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev