quantlib-dev — Discussion of QuantLib development

Re: [Quantlib-dev] Subversion glitches

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

On Mon, 2007-04-16 at 11:15 +0200, Ferdinando Ametrano wrote:
> > a) due to non-ASCII characters in a few past commit messages, "svn log"
> > is currently broken.
> how can I see the problem? on which file?

>From the command line, execute "svn log" from within your working copy
of the trunk. Wait, let me see if Tortoise somehow hides the error...
no, it doesn't. With Tortoise, choose "Show Log" on the trunk and check
the "Show all" checkbox. It starts chugging along and it breaks after a
while. You'll still be able to see part of the log, though (as with the
command line.)

> >  Should I also regroup past branches so that all modules in sync for a particular
> > release live in the same directory
> In my opinion I would leave past branches the way the are. Maybe just
> move old breanches in a subfolder, so that we could have a "clean"
> branches (and tags) folder

It seems to me it's already as clean as it can be. Currently, they
contain only branches and tags for past releases, which I'd leave in the
corresponding folders.

> thank you for all this SVN job you are taking care of

No problem.

Later,
	Luigi


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

There are no rules of architecture for a castle in the clouds. 
-- Gilbert K. Chesterton 

Re: [Quantlib-dev] Subversion glitches

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

Hi Luigi

> a) due to non-ASCII characters in a few past commit messages, "svn log"
> is currently broken.
how can I see the problem? on which file?

> I can fix it, but I'll need to take the repository
> down for a day or two. I might be able to do it during the next weekend
> or the one after, which means that you won't be able to commit on those
> Saturday and Sunday. Any objections?
during week-ends it's ok for me

> Starting with next release, Subversion will
> make it more convenient to branch the whole trunk; therefore, the
> branches for all modules would live in the same directory.
I've appreciated that very much as it is my favorite approach.

>  Should I also regroup past branches so that all modules in sync for a particular
> release live in the same directory
In my opinion I would leave past branches the way the are. Maybe just
move old breanches in a subfolder, so that we could have a "clean"
branches (and tags) folder

thank you for all this SVN job you are taking care of

ciao -- Nando

[Quantlib-dev] Subversion glitches

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

Hi all,
	there are still a couple of glitches left after the migration to
Subversion. Here they are:

a) due to non-ASCII characters in a few past commit messages, "svn log"
is currently broken. I can fix it, but I'll need to take the repository
down for a day or two. I might be able to do it during the next weekend
or the one after, which means that you won't be able to commit on those
Saturday and Sunday. Any objections?

b) the migration tool we used preserved the branches and tags we had in
CVS based on their name. This means that, for instance, the latest
releases of QuantLib, QuantLib-SWIG and QuantLibXL all live in
branches/R000400f0-branch while the latest releases of ObjectHandler and
gensrc (which had a different version number) live in
branches/R000200f0-branch.  Starting with next release, Subversion will
make it more convenient to branch the whole trunk; therefore, the
branches for all modules would live in the same directory.  Should I
also regroup past branches so that all modules in sync for a particular
release live in the same directory (which would make it easy to checkout
all related modules at the right versions, but would make it a bit more
difficult to find where any particular ObjectHandler release lives) or
should I leave the repository as it is (which would make it easy to find
any specific release of ObjectHandler, but would make it a bit more
difficult to find what QuantLibXL version it relates to?)  Opinions?

Later,
	Luigi


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

standards, n.: 
The principles we use to reject other people's code. 

[Quantlib-dev] TimeStamp class

[Joseph W. <jo...@gn...>]

I'd like to start producing a timestamp class that will allow storage of time 
stamps for recording high frequency trading data.  What I have in mind would 
be a class

TimeStamp include a Date, hour, minute, second, and a fractional second

and subclasses GmtTimeStamp and LocalTimeStamp.  

Thoughts?  One gotcha is that Time is already defined as continuous real time.

-- 
-------------------------------------------------------------------------------
Joseph Wang Ph.D. - jo...@gn...  
China Derivatives Researcher and Software Developer - QuantLib
http://en.wikiversity.org/wiki/User:Roadrunner

[Quantlib-dev] SVN commit message - technical warning

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

Hi all,
	just a note: when you commit changes, please do not use non-ASCII
characters in the commit messages (such as the ä in Jäckel or,
unfortunately, the ç in François) since they break the 'svn log' command
over the http protocol we use.

Thanks,
	Luigi


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

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

[Quantlib-dev] [ quantlib-Feature Requests-910972 ] Add Greeks to Binomial Vanilla Engine

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

Feature Requests item #910972, was opened at 2004-03-06 23:41
Message generated for change (Comment added) made by steve_affine
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=362740&aid=910972&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
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add Greeks to Binomial Vanilla Engine

Initial Comment:
delta, gamma, theta, vega, rho, etc.  ought to be added 
to the binomial vanilla engine.   many would consider 
this "core" functionality of any serious library.  if i can 
find the time, i will look into it myself as Luigi and others 
have suggested.  phil k. (wr...@ya...)

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

Comment By: steve_affine (steve_affine)
Date: 2007-04-11 17:32

Message:
Logged In: YES 
user_id=1758990
Originator: NO

I have added Delta, Gamma and Theta to the latest release (0.8), as they
can be derived directly from the binomial tree. Other greeks (primarily
Rho, Vega) can only really be derived by running the calculation twice for
slightly different rates/volatilities, but this is trivial to do.

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

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

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10030] trunk/QuantLib

[Klaus S. <kla...@fr...>]

Hi Luigi

It was just convenient for me in one case. No big issue, perform 
rollback...done

cheers 
 Klaus

On Tuesday 10 April 2007 10:58 am, you wrote:
> On Fri, 2007-04-06 at 17:00 -0700, kla...@us...
>
> wrote:
> > Revision: 10030
> >          
> > http://quantlib.svn.sourceforge.net/quantlib/?rev=10030&view=rev Author: 
> >  klausspanderen
> > Date:     2007-04-06 17:00:25 -0700 (Fri, 06 Apr 2007)
> >
> > Log Message:
> > -----------
> > use relinkableHandle for all parameters
> >
> > Modified Paths:
> > --------------
> >     trunk/QuantLib/ql/processes/hestonprocess.cpp
> >     trunk/QuantLib/ql/processes/hestonprocess.hpp
>
> Klaus,
> 	those were Handles on purpose---a Heston process is not supposed to be
> able to relink them, since there might be other processes which depend
> on them. Were there any reason you wanted to be able to do so (in which
> case we'll have to discuss how to do it) or was it just a
> misunderstanding?
>
> Later,
> 	Luigi
>
>
> ----------------------------------------
>
> The box said "Use Windows 95 or better," so I got a Macintosh.

Re: [Quantlib-dev] pseudoSqrt() and rankReducedSqrt()

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

On Apr 10, 2007, at 1:26 PM, Li, Peter wrote:

> Hi,
> Here it is to confirm that the symmetric matrix checking failure has
> been fixed.

Ok, thanks.

Luigi

Re: [Quantlib-dev] pseudoSqrt() and rankReducedSqrt()

[Li, P. <pet...@wa...>]

Hi,=20
Here it is to confirm that the symmetric matrix checking failure has
been fixed.

Thanks.

------------------------------------
Peter Li

-----Original Message-----
From: Luigi Ballabio [mailto:lui...@gm...]=20
Sent: Thursday, March 22, 2007 7:57 AM
To: Li, Peter
Cc: qua...@li...
Subject: Re: [Quantlib-dev] pseudoSqrt() and rankReducedSqrt()

On Thu, 2007-03-15 at 10:36 -0400, Li, Peter wrote:
> in pseudoSqrt.cpp the checking of symmetric matrix may fail due to
> rounding errors in construction of a matrix.=20

Fixed, thanks. Not by me, I must add.

Luigi


----------------------------------------=20

Anyone who says he can see through women is missing a lot.=20
-- Groucho Marx=20

[Quantlib-dev] [ quantlib-Bugs-1697468 ] QuantLib Add-In BermidanSwaptionCalculation

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

Bugs item #1697468, was opened at 2007-04-10 10:19
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112740&aid=1697468&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: goncha (victor_gonzalez)
Assigned to: Nobody/Anonymous (nobody)
Summary: QuantLib Add-In BermidanSwaptionCalculation

Initial Comment:
Using the Add-In I am able to price a European Swaption however I can not price a Bermudan nor an American Swaption.

I am using the following functions:

1) qlBermudanExercise

2) qlSwaption (I created a swap first using qlVanillaSwap) 

3) qlInstrumentNPV

Please see output on attached word document

Many Thanks



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

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

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10030] trunk/QuantLib

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

On Fri, 2007-04-06 at 17:00 -0700, kla...@us...
wrote:
> Revision: 10030
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=10030&view=rev
> Author:   klausspanderen
> Date:     2007-04-06 17:00:25 -0700 (Fri, 06 Apr 2007)
> 
> Log Message:
> -----------
> use relinkableHandle for all parameters
> 
> Modified Paths:
> --------------
>     trunk/QuantLib/ql/processes/hestonprocess.cpp
>     trunk/QuantLib/ql/processes/hestonprocess.hpp

Klaus,
	those were Handles on purpose---a Heston process is not supposed to be
able to relink them, since there might be other processes which depend
on them. Were there any reason you wanted to be able to do so (in which
case we'll have to discuss how to do it) or was it just a
misunderstanding?

Later,
	Luigi


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

The box said "Use Windows 95 or better," so I got a Macintosh. 

Re: [Quantlib-dev] QuantLib 0.4.0 test suite fails

[eric e. <eri...@gm...>]

Piter,

On 4/7/07, Piter Dias <pit...@ma...> wrote:
> Guys,
>
> Today I compiled QuantLib 0.4.0 (so long time since last time...) and I g=
ot
> the following test suite error. Could you please check it?
>
> Regards,
>
>
> Piter Dias
> pit...@ca...
>
> Testing flat-volatility stripping...
> ./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStrippi=
ng":

I added this to the FAQ:
    http://quantlib.org/faq.shtml#Testing%20QuantLib1

Fran=E7ois, your comment on the ticket suggests that you understand the
cause of the bug but gives no indication of a resolution, do you have
one in mind?

Regards,
Eric

[Quantlib-dev] QuantLib 0.4.0 test suite fails

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

Guys,

Today I compiled QuantLib 0.4.0 (so long time since last time...) and I got
the following test suite error. Could you please check it?

Regards,


Piter Dias
pit...@ca...

Testing flat-volatility stripping...
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping":
tenor: 2Y
strike: 2%
volatility=: 0.179978
relativeError=: -0.0120633
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping":
tenor: 2Y
strike: 3%
volatility=: 0.179892
relativeError=: -0.0601433
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping":
tenor: 2Y
strike: 4%
volatility=: 0.179846
relativeError=: -0.0856778
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping":
tenor: 2Y
strike: 5%
volatility=: 0.17987
relativeError=: -0.0723772
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping":
tenor: 2Y
strike: 6%
volatility=: 0.179915
relativeError=: -0.0471077
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping":
tenor: 2Y
strike: 7%
volatility=: 0.179953
relativeError=: -0.0260588
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping":
tenor: 2Y
strike: 8%
volatility=: 0.179981
relativeError=: -0.0106963
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping":
tenor: 3Y
strike: 4%
volatility=: 0.180032
relativeError=: 0.0179383
-------------
./capstripper.cpp(234): error in "CapsStripperTest::FlatVolatilityStripping":
tenor: 3Y
strike: 5%
volatility=: 0.180027
relativeError=: 0.015243
-------------

[Quantlib-dev] Looking for a presentation on QuantLib

[<fre...@gm...>]

Hello,

I have to present QuantLib during a few days to a quant team. They want
to use QuantLib architecture. So i will show them how developing in
QuantLib. I want to tell them the good manners, what not to do, etc.. Is
there a presentation or a short documentation already started? I can try to
improve it and give it back to you after use.

Best regards

Fr=E9d=E9ric Degraeve

Re: [Quantlib-dev] Quantlib on Openmosix

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

On Tue, Apr 03, 2007 at 02:42:15PM -0400, Apollo Wong wrote:
> Does anyone have any experience with running Quantlib on Openmosix
> clusters? I see that the Quantian disk was packaging Quantlib on Knobix
> Openmosix 2.4 implying the Quantlib could benefit from Openmosix
> clustering. I was wondering how? 
> Any comments?

Yup. I always include QuantLib in my Quantian (www.quantian.org)
cd/dvd builds, and this includes autoconfigured openMosix if you boot
the 2.4 kernel.  And I eve use BermudanSwaption (from the QL's
examples) as a test case for OpenMosix as it is moderately involved in
terms of cpu requirements.

So in a nutshell 'it just works' as it uses neither shared memory nor
threads either one of which may conflict with openMosix.

Hope this helps, Dirk

-- 
Hell, there are no rules here - we're trying to accomplish something. 
                                                  -- Thomas A. Edison

Re: [Quantlib-dev] coding style

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

On Thu, 2007-04-05 at 15:59 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> Ok you win me over

It's not a match :)

However, I just checked out a revision of the library prior to your
changes and tried some tests. Full compilation times vary of just a few
seconds (which might well be attributed to my computer checking RSS
feeds during the compilation.) Recompilation times (i.e., time to
recompile the library starting from a fully compiled one and touching
ql/yieldtermstructure.hpp) were about 5% smaller for the new version. So
there is some effect, but nothing very exciting...

Later,
	Luigi


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

feature, n: 
A surprising property of a program. Occasionally documented. 
To call a property a feature sometimes means the author did not 
consider that case, and the program makes an unexpected, though 
not necessarily wrong response. See BUG. "That's not a bug, 
it's a feature!" A bug can be changed to a feature by 
documenting it. 

Re: [Quantlib-dev] coding style

[DU V. DE V. F. G. P. <fra...@ca...>]

>Non necessarily. Let's say we have:

>- a class Foo declared in foo.hpp and implemented in foo.cpp;
>- a class Bar that stores, say, a pointer to Foo. In bar.hpp, we
>  only need a forward declaration of Foo. In bar.cpp (where the
>  Foo object is manipulated) we need to include foo.hpp.
>- a class Baz which takes a pointer to Foo as argument, passes it
>  to a Bar, and stores (and possibly manipulates) the resulting Bar.

>Since Baz is not going to use Foo directly, baz.cpp does not need to
>include its definition---the forward declaration in bar.hpp is
>enough---and can be compiled successfully without including foo.hpp.

Ok you win me over, thanks for this detailled explanation.
Regards,

Fran=E7ois=20

Re: [Quantlib-dev] coding style

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

On Thu, 2007-04-05 at 15:10 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> >Possibly. At the end of the day, the client code must instantiate all
> >needed classes, so it's likely that it includes everything.
> >However, the advantage is in compilation times for the library. On the
> >one hand, the overall time can decrease as each source file might
> >include less headers. On the other hand, and more importantly,
> >incremental compilations are faster since changing a header file might
> >cause less source files to be recompiled.
> 
> Well, since all classes are compiled in the library, they also must
> have access sooner or later to the actual definition of the classes
> they are depends on. 

Non necessarily. Let's say we have:

- a class Foo declared in foo.hpp and implemented in foo.cpp;
- a class Bar that stores, say, a pointer to Foo. In bar.hpp, we
  only need a forward declaration of Foo. In bar.cpp (where the
  Foo object is manipulated) we need to include foo.hpp.
- a class Baz which takes a pointer to Foo as argument, passes it
  to a Bar, and stores (and possibly manipulates) the resulting Bar.

Since Baz is not going to use Foo directly, baz.cpp does not need to
include its definition---the forward declaration in bar.hpp is
enough---and can be compiled successfully without including foo.hpp.


> >> Another one, what about refactoring the QL folders hierarchy since we
> >> are using svn?
> 
> >Sure. Any ideas?
> 
> I would move some existing folders and files as follows
> 
> math:
> 	optimization
> 	randomnumbers
> 	solver1D
> 
> time:(new)
> 	calendars
> 	daycounters
> 	(schedule.*, BDC, weekday, ...)
> 
> methods:(new)
> 	finitedifferences
> 	montecarlo
> 	lattices
> 
> termstructures:
> 	Volatilities
> 
> 
> I would also create the following subfolders:
> math:
> 	integrals
> 	distributions
> 	interpolations
> 
> instruments:
> 	swaps
> 	bonds
> 	options
> 
> termstructures:
> 	yieldCurve
> 	volatilities

yieldcurves, you mean. Plural and lowercase.

About instruments, I'm not so sure. But all the others seem ok to me.
Any other votes, anybody?

Later,
	Luigi


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

The purpose of abstraction is not to be vague, but to create a new 
semantic level in which one can be absolutely precise. 
-- W.E. Dijkstra 

Re: [Quantlib-dev] coding style

[DU V. DE V. F. G. P. <fra...@ca...>]

>Possibly. At the end of the day, the client code must instantiate all
>needed classes, so it's likely that it includes everything.
>However, the advantage is in compilation times for the library. On the
>one hand, the overall time can decrease as each source file might
>include less headers. On the other hand, and more importantly,
>incremental compilations are faster since changing a header file might
>cause less source files to be recompiled.

Well, since all classes are compiled in the library, they also must have =
access sooner or later to the actual definition of the classes they are =
depends on.=20
IMHO the actual improvement (if any) is that it reduces the number of =
redundant inclusions. It should make no difference thanks to include =
guards. However Lakos recommands in his book (Large-Scale C++ Software =
Design) the use of redundant include guards to detect redundant =
inclusion earlier. (It keeps the compiler from parsing header files to =
look for include guards limits.)

>> Another one, what about refactoring the QL folders hierarchy since we
>> are using svn?

>Sure. Any ideas?

I would move some existing folders and files as follows

math:
	optimization
	randomnumbers
	solver1D

time:(new)
	calendars
	daycounters
	(schedule.*, BDC, weekday, ...)

methods:(new)
	finitedifferences
	montecarlo
	lattices

termstructures:
	Volatilities


I would also create the following subfolders:
math:
	integrals
	distributions
	interpolations

instruments:
	swaps
	bonds
	options

termstructures:
	yieldCurve
	volatilities


Fran=E7ois

Re: [Quantlib-dev] coding style

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

On Thu, 2007-04-05 at 12:46 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> You may have noticed that I have done some changes in the inclusions
> yesterday. The goal was to include less header files in the header
> files (to avoid cascading inclusion). To do so I have removed uneeded
> or too general inclusions. I have also used forward declarations and
> now I have doubts about the relevancy this trick. Indeed I have the
> feeling that it simply moves some inclusions to the client code. So
> one way or another compiler will have parsed the same amount of header
> files to compile a client file... Any thoughts? 

Possibly. At the end of the day, the client code must instantiate all
needed classes, so it's likely that it includes everything.
However, the advantage is in compilation times for the library. On the
one hand, the overall time can decrease as each source file might
include less headers. On the other hand, and more importantly,
incremental compilations are faster since changing a header file might
cause less source files to be recompiled.

This said, I'd love to see experimental data on compilation times before
and after the changes...


> Another one, what about refactoring the QL folders hierarchy since we
> are using svn?

Sure. Any ideas?

Luigi


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

Blessed is the man who, having nothing to say, abstains from giving 
wordy evidence of the fact. 
-- George Eliot 

[Quantlib-dev] coding style

[DU V. DE V. F. G. P. <fra...@ca...>]

Hi all,

=20

=20

You may have noticed that I have done some changes in the inclusions =
yesterday. The goal was to include less header files in the header files =
(to avoid cascading inclusion). To do so I have removed uneeded or too =
general inclusions. I have also used forward declarations and now I have =
doubts about the relevancy this trick. Indeed I have the feeling that it =
simply moves some inclusions to the client code. So one way or another =
compiler will have parsed the same amount of header files to compile a =
client file... Any thoughts?=20

Another one, what about refactoring the QL folders hierarchy since we =
are using svn?

Fran=E7ois=20

[Quantlib-dev] R-SWIG QuantLib

[Joseph W. <jo...@gn...>]

There is a implementation of QuantLib which uses SWIG to interface with R.  To 
use this you will need to checkout QuantLib-SWIG and run the latest version 
of swig against the directory marked R.

I've had reports of R swig failing on windows, but I haven't gotten enough 
debug information to track the problem down.
-- 
-------------------------------------------------------------------------------
Joseph Wang Ph.D. - jo...@gn...  
China Derivatives Researcher and Software Developer - QuantLib
http://en.wikiversity.org/wiki/User:Roadrunner

Re: [Quantlib-dev] Greeks for vanilla binomial - implementation

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

On Mon, 2007-04-02 at 00:21 -0700, steve.affine wrote:
> Concerning the FR to add Greeks
> (http://sourceforge.net/tracker/index.php?func=detail&aid=910972&group_id=12740&atid=362740),
> I have looked at this today and implemented most of them.
> 
> My suggestion is to use points on the binomial tree as per Odergaard
> (http://finance-old.bi.no/~bernt/gcc_prog/recipes/recipes.pdf).

Steve,
	looks ok to me. May you send a patch?

Thanks,
	Luigi

P.S. Is the Nabble archive a public one? If so, I'll link it from the
mailing list page on the QuantLib site.


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

Don't let school get in the way of your education. 
-- Mark Twain 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [9971] trunk/QuantLibXL/Workbooks

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

On Tue, 2007-04-03 at 10:42 -0700, na...@us... wrote:
> Revision: 9971
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=9971&view=rev
> Author:   nando
> Date:     2007-04-03 10:42:29 -0700 (Tue, 03 Apr 2007)
> 
> Log Message:
> -----------
> improved design

How was it improved? Just curious :)

Seriously, let's try (me first---please point out when I don't) to be a
bit more informative in commit messages...

Thanks,
	Luigi


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

Harrison's Postulate: 
For every action, there is an equal and opposite criticism. 

[Quantlib-dev] Quantlib on Openmosix

[Apollo W. <aw...@gw...>]

Does anyone have any experience with running Quantlib on Openmosix
clusters? I see that the Quantian disk was packaging Quantlib on Knobix
Openmosix 2.4 implying the Quantlib could benefit from Openmosix
clustering. I was wondering how?=20
Any comments?
Thank s.
Apollo
*************************************************************************=
*********************
This email is being sent to you for your information pursuant to your req=
uest. This information is not warranted=20
as to completeness or accuracy. The views expressed in the message are th=
ose of the individual sender,=20
except where the message states otherwise and the sender is authorized to=
 state them to be the views of=20
George Weiss Associates, Inc. or any of its affiliated entities. This mes=
sage is for the named person's use=20
only. It may contain sensitive and private proprietary or legally privile=
ged information. No confidentiality or=20
privilege is waived or lost by any mistransmission. You must not, directl=
y or indirectly, use, disclose, distribute,=20
print or copy any part of this message if you are not the intended recipi=
ent.
*** eSafe scanned this email for viruses, vandals, and malicious content.=
 ***
*************************************************************************=
*********************