quantlib-dev — Discussion of QuantLib development

[Quantlib-dev] [ quantlib-Bugs-1686600 ] LINK : fatal error LNK1104: cannot open file 'libboost_unit_

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

Bugs item #1686600, was opened at 2007-03-23 02:48
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=1686600&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: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: LINK : fatal error LNK1104: cannot open file 'libboost_unit_

Initial Comment:
Any idea why this link error occurred in the first place.

Thank you

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

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

Re: [Quantlib-dev] long and possibly inifinite observer/observablenotifying loops

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

On Thu, 2007-03-22 at 16:53 +0100, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> Sorry for this wrong analysis I thought that once a LazyObject has
> been updated it doesn't propagate any notification until it has been
> recalculated. 
> Don't you think that this should break any circular chain and solve
> the pb of reconvergency ?

No, it wouldn't work. If it didn't forward the notification, it might
not be asked for recalculation at all (see my previous post.)

Luigi



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

The first rule of intelligent tinkering is to save all the parts. 
-- Paul Erlich 

Re: [Quantlib-dev] solvers in Instruments - why nested classes rather than adapter+binder?

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

On Tue, 2007-03-20 at 10:49 -0700, Chris Kenyon wrote:
> I have a question about use of solvers, e.g. in Instruments & Engines.
> In classes such as CapFloor a nested class in the Instrument is used
> to provide a function to a solver by overloading the  () operator (see
> capfloor.hpp & capfloor.cpp).   However, the same result can be
> achieved by using an ordinary method (no overloading) together with a
> binder and an adapter [...]
> 
> So why go with embedded classes?  What was the rational?

Historical reasons, I guess. In later versions of the library, the
solve() method was not template, and the function object to be passed
had to inherit from a base class. When we changed solve(), we didn't
bother changing the client code since it worked as it was.

Moreover, the inner class is not so bad. It encapsulates nicely a few
accessory object which otherwise should be kept as data members of the
CapFloor class itself. What we could do, however, is to avoid defining
it as an inner class. We could remove it from the header altogether and
define it in an anonymous namespace in the .cpp file. Did you spot any
other such class in the library?

Later,
	Luigi


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

I've finally learned what `upward compatible' means. It means we 
get to keep all our old mistakes. 
-- Dennie van Tassel 

Re: [Quantlib-dev] long and possibly inifinite observer/observablenotifying loops

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

Hi Luigi,

Sorry for this wrong analysis I thought that once a LazyObject has been =
updated it doesn't propagate any notification until it has been =
recalculated.=20
Don't you think that this should break any circular chain and solve the =
pb of reconvergency ? As for our setting I must confess that we are =
creating many objects and it is not impossible that the dependencies =
between them have some flaws.
Rgds

Fran=E7ois


-----Original Message-----
From: Luigi Ballabio [mailto:lui...@gm...]=20
Sent: gioved=EC 22 marzo 2007 16.40
To: DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
Cc: qua...@li...
Subject: Re: [Quantlib-dev] long and possibly inifinite =
observer/observablenotifying loops


Hi Francois,

On Thu, 2007-03-22 at 13:04 +0100, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> I have found that in some cases we can have some huge (possibly
> infinite) observer/observable notifying chains. (ie: one call to the
> notifyObservers method trigger millions of calls to notifyObservers).
> This obviously occurs when we create a circular observer/observable
> chain and no lazyObject is included in.

True. LazyObject doesn't help, either (see below.) But if you have such
a cycle, there's something wrong in the way you built your objects.

>  But it also occurs in the case of a reconvergent chaining ( ie: a set
> of objects are both observing the same object and are all observed by
> another one) which multiply the number of notifying calls.

Yes, but this can hardly trigger millions of calls. A chain like the one
you described triggers N calls where N is the dimension of the set. To
get quadratic behavior or worse, you'd need two or more recombining
chains in sequence. What kind of setup do you have?

> IMHO we should make more objects inherit from LazyObject (even if they
> are not computing anything actually) taking some extra care about what
> we expose in the base classes. Indeed it might happen that some
> LazyObjects might not act as LazyObjects. Indeed these objects
> (PiecewiseYieldCurve for instance) are bypassing the LazyOject
> behavior by call the notifyObservers method directly. (see update()
> method of PiecewiseYieldCurve).=20

LazyObject has nothing to do with it. Laziness causes it to postpone
calculations, but observers have to be notified immediately. If this
were not so, recalculation might never happen. Let's imagine that a lazy
object receives a notification from an observable. If the lazy object
waited to notify its observers until they ask for calculation, the
observers would not know that something is changed; therefore, they
would not ask the lazy object for an updated value, and the lazy object
still wouldn't notify them. In short, the notification would be lost.

Thus, notification cannot be lazy. And in fact, PiecewiseYieldCurve does
not bypass the behavior of LazyObject; the call to notifyObservers() is
inside LazyObject::update() itself. Although a problem might be that
PiecewiseYieldCurve calls the update() methods of both its base classes,
and therefore ends up calling notifyObservers() twice.

Later,
	Luigi



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

No, I'm not interested in developing a powerful brain. All I'm after=20
is just a mediocre brain, something like the president of American=20
Telephone and Telegraph Company.=20
-- Alan Turing on the possibilities of a thinking machine, 1943.=20

Re: [Quantlib-dev] long and possibly inifinite observer/observable notifying loops

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

Hi Francois,

On Thu, 2007-03-22 at 13:04 +0100, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> I have found that in some cases we can have some huge (possibly
> infinite) observer/observable notifying chains. (ie: one call to the
> notifyObservers method trigger millions of calls to notifyObservers).
> This obviously occurs when we create a circular observer/observable
> chain and no lazyObject is included in.

True. LazyObject doesn't help, either (see below.) But if you have such
a cycle, there's something wrong in the way you built your objects.

>  But it also occurs in the case of a reconvergent chaining ( ie: a set
> of objects are both observing the same object and are all observed by
> another one) which multiply the number of notifying calls.

Yes, but this can hardly trigger millions of calls. A chain like the one
you described triggers N calls where N is the dimension of the set. To
get quadratic behavior or worse, you'd need two or more recombining
chains in sequence. What kind of setup do you have?

> IMHO we should make more objects inherit from LazyObject (even if they
> are not computing anything actually) taking some extra care about what
> we expose in the base classes. Indeed it might happen that some
> LazyObjects might not act as LazyObjects. Indeed these objects
> (PiecewiseYieldCurve for instance) are bypassing the LazyOject
> behavior by call the notifyObservers method directly. (see update()
> method of PiecewiseYieldCurve). 

LazyObject has nothing to do with it. Laziness causes it to postpone
calculations, but observers have to be notified immediately. If this
were not so, recalculation might never happen. Let's imagine that a lazy
object receives a notification from an observable. If the lazy object
waited to notify its observers until they ask for calculation, the
observers would not know that something is changed; therefore, they
would not ask the lazy object for an updated value, and the lazy object
still wouldn't notify them. In short, the notification would be lost.

Thus, notification cannot be lazy. And in fact, PiecewiseYieldCurve does
not bypass the behavior of LazyObject; the call to notifyObservers() is
inside LazyObject::update() itself. Although a problem might be that
PiecewiseYieldCurve calls the update() methods of both its base classes,
and therefore ends up calling notifyObservers() twice.

Later,
	Luigi



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

No, I'm not interested in developing a powerful brain. All I'm after 
is just a mediocre brain, something like the president of American 
Telephone and Telegraph Company. 
-- Alan Turing on the possibilities of a thinking machine, 1943. 

[Quantlib-dev] long and possibly inifinite observer/observable notifying loops

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

CXN0ZDo6bGlzdDxRdWFudExpYjo6T2JzZXJ2ZXIgKixzdGQ6OmFsbG9jYXRvcjxRdWFudExpYjo6
T2JzZXJ2ZXIgKj4gPjo6YmVnaW4oKSBMaW5lIDUyOAlDKysNCiAJUXVhbnRMaWI6Ok9ic2VydmFi
bGU6Om5vdGlmeU9ic2VydmVycygpIExpbmUgMTE2CUMrKw0KIAlRdWFudExpYjo6Q2FwcGVkRmxv
b3JlZENvdXBvbjo6dXBkYXRlKCkgTGluZSAxMTYJQysrDQogCVF1YW50TGliOjpPYnNlcnZhYmxl
Ojpub3RpZnlPYnNlcnZlcnMoKSBMaW5lIDExOAlDKysNCiAJUXVhbnRMaWI6OkZsb2F0aW5nUmF0
ZUNvdXBvbjo6dXBkYXRlKCkgTGluZSAxMzAJQysrDQogCVF1YW50TGliOjpPYnNlcnZhYmxlOjpu
b3RpZnlPYnNlcnZlcnMoKSBMaW5lIDExOAlDKysNCiAJUXVhbnRMaWI6OkZsb2F0aW5nUmF0ZUNv
dXBvblByaWNlcjo6dXBkYXRlKCkgTGluZSA1OQlDKysNCiAJUXVhbnRMaWI6Ok9ic2VydmFibGU6
Om5vdGlmeU9ic2VydmVycygpIExpbmUgMTE4CUMrKw0KIAlRdWFudExpYjo6SGFuZGxlPFF1YW50
TGliOjpDYXBsZXRWb2xhdGlsaXR5U3RydWN0dXJlPjo6TGluazo6dXBkYXRlKCkgTGluZSA1MQlD
KysNCiAJUXVhbnRMaWI6Ok9ic2VydmFibGU6Om5vdGlmeU9ic2VydmVycygpIExpbmUgMTE4CUMr
Kw0KIAlRdWFudExpYjo6VGVybVN0cnVjdHVyZTo6dXBkYXRlKCkgTGluZSAxNTQJQysrDQogCVF1
YW50TGliOjpDYXBzU3RyaXBwZXI6OnVwZGF0ZSgpIExpbmUgNjYJQysrDQogCVF1YW50TGliOjpP
YnNlcnZhYmxlOjpub3RpZnlPYnNlcnZlcnMoKSBMaW5lIDExOAlDKysNCiAJUXVhbnRMaWI6Okxh
enlPYmplY3Q6OnVwZGF0ZSgpIExpbmUgMTA3CUMrKw0KIAlRdWFudExpYjo6T2JzZXJ2YWJsZTo6
bm90aWZ5T2JzZXJ2ZXJzKCkgTGluZSAxMTgJQysrDQogCVF1YW50TGliOjpGbG9hdGluZ1JhdGVD
b3Vwb246OnVwZGF0ZSgpIExpbmUgMTMwCUMrKw0KIAlRdWFudExpYjo6T2JzZXJ2YWJsZTo6bm90
aWZ5T2JzZXJ2ZXJzKCkgTGluZSAxMTgJQysrDQogCVF1YW50TGliOjpJbnRlcmVzdFJhdGVJbmRl
eDo6dXBkYXRlKCkgTGluZSA5OQlDKysNCiAJUXVhbnRMaWI6Ok9ic2VydmFibGU6Om5vdGlmeU9i
c2VydmVycygpIExpbmUgMTE4CUMrKw0KIAlRdWFudExpYjo6SGFuZGxlPFF1YW50TGliOjpZaWVs
ZFRlcm1TdHJ1Y3R1cmU+OjpMaW5rOjp1cGRhdGUoKSBMaW5lIDUxCUMrKw0KIAlRdWFudExpYjo6
T2JzZXJ2YWJsZTo6bm90aWZ5T2JzZXJ2ZXJzKCkgTGluZSAxMTgJQysrDQogCVF1YW50TGliOjpM
YXp5T2JqZWN0Ojp1cGRhdGUoKSBMaW5lIDEwNwlDKysNCiAJUXVhbnRMaWI6OlBpZWNld2lzZVlp
ZWxkQ3VydmU8UXVhbnRMaWI6Olplcm9ZaWVsZCxRdWFudExpYjo6TGluZWFyPjo6dXBkYXRlKCkg
TGluZSAyMTkJQysrDQogCVF1YW50TGliOjpPYnNlcnZhYmxlOjpub3RpZnlPYnNlcnZlcnMoKSBM
aW5lIDExOAlDKysNCiAJUXVhbnRMaWI6OlJhdGVIZWxwZXI6OnVwZGF0ZSgpIExpbmUgODYJQysr
DQogCVF1YW50TGliOjpSZWxhdGl2ZURhdGVSYXRlSGVscGVyOjp1cGRhdGUoKSBMaW5lIDEyNwlD
KysNCiAJUXVhbnRMaWI6Ok9ic2VydmFibGU6Om5vdGlmeU9ic2VydmVycygpIExpbmUgMTE4CUMr
Kw0KIAlRdWFudExpYjo6SW50ZXJlc3RSYXRlSW5kZXg6OnVwZGF0ZSgpIExpbmUgOTkJQysrDQog
CVF1YW50TGliOjpPYnNlcnZhYmxlOjpub3RpZnlPYnNlcnZlcnMoKSBMaW5lIDExOAlDKysNCiAJ
UXVhbnRMaWI6Ok9ic2VydmFibGVWYWx1ZTxRdWFudExpYjo6VGltZVNlcmllczxkb3VibGUsc3Rk
OjptYXA8UXVhbnRMaWI6OkRhdGUsZG91YmxlLHN0ZDo6bGVzczxRdWFudExpYjo6RGF0ZT4sc3Rk
OjphbGxvY2F0b3I8c3RkOjpwYWlyPFF1YW50TGliOjpEYXRlIGNvbnN0ICxkb3VibGU+ID4gPiA+
ID46Om9wZXJhdG9yPShjb25zdCBRdWFudExpYjo6VGltZVNlcmllczxkb3VibGUsc3RkOjptYXA8
UXVhbnRMaWI6OkRhdGUsZG91YmxlLHN0ZDo6bGVzczxRdWFudExpYjo6RGF0ZT4sc3RkOjphbGxv
Y2F0b3I8c3RkOjpwYWlyPFF1YW50TGliOjpEYXRlIGNvbnN0ICxkb3VibGU+ID4gPiA+ICYgdD17
Li4ufSkgTGluZSA4NAlDKysNCiAJUXVhbnRMaWI6OkluZGV4TWFuYWdlcjo6c2V0SGlzdG9yeShj
b25zdCBzdGQ6OmJhc2ljX3N0cmluZzxjaGFyLHN0ZDo6Y2hhcl90cmFpdHM8Y2hhcj4sc3RkOjph
bGxvY2F0b3I8Y2hhcj4gPiAmIG5hbWU9IkV1cmlib3I2TSBBY3R1YWwvMzYwIiwgY29uc3QgUXVh
bnRMaWI6OlRpbWVTZXJpZXM8ZG91YmxlLHN0ZDo6bWFwPFF1YW50TGliOjpEYXRlLGRvdWJsZSxz
dGQ6Omxlc3M8UXVhbnRMaWI6OkRhdGU+LHN0ZDo6YWxsb2NhdG9yPHN0ZDo6cGFpcjxRdWFudExp
Yjo6RGF0ZSBjb25zdCAsZG91YmxlPiA+ID4gPiAmIGhpc3Rvcnk9ey4uLn0pIExpbmUgMzkJQysr
DQogCVF1YW50TGliOjpJbmRleDo6YWRkRml4aW5nczxzdGQ6Ol9WZWN0b3JfaXRlcmF0b3I8UXVh
bnRMaWI6OkRhdGUsc3RkOjphbGxvY2F0b3I8UXVhbnRMaWI6OkRhdGU+ID4sc3RkOjpfVmVjdG9y
X2l0ZXJhdG9yPGRvdWJsZSxzdGQ6OmFsbG9jYXRvcjxkb3VibGU+ID4gPihzdGQ6Ol9WZWN0b3Jf
aXRlcmF0b3I8UXVhbnRMaWI6OkRhdGUsc3RkOjphbGxvY2F0b3I8UXVhbnRMaWI6OkRhdGU+ID4g
ZEJlZ2luPXtzZXJpYWxOdW1iZXJfPS0zMzY4NjAxOSB9LCBzdGQ6Ol9WZWN0b3JfaXRlcmF0b3I8
UXVhbnRMaWI6OkRhdGUsc3RkOjphbGxvY2F0b3I8UXVhbnRMaWI6OkRhdGU+ID4gZEVuZD17c2Vy
aWFsTnVtYmVyXz0tMzM2ODYwMTkgfSwgc3RkOjpfVmVjdG9yX2l0ZXJhdG9yPGRvdWJsZSxzdGQ6
OmFsbG9jYXRvcjxkb3VibGU+ID4gdkJlZ2luPTIuMzU0MDcyNDE2MjUzMDE3NGUtMjg0KSBMaW5l
IDc3CUMrKw0KIAlxbEluZGV4QWRkRml4aW5ncyhjaGFyICogb2JqZWN0SUQ9MHgwMmYyYWVmMSwg
eGxvcGVyICogZml4aW5nRGF0ZXM9MHgwMmYyZGY3OCwgeGxvcGVyICogZml4aW5nVmFsdWVzPTB4
MDJmMmVmYjgsIHhsb3BlciAqIHRyaWdnZXI9MHgwMmYyYmUzOCkgTGluZSAzODgJQysrDQo=

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

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

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. 

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

Luigi


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

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

Re: [Quantlib-dev] [QuantLib-cvs] QuantLib/ql period.hpp,1.9,1.10

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

On Wednesday 21 March 2007 12:15:08 Luigi Ballabio wrote:
> I think one might still have problems if QL_INTEGER is redefined to
> long. In the end, I just tried putting in a template version. Let me
> know if it works.

Neat!!!!  Works fine!!!  Let me go through the rest of the code to see if 
there are any types that should be template functions.

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

Re: [Quantlib-dev] [QuantLib-cvs] QuantLib/ql period.hpp,1.9,1.10

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

On Wed, 2007-03-14 at 19:09 -0500, Joseph Wang wrote:
> I have a proposed fix that includes the Period declaration for Natural, but 
> takes out the one for Size (which doesn't make any sense anyway).  Since we 
> now have both a signed and unsigned QL_INTEGER declaration, this should 
> compile on anything.

I think one might still have problems if QL_INTEGER is redefined to
long. In the end, I just tried putting in a template version. Let me
know if it works.

Luigi


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

There is no opinion so absurd that some philosopher will not 
express it. 
-- Marcus Tullius Cicero, "Ad familiares" 

Re: [Quantlib-dev] Quantlib

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

On Tue, 2007-03-20 at 18:24 +1100, Ibrahim ElFayoumi wrote:
> I am trying to write a wrapper around quantlib to do various simple
> things. I wanted to be able to use black school formulae to calculate
> the call Primium at a given date given the various Required values,
> like underlying, strike, volatility and rate…
> 
> Why I get zero at the end?
> 
>                 Date settlementDate = todaysDate + (int) DaysToMature;
> 
>                 Date maturity = todaysDate + (int) DaysToMature;

The settlement date is the date to which the option value is discounted
to get its NPV---depending on where you are based, it might be today's
date or a couple of days from today. Setting it to be the same as the
maturity is probably causing the option to be seen as expired.

Luigi


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

All parts should go together without forcing. You must remember that 
the parts you are reassembling were disassembled by you. Therefore, if 
you can't get them together again, there must be a reason. By all 
means, do not use a hammer. 
-- IBM maintenance manual, 1925 

[Quantlib-dev] solvers in Instruments - why nested classes rather than adapter+binder?

[Chris K. <chr...@ya...>]

Hi,

I have a question about use of solvers, e.g. in Instruments & Engines.  In classes such as CapFloor a nested class in the Instrument is used to provide a function to a solver by overloading the  () operator (see capfloor.hpp & capfloor.cpp).   However, the same result can be achieved by using an ordinary method (no overloading) together with a binder and an adapter (see 18.4.4 of C++ 3rd edition), plus a bit of boost, e.g.:

----------------------------------------
#include "boost/function.hpp"
#include <functional>

boost::function1<Real, Real> f;
f = std::bind1st( std::mem_fun( &className::methodName ),  &(*this) );
Brent solver;    
Real resultX = solver.solve(f, accuracy, guess, minX, maxX);
----------------------------------------

No changes are required in the solver code.  (Of course you need to set up methodName to return the difference between the targetValue and the value generated by the method call.)  This seems to avoid a lot of the overhead of creating a nested class at the cost of using a potentially obscure (but supported) piece of C++ generics, plus boost which is already used.

So why go with embedded classes?  What was the rational?

Very curiously,

CMK

p.s. another potentially cleaner alternative, local classes, is not supported by most compilers.

Re: [Quantlib-dev] Subversion

[Alan K. <ki...@us...>]

<br><font size=2 face="sans-serif">COIN-OR ported from cvs to svn recently.
&nbsp;I think the port went smoothly. &nbsp;It seems to be a worthwhile
change, with one caveat.</font>
<br>
<br><font size=2 face="sans-serif">There is a new concept in svn called
&quot;properties&quot;. &nbsp;It can be difficult to understand and manage,
IMHO. &nbsp;(I've been bitten a few times.) &nbsp;Properties are &quot;ant-like&quot;,
so like ant, once set they are not overwritten. &nbsp;Anytime you feel
like an update didn't take effect then you suspect a properties problem.
&nbsp;The issue arises when you don't get that feeling, updates did take
effect, and have created bugs you can't detect until you update your properties
:-(. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">Properties are used for project dependencies,
among other things. &nbsp;This means that with svn it is even more important
to perform a &quot;new user download and build&quot; test. &nbsp;Your properties
settings might block you from seeing a bug in the default dependencies.</font>
<br>
<br><font size=2 face="sans-serif">COIN-OR has some project manager info
and tips on https://projects.coin-or.org/BuildTools/wiki/pm-main</font>
<br>
<br><font size=2 face="sans-serif">Alan</font>
<br><font size=2 face="sans-serif"><br>
Alan King<br>
Math Sciences<br>
IBM Thomas J Watson Research Center<br>
914-945-1236<br>
http://www.research.ibm.com/people/k/kingaj/</font>
<br>
<br>
<br>
<table width=100%>
<tr valign=top>
<td width=40%><font size=1 face="sans-serif"><b>Luigi Ballabio &lt;lui...@gm...&gt;</b>
</font>
<br><font size=1 face="sans-serif">Sent by: qua...@li...</font>
<p><font size=1 face="sans-serif">03/20/2007 07:48 AM</font>
<td width=59%>
<table width=100%>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">To</font></div>
<td><font size=1 face="sans-serif">QuantLib developers &lt;qua...@li...&gt;</font>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">cc</font></div>
<td>
<tr valign=top>
<td>
<div align=right><font size=1 face="sans-serif">Subject</font></div>
<td><font size=1 face="sans-serif">[Quantlib-dev] Subversion</font></table>
<br>
<table>
<tr valign=top>
<td>
<td></table>
<br></table>
<br>
<br>
<br><tt><font size=2><br>
Hi all,<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
we're thinking of moving the QuantLib repository from CVS to Subversion<br>
shortly. Thoughts anyone? Words of warning?<br>
<br>
Thanks,<br>
 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;
Luigi<br>
<br>
<br>
---------------------------------------- <br>
<br>
Olmstead's Law: <br>
After all is said and done, a hell of a lot more is said <br>
than done. <br>
<br>
<br>
<br>
-------------------------------------------------------------------------<br>
Take Surveys. Earn Cash. Influence the Future of IT<br>
Join SourceForge.net's Techsay panel and you'll get the chance to share
your<br>
opinions on IT &amp; business topics through brief surveys-and earn cash<br>
http://www.techsay.com/default.php?page=join.php&amp;p=sourceforge&amp;CID=DEVDEV<br>
_______________________________________________<br>
QuantLib-dev mailing list<br>
Qua...@li...<br>
https://lists.sourceforge.net/lists/listinfo/quantlib-dev<br>
</font></tt>
<br>

[Quantlib-dev] Subversion

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

Hi all,
	we're thinking of moving the QuantLib repository from CVS to Subversion
shortly. Thoughts anyone? Words of warning?

Thanks,
	Luigi


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

Olmstead's Law: 
After all is said and done, a hell of a lot more is said 
than done. 

[Quantlib-dev] Quantlib

[Ibrahim E. <Ibr...@au...>]

Hello

I am trying to write a wrapper around quantlib to do various simple
things. I wanted to be able to use black school formulae to calculate
the call Primium at a given date given the various Required values, like
underlying, strike, volatility and rate...

Why I get zero at the end?

=20

=20

#include "QuantlibWrapper.h"

=20

// the only header you need to use QuantLib

#define BOOST_LIB_DIAGNOSTIC

#  include <ql/quantlib.hpp>

#undef BOOST_LIB_DIAGNOSTIC

=20

#ifdef BOOST_MSVC

/* Uncomment the following lines to unmask floating-point

   exceptions. Warning: unpredictable results can arise...

=20

   See http://www.wilmott.com/messageview.cfm?catid=3D10&threadid=3D9481

   Is there anyone with a definitive word about this?

*/

// #include <float.h>

// namespace { unsigned int u =3D _controlfp(_EM_INEXACT, _MCW_EM); }

#endif

=20

#include <boost/timer.hpp>

#include <iostream>

#include <iomanip>

=20

using namespace QuantLib;

=20

#if defined(QL_ENABLE_SESSIONS)

namespace QuantLib {

=20

    Integer sessionId() { return 0; }

=20

}

#endif

=20

=20

double QuantlibWrapper::BlackScholesCall(double underlying, double
strike, double volatility, double riskFreeRate, double DaysToMature)

{

        double ret =3D 0;

=20

        try

        {

                QL_IO_INIT

=20

                boost::timer timer;

                std::cout << std::endl;

=20

                // our options

                Option::Type type(Option::Call);

                Spread dividendYield =3D 0.00;

=20

=20

                Date todaysDate =3D Date::todaysDate();

                Date settlementDate =3D todaysDate + (int) DaysToMature;

                Settings::instance().evaluationDate() =3D todaysDate;

=20

                Date maturity =3D todaysDate + (int) DaysToMature;

                DayCounter dayCounter =3D Actual365Fixed();

=20

=20

                std::string method;

=20

                std::vector<Date> exerciseDates;

                exerciseDates.push_back(settlementDate);

=20

                boost::shared_ptr<Exercise> europeanExercise(

                        new EuropeanExercise(maturity));

=20

                Handle<Quote> underlyingH(

                        boost::shared_ptr<Quote>(new
SimpleQuote(underlying)));

=20

                // bootstrap the yield/dividend/vol curves

                Handle<YieldTermStructure> flatTermStructure(

                        boost::shared_ptr<YieldTermStructure>(

                        new FlatForward(settlementDate, riskFreeRate,
dayCounter)));

                Handle<YieldTermStructure> flatDividendTS(

                        boost::shared_ptr<YieldTermStructure>(

                        new FlatForward(settlementDate, dividendYield,
dayCounter)));

                Handle<BlackVolTermStructure> flatVolTS(

                        boost::shared_ptr<BlackVolTermStructure>(

                        new BlackConstantVol(settlementDate, volatility,
dayCounter)));

=20

                boost::shared_ptr<StrikedTypePayoff> payoff(

                        new PlainVanillaPayoff(type, strike));

=20

                boost::shared_ptr<StochasticProcess> stochasticProcess(

                        new BlackScholesMertonProcess(underlyingH,
flatDividendTS,

                        flatTermStructure, flatVolTS));

=20

                // options

=20

                VanillaOption europeanOption(stochasticProcess, payoff,

                        europeanExercise);

=20

                // Analytic formulas:

=20

                // Black-Scholes for European

                method =3D "Black-Scholes";

=20
europeanOption.setPricingEngine(boost::shared_ptr<PricingEngine>(

                        new AnalyticEuropeanEngine));

                ret =3D europeanOption.NPV();

        }

        catch (std::exception& e)

        {

        std::cout << e.what() << std::endl;

        return 1;

    }

        catch (...)

        {

        std::cout << "unknown error" << std::endl;

        return 1;

    }

=20

        return ret;

}

=20

=20

I get zero for any pricing I use..=20

Can you please help how to use Quantlib?

Please send reply to : elf...@gm...

Regards

Ibrahim

=20




This e-mail and any files transmitted with it are confidential and are =
only for the use of the person to whom they are addressed.  If you are =
not the intended recipient, you are hereby notified that any use, =
dissemination, forwarding, printing, copying or dealing in any way =
whatsoever with this e-mail is strictly prohibited.  If you have =
received this e-mail in error, please reply to us immediately and delete =
the document.  It is the recipient's duty to virus-scan and otherwise =
test the enclosed information before using the information or loading =
attached files onto any computer system.  Australian Investment Exchange =
Ltd does not warrant that the information contained in this e-mail is =
free from viruses, defects, errors, interception or interference.  =
Australian Investment Exchange Ltd, and each of its related companies =
each reserve the right to monitor all e-mail communications through its =
networks.  Any views expressed in this message are those of the =
individual sender, except where that sender specifically states them to =
be the views of Australian Investment Exchange Ltd.  Your private =
information is only used and disclosed for the intention which you have =
provided it for.  This information is not disclosed or used unless your =
consent has been provided or in the case that Australian Investment =
Exchange Ltd is permitted to do so under the Privacy Act of 1988.

Re: [Quantlib-dev] Plans for future releases and callfor contributions

[Toyin A. <toy...@ho...>]

Hi all,

I've looked at GSL in the past and it's quite an impressive library.

The only problem with it is that you cannot use it within a commercial 
application... unless that rule has changed recently.

Toy out.

>From: Alan King <ki...@us...>
>To: "QuantLib developers" <qua...@li...>
>Subject: Re: [Quantlib-dev] Plans for future releases and 
>callfor	contributions
>Date: Mon, 19 Mar 2007 10:43:51 -0400
>
>
>
>I would like to point to an alternative
>that was adopted and actively supported by COIN-OR 
>(http://www.coin-or.org/),
>an open source community that I contribute to.
>
>
>
>COIN-OR promotes the Open Solver Interface.
> OSI is a specification for an optimization solver interface.  It
>consists of an abstract class and a dozen or so implementations that were
>submitted and are (more or less actively) supported by various commercial
>vendors and open source developers.  COIN-OR projects use OSI as a
>bridge pattern.
>
>
>
>This suggest three possibilities for
>solver objects that QL depends on:
>
>
>
>1) For solvers that have significant
>open source activity and have bridge implementations (like COIN-OR) then
>it seems like QuantLib could investigate and see if adopting this would
>work for them.  
>
>
>
>2) For solvers that have a significant
>open source activity but no bridge implementation, QL could recommend to
>those projects that they adopt something like an OSI.
>
>
>
>3) For solvers for which QL is really
>the only open source provider, QL could provide an OSI specification and
>an implementation of the QL OSI.
>
>
>
>Alan King
>
>http://www.research.ibm.com/people/k/kingaj/
>
>
>
>qua...@li... wrote on
>03/19/2007 07:50:15 AM:
>
>
>
> > Welcome overview, many thanks.
>
> >
>
> > My epsilon contribution (as anticipated sometime else), is the
>
> > following:
>
> >
>
> > QuantLib was born largely on the (welcome and foresighting) idea to
>NOT
>
> > "re-invent the wheel every time". But, on the long run,
>this goal has
>
> > been partially weakened. In fact, today in quantlib one can find the
>
> > 1001th implementation of standard non-pretty-financial algorithms
>(e.g.
>
> > optimizers, random numbers, etc.).
>
> >
>
> > This stuff is already available from other dedicated open-source
>
> > projects (GSL, for instance). Recoding it exposes the QL community
>to
>
> > the risk of reintroducing bugs, inefficiencies and all the (non)subtle
>
> > problems already encountered - and solved - by the scientific community
>
> > in the last 50 years of computing... Not a good idea, right? :-)
>
> >
>
> > So, what to do? Here some alternatives:
>
> >
>
> > A) coherently, take the wheel reinvention to its natural end: all
>the
>
> > standard non-pretty-financial algorithms should be enumerated, tested
>
> > *in any financial realistic case* with a dedicated testsuite, in
>
> > particular against other more standard implementations.
>
> > I confess I don't know how much of this work has already ben done
>in the
>
> > past, but I feel it is a lot of (unwanted) work (optimizers, for
>
> > instance, should be considered with suspect, at the moment).
>
> >
>
> > B) include the "standard non-pretty-financial algorithms"
>from other,
>
> > trusted open-source projects.
>
> >
>
> > Obviously the second solution:
>
> > B1) simply moves the problem away from QuantLib, but this is not bad
>:-)
>
> > B2) force us to include other libraries into the QL distribution,
>
> > increasing the dependence of the project onto other pieces and
>
> > complicating the installation/building procedure; but QL is already
>
> > integrated with other pieces (boost and log4cxx, for instance), so
>we
>
> > should know how to deal with the n+1th piece;
>
> > B3) leaves open the choice of what other "trusted open-source
>projects"
>
> > consider, which could be not easy;
>
> >
>
> > To conclude, solution B is my favourite, provided the set B3 is
>
> > non-empty :-)
>
> >
>
> > Unfortunately, my knowledge of other "trusted open-source projects"
>
> > being not large enough to provide a closed solution.
>
> > My only feeling is that GSL looks to be a good candidate: it provides
>a
>
> > wide range of mathematical routines "with an extensive test suite";
>it's
>
> > well-known and commonly used in scientific research, the last 1.9
>
> > version was released on 21 February 2007 and it is claimed to be stable
>
> > (see http://www.gnu.org/software/gsl/). I was told that there is a
>
> > problem with the GNU General Public License, but maybe it can be
>
> > overcome, being the library distributed with London's book. It's written
>
> > in C, not object-oriented, and somewhat old-style, but elegance is
>
> > secondary to correct results and computing speed, in my opinion.
>
> >
>
> > I stop here, at this point I don't want to focus the discussion on
>GSL
>
> > in particular, but only to points A+B before, and arguments are heavy
>
> > enough for a discussion. I suspect the latter has been already done
>
> > sometime in the past, but I decided to post this contribution in any
>
> > case, in the hope that an update could be useful.
>
> >
>
> > Thank you for reading up to here, any comment is welcome.
>
> >
>
> > Ciao
>
> > Marco
>
> >
>
> > > -----Original Message-----
>
> > > From: qua...@li...
>
> > > [mailto:qua...@li...] On Behalf
>
>
> > > Of Luigi Ballabio
>
> > > Sent: 16 March 2007 15:28
>
> > > To: QuantLib developers
>
> > > Subject: [Quantlib-dev] Plans for future releases and call
>
> > > for contributions
>
> > >
>
> > >
>
> > >
>
> > > Hi all,
>
> > >     first of all, I'd like to say thanks to everybody
>who helped us
>
> > > releasing QuantLib 0.4.0 (as well as all previous releases) by
>
> > > contributing code, bug reports, comments---you name it. It's
>been a
>
> > > great six years.
>
> > >
>
> > > This year, we're planning to finally take the next step and release
>
> > > QuantLib 1.0.  I'll draft a plan and ask for specific contributions
>
> > > later in this post; but before that, please let me share a
>
> > > few thoughts.
>
> > >
>
> > > Lately I started to have the feeling that our development model
>has
>
> > > reached its limit. Until now, development of the library has
>
>
> > > been pushed
>
> > > forwards by a few dedicated individuals and by occasional
>
> > > contributions
>
> > > by other people. However, there's only so much that this can
>
>
> > > achieve; as
>
> > > witnessed, to name a couple of examples, by the lack of user
>
> > > documentation and my systematic delay in answering posts to
>
> > > the mailing
>
> > > lists.
>
> > >
>
> > > In short, we need to foster a community. We didn't give much
>effort to
>
> > > this so far; actually, I'm afraid we (the core developers) might
>have
>
> > > scared potential contributors away. Until now, we have had a
>somewhat
>
> > > cavalier attitude---when we wanted to do something, we just opened
>our
>
> > > editors and IDEs and started hacking. (Me? Guilty as charged.)
>
> > > Unfortunately, this might give the impression that the library
>is our
>
> > > playground and discourage people from entering our supposedly
>closed
>
> > > club.
>
> > >
>
> > > This will have to change. I'll try and bounce ideas on the developer
>
> > > mailing list before any major change. Of course, I also encourage
>the
>
> > > other developers to do the same---kudos to those that already
>do. In
>
> > > short, I'll do my best so that the library is owned (and felt
>as such)
>
> > > by the whole community gravitating around the mailing lists.
>
> > >
>
> > > Enough---and onwards to the plan for release 1.0.
>
> > >
>
> > > My idea (open to discussion, of course) was to get to 1.0 in
>two or
>
> > > three releases. The ones before 1.0 will give us a chance to
>make
>
> > > changes we've intended to do for quite a while, but that could
>not be
>
> > > done easily in a backward-compatible way. Some of them were made
>
> > > already.
>
> > >
>
> > > The next step would be QuantLib 1.0. In fact, the release before
>that
>
> > > one (0.9.0?) would almost be a beta release of 1.0. I wouldn't
>change
>
> > > much between the two; instead, I would focus on improving
>
> > > documentation
>
> > > and general usability (a task which should already start for
>the
>
> > > upcoming releases.)
>
> > >
>
> > > Needless to say, all such releases (as well as future ones) will
>need
>
> > > your contribution. You don't need to do anything exceptional;
>each of
>
> > > you can help by giving as little time and effort you can
>
> > > afford or want
>
> > > to spare.
>
> > >
>
> > > The easiest way to contribute would be to subscribe to the
>
> > > QuantLib-dev
>
> > > mailing list (the subscription page can be found at
>
> > > <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>.)
>
>
> > > As I said,
>
> > > we'll try and discuss future developments there. Your contribution
>to
>
> > > the discussions, even if only an occasional one, will be useful.
>
> > >
>
> > > If you think you can get more involved, there's a number of
>
> > > other things
>
> > > you can do - apart from contributing code or patches to the
>
> > > library, of
>
> > > course. A few of them are:
>
> > >
>
> > > - answer questions on the QuantLib-users mailing list;
>
> > >
>
> > > - subscribe to the QuantLib-cvs mailing list and review the changes
>
> > >   committed to the repository. You might ask questions about
>the
>
> > >   change, make further suggestions, or report a bug you
>spotted. I'll
>
> > >   try and setup the mailing list so that replies to posts
>go to
>
> > >   QuantLib-dev.
>
> > >
>
> > > - provide examples. Those are easier to write than new parts
>of the
>
> > >   library, and are immensely useful to new users as they
>can act as
>
> > >   documentation of library features and their usage. If
>you don't have
>
> > >   the time to provide examples, you can still contribute
>by writing to
>
> > >   QuantLib-dev and proposing examples to be written by whoever
>accepts
>
> > >   the task.
>
> > >
>
> > > - We might put some kind of cookbook on the wiki (we'll have
>to
>
> > >   discuss the idea on the list.) In this case, you might
>provide code
>
> > >   snippets exemplifying how to perform simple (or less simple)
>
> > >   tasks. This would require less effort than full-fledged
>examples.
>
> > >
>
> > > All of the above are ways to contribute. Even if contributions
>were
>
> > > little, their cumulative effect would be a great help to improve
>the
>
> > > library. Moreover, each of the above are also ways to familiarize
>with
>
> > > the library and in time to become able to work on its internals.
>
> > >
>
> > > Thanks for listening. Comments are welcome.
>
> > >
>
> > > Later,
>
> > >         Luigi
>
> > >
>
> > >
>
> > > ----------------------------------------
>
> > >
>
> > > fix, n.,v.
>
> > > What one does when a problem has been reported too many times
>
>
> > > to be ignored.
>
> > > -- the Jargon file
>
> > >
>
> > >
>
> > >
>
> > > --------------------------------------------------------------
>
> > > -----------
>
> > > Take Surveys. Earn Cash. Influence the Future of IT
>
> > > Join SourceForge.net's Techsay panel and you'll get the
>
> > > chance to share your
>
> > > opinions on IT & business topics through brief surveys-and
>earn cash
>
> > > http://www.techsay.com/default.php?page=join.php&p=sourceforge
>
> > &CID=DEVDEV
>
> > _______________________________________________
>
> > QuantLib-dev mailing list
>
> > Qua...@li...
>
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
> >
>
> > 
>-------------------------------------------------------------------------
>
> > Take Surveys. Earn Cash. Influence the Future of IT
>
> > Join SourceForge.net's Techsay panel and you'll get the chance to
>share your
>
> > opinions on IT & business topics through brief surveys-and earn
>cash
>
> > 
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>
> > _______________________________________________
>
> > QuantLib-dev mailing list
>
> > Qua...@li...
>
> > https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>
>
>


>-------------------------------------------------------------------------
>Take Surveys. Earn Cash. Influence the Future of IT
>Join SourceForge.net's Techsay panel and you'll get the chance to share 
>your
>opinions on IT & business topics through brief surveys-and earn cash
>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV


>_______________________________________________
>QuantLib-dev mailing list
>Qua...@li...
>https://lists.sourceforge.net/lists/listinfo/quantlib-dev

_________________________________________________________________
Solve the Conspiracy and win fantastic prizes.  
http://www.theconspiracygame.co.uk/

Re: [Quantlib-dev] Plans for future releases and call for contributions

[Alan K. <ki...@us...>]

<br><font size=2 face="sans-serif">I would like to point to an alternative
that was adopted and actively supported by COIN-OR (http://www.coin-or.org/),
an open source community that I contribute to.</font>
<br>
<br><font size=2 face="sans-serif">COIN-OR promotes the Open Solver Interface.
&nbsp;OSI is a specification for an optimization solver interface. &nbsp;It
consists of an abstract class and a dozen or so implementations that were
submitted and are (more or less actively) supported by various commercial
vendors and open source developers. &nbsp;COIN-OR projects use OSI as a
bridge pattern.</font>
<br>
<br><font size=2 face="sans-serif">This suggest three possibilities for
solver objects that QL depends on:</font>
<br>
<br><font size=2 face="sans-serif">1) For solvers that have significant
open source activity and have bridge implementations (like COIN-OR) then
it seems like QuantLib could investigate and see if adopting this would
work for them. &nbsp;</font>
<br>
<br><font size=2 face="sans-serif">2) For solvers that have a significant
open source activity but no bridge implementation, QL could recommend to
those projects that they adopt something like an OSI.</font>
<br>
<br><font size=2 face="sans-serif">3) For solvers for which QL is really
the only open source provider, QL could provide an OSI specification and
an implementation of the QL OSI.</font>
<br><font size=2 face="sans-serif"><br>
Alan King<br>
http://www.research.ibm.com/people/k/kingaj/</font>
<br>
<br><tt><font size=2>qua...@li... wrote on
03/19/2007 07:50:15 AM:<br>
<br>
&gt; Welcome overview, many thanks.<br>
&gt; <br>
&gt; My epsilon contribution (as anticipated sometime else), is the<br>
&gt; following:<br>
&gt; <br>
&gt; QuantLib was born largely on the (welcome and foresighting) idea to
NOT<br>
&gt; &quot;re-invent the wheel every time&quot;. But, on the long run,
this goal has<br>
&gt; been partially weakened. In fact, today in quantlib one can find the<br>
&gt; 1001th implementation of standard non-pretty-financial algorithms
(e.g.<br>
&gt; optimizers, random numbers, etc.).<br>
&gt; <br>
&gt; This stuff is already available from other dedicated open-source<br>
&gt; projects (GSL, for instance). Recoding it exposes the QL community
to<br>
&gt; the risk of reintroducing bugs, inefficiencies and all the (non)subtle<br>
&gt; problems already encountered - and solved - by the scientific community<br>
&gt; in the last 50 years of computing... Not a good idea, right? :-) <br>
&gt; <br>
&gt; So, what to do? Here some alternatives:<br>
&gt; <br>
&gt; A) coherently, take the wheel reinvention to its natural end: all
the<br>
&gt; standard non-pretty-financial algorithms should be enumerated, tested<br>
&gt; *in any financial realistic case* with a dedicated testsuite, in<br>
&gt; particular against other more standard implementations. <br>
&gt; I confess I don't know how much of this work has already ben done
in the<br>
&gt; past, but I feel it is a lot of (unwanted) work (optimizers, for<br>
&gt; instance, should be considered with suspect, at the moment).<br>
&gt; <br>
&gt; B) include the &quot;standard non-pretty-financial algorithms&quot;
from other,<br>
&gt; trusted open-source projects. <br>
&gt; <br>
&gt; Obviously the second solution:<br>
&gt; B1) simply moves the problem away from QuantLib, but this is not bad
:-)<br>
&gt; B2) force us to include other libraries into the QL distribution,<br>
&gt; increasing the dependence of the project onto other pieces and<br>
&gt; complicating the installation/building procedure; but QL is already<br>
&gt; integrated with other pieces (boost and log4cxx, for instance), so
we<br>
&gt; should know how to deal with the n+1th piece;<br>
&gt; B3) leaves open the choice of what other &quot;trusted open-source
projects&quot;<br>
&gt; consider, which could be not easy;<br>
&gt; <br>
&gt; To conclude, solution B is my favourite, provided the set B3 is<br>
&gt; non-empty :-)<br>
&gt; <br>
&gt; Unfortunately, my knowledge of other &quot;trusted open-source projects&quot;<br>
&gt; being not large enough to provide a closed solution. <br>
&gt; My only feeling is that GSL looks to be a good candidate: it provides
a<br>
&gt; wide range of mathematical routines &quot;with an extensive test suite&quot;;
it's<br>
&gt; well-known and commonly used in scientific research, the last 1.9<br>
&gt; version was released on 21 February 2007 and it is claimed to be stable<br>
&gt; (see http://www.gnu.org/software/gsl/). I was told that there is a<br>
&gt; problem with the GNU General Public License, but maybe it can be<br>
&gt; overcome, being the library distributed with London's book. It's written<br>
&gt; in C, not object-oriented, and somewhat old-style, but elegance is<br>
&gt; secondary to correct results and computing speed, in my opinion.<br>
&gt; <br>
&gt; I stop here, at this point I don't want to focus the discussion on
GSL<br>
&gt; in particular, but only to points A+B before, and arguments are heavy<br>
&gt; enough for a discussion. I suspect the latter has been already done<br>
&gt; sometime in the past, but I decided to post this contribution in any<br>
&gt; case, in the hope that an update could be useful.<br>
&gt; <br>
&gt; Thank you for reading up to here, any comment is welcome.<br>
&gt; <br>
&gt; Ciao<br>
&gt; Marco<br>
&gt; <br>
&gt; &gt; -----Original Message-----<br>
&gt; &gt; From: qua...@li... <br>
&gt; &gt; [mailto:qua...@li...] On Behalf
<br>
&gt; &gt; Of Luigi Ballabio<br>
&gt; &gt; Sent: 16 March 2007 15:28<br>
&gt; &gt; To: QuantLib developers<br>
&gt; &gt; Subject: [Quantlib-dev] Plans for future releases and call <br>
&gt; &gt; for contributions<br>
&gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; Hi all,<br>
&gt; &gt; &nbsp; &nbsp; first of all, I'd like to say thanks to everybody
who helped us<br>
&gt; &gt; releasing QuantLib 0.4.0 (as well as all previous releases) by<br>
&gt; &gt; contributing code, bug reports, comments---you name it. It's
been a<br>
&gt; &gt; great six years.<br>
&gt; &gt; <br>
&gt; &gt; This year, we're planning to finally take the next step and release<br>
&gt; &gt; QuantLib 1.0. &nbsp;I'll draft a plan and ask for specific contributions<br>
&gt; &gt; later in this post; but before that, please let me share a <br>
&gt; &gt; few thoughts.<br>
&gt; &gt; <br>
&gt; &gt; Lately I started to have the feeling that our development model
has<br>
&gt; &gt; reached its limit. Until now, development of the library has
<br>
&gt; &gt; been pushed<br>
&gt; &gt; forwards by a few dedicated individuals and by occasional <br>
&gt; &gt; contributions<br>
&gt; &gt; by other people. However, there's only so much that this can
<br>
&gt; &gt; achieve; as<br>
&gt; &gt; witnessed, to name a couple of examples, by the lack of user<br>
&gt; &gt; documentation and my systematic delay in answering posts to <br>
&gt; &gt; the mailing<br>
&gt; &gt; lists.<br>
&gt; &gt; <br>
&gt; &gt; In short, we need to foster a community. We didn't give much
effort to<br>
&gt; &gt; this so far; actually, I'm afraid we (the core developers) might
have<br>
&gt; &gt; scared potential contributors away. Until now, we have had a
somewhat<br>
&gt; &gt; cavalier attitude---when we wanted to do something, we just opened
our<br>
&gt; &gt; editors and IDEs and started hacking. (Me? Guilty as charged.)<br>
&gt; &gt; Unfortunately, this might give the impression that the library
is our<br>
&gt; &gt; playground and discourage people from entering our supposedly
closed<br>
&gt; &gt; club.<br>
&gt; &gt; <br>
&gt; &gt; This will have to change. I'll try and bounce ideas on the developer<br>
&gt; &gt; mailing list before any major change. Of course, I also encourage
the<br>
&gt; &gt; other developers to do the same---kudos to those that already
do. In<br>
&gt; &gt; short, I'll do my best so that the library is owned (and felt
as such)<br>
&gt; &gt; by the whole community gravitating around the mailing lists.<br>
&gt; &gt; <br>
&gt; &gt; Enough---and onwards to the plan for release 1.0.<br>
&gt; &gt; <br>
&gt; &gt; My idea (open to discussion, of course) was to get to 1.0 in
two or<br>
&gt; &gt; three releases. The ones before 1.0 will give us a chance to
make<br>
&gt; &gt; changes we've intended to do for quite a while, but that could
not be<br>
&gt; &gt; done easily in a backward-compatible way. Some of them were made<br>
&gt; &gt; already.<br>
&gt; &gt; <br>
&gt; &gt; The next step would be QuantLib 1.0. In fact, the release before
that<br>
&gt; &gt; one (0.9.0?) would almost be a beta release of 1.0. I wouldn't
change<br>
&gt; &gt; much between the two; instead, I would focus on improving <br>
&gt; &gt; documentation<br>
&gt; &gt; and general usability (a task which should already start for
the<br>
&gt; &gt; upcoming releases.)<br>
&gt; &gt; <br>
&gt; &gt; Needless to say, all such releases (as well as future ones) will
need<br>
&gt; &gt; your contribution. You don't need to do anything exceptional;
each of<br>
&gt; &gt; you can help by giving as little time and effort you can <br>
&gt; &gt; afford or want<br>
&gt; &gt; to spare.<br>
&gt; &gt; <br>
&gt; &gt; The easiest way to contribute would be to subscribe to the <br>
&gt; &gt; QuantLib-dev<br>
&gt; &gt; mailing list (the subscription page can be found at<br>
&gt; &gt; &lt;https://lists.sourceforge.net/lists/listinfo/quantlib-dev&gt;.)
<br>
&gt; &gt; As I said,<br>
&gt; &gt; we'll try and discuss future developments there. Your contribution
to<br>
&gt; &gt; the discussions, even if only an occasional one, will be useful.<br>
&gt; &gt; <br>
&gt; &gt; If you think you can get more involved, there's a number of <br>
&gt; &gt; other things<br>
&gt; &gt; you can do - apart from contributing code or patches to the <br>
&gt; &gt; library, of<br>
&gt; &gt; course. A few of them are:<br>
&gt; &gt; <br>
&gt; &gt; - answer questions on the QuantLib-users mailing list;<br>
&gt; &gt; <br>
&gt; &gt; - subscribe to the QuantLib-cvs mailing list and review the changes<br>
&gt; &gt; &nbsp; committed to the repository. You might ask questions about
the<br>
&gt; &gt; &nbsp; change, make further suggestions, or report a bug you
spotted. I'll<br>
&gt; &gt; &nbsp; try and setup the mailing list so that replies to posts
go to<br>
&gt; &gt; &nbsp; QuantLib-dev.<br>
&gt; &gt; <br>
&gt; &gt; - provide examples. Those are easier to write than new parts
of the<br>
&gt; &gt; &nbsp; library, and are immensely useful to new users as they
can act as<br>
&gt; &gt; &nbsp; documentation of library features and their usage. If
you don't have<br>
&gt; &gt; &nbsp; the time to provide examples, you can still contribute
by writing to<br>
&gt; &gt; &nbsp; QuantLib-dev and proposing examples to be written by whoever
accepts<br>
&gt; &gt; &nbsp; the task.<br>
&gt; &gt; <br>
&gt; &gt; - We might put some kind of cookbook on the wiki (we'll have
to<br>
&gt; &gt; &nbsp; discuss the idea on the list.) In this case, you might
provide code<br>
&gt; &gt; &nbsp; snippets exemplifying how to perform simple (or less simple)<br>
&gt; &gt; &nbsp; tasks. This would require less effort than full-fledged
examples.<br>
&gt; &gt; <br>
&gt; &gt; All of the above are ways to contribute. Even if contributions
were<br>
&gt; &gt; little, their cumulative effect would be a great help to improve
the<br>
&gt; &gt; library. Moreover, each of the above are also ways to familiarize
with<br>
&gt; &gt; the library and in time to become able to work on its internals.<br>
&gt; &gt; <br>
&gt; &gt; Thanks for listening. Comments are welcome.<br>
&gt; &gt; <br>
&gt; &gt; Later,<br>
&gt; &gt; &nbsp; &nbsp; &nbsp; &nbsp; Luigi<br>
&gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; ---------------------------------------- <br>
&gt; &gt; <br>
&gt; &gt; fix, n.,v. <br>
&gt; &gt; What one does when a problem has been reported too many times
<br>
&gt; &gt; to be ignored. <br>
&gt; &gt; -- the Jargon file <br>
&gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; <br>
&gt; &gt; --------------------------------------------------------------<br>
&gt; &gt; -----------<br>
&gt; &gt; Take Surveys. Earn Cash. Influence the Future of IT<br>
&gt; &gt; Join SourceForge.net's Techsay panel and you'll get the <br>
&gt; &gt; chance to share your<br>
&gt; &gt; opinions on IT &amp; business topics through brief surveys-and
earn cash<br>
&gt; &gt; http://www.techsay.com/default.php?page=join.php&amp;p=sourceforge<br>
&gt; &amp;CID=DEVDEV<br>
&gt; _______________________________________________<br>
&gt; QuantLib-dev mailing list<br>
&gt; Qua...@li...<br>
&gt; https://lists.sourceforge.net/lists/listinfo/quantlib-dev<br>
&gt; <br>
&gt; -------------------------------------------------------------------------<br>
&gt; Take Surveys. Earn Cash. Influence the Future of IT<br>
&gt; Join SourceForge.net's Techsay panel and you'll get the chance to
share your<br>
&gt; opinions on IT &amp; business topics through brief surveys-and earn
cash<br>
&gt; http://www.techsay.com/default.php?page=join.php&amp;p=sourceforge&amp;CID=DEVDEV<br>
&gt; _______________________________________________<br>
&gt; QuantLib-dev mailing list<br>
&gt; Qua...@li...<br>
&gt; https://lists.sourceforge.net/lists/listinfo/quantlib-dev<br>
</font></tt>

Re: [Quantlib-dev] Plans for future releases and call for contributions

[Bianchetti M. <mar...@ca...>]

Welcome overview, many thanks.

My epsilon contribution (as anticipated sometime else), is the
following:

QuantLib was born largely on the (welcome and foresighting) idea to NOT
"re-invent the wheel every time". But, on the long run, this goal has
been partially weakened. In fact, today in quantlib one can find the
1001th implementation of standard non-pretty-financial algorithms (e.g.
optimizers, random numbers, etc.).

This stuff is already available from other dedicated open-source
projects (GSL, for instance). Recoding it exposes the QL community to
the risk of reintroducing bugs, inefficiencies and all the (non)subtle
problems already encountered - and solved - by the scientific community
in the last 50 years of computing... Not a good idea, right? :-)=20

So, what to do? Here some alternatives:

A) coherently, take the wheel reinvention to its natural end: all the
standard non-pretty-financial algorithms should be enumerated, tested
*in any financial realistic case* with a dedicated testsuite, in
particular against other more standard implementations.=20
I confess I don't know how much of this work has already ben done in the
past, but I feel it is a lot of (unwanted) work (optimizers, for
instance, should be considered with suspect, at the moment).

B) include the "standard non-pretty-financial algorithms" from other,
trusted open-source projects.=20

Obviously the second solution:
B1) simply moves the problem away from QuantLib, but this is not bad :-)
B2) force us to include other libraries into the QL distribution,
increasing the dependence of the project onto other pieces and
complicating the installation/building procedure; but QL is already
integrated with other pieces (boost and log4cxx, for instance), so we
should know how to deal with the n+1th piece;
B3) leaves open the choice of what other "trusted open-source projects"
consider, which could be not easy;

To conclude, solution B is my favourite, provided the set B3 is
non-empty :-)

Unfortunately, my knowledge of other "trusted open-source projects"
being not large enough to provide a closed solution.=20
My only feeling is that GSL looks to be a good candidate: it provides a
wide range of mathematical routines "with an extensive test suite"; it's
well-known and commonly used in scientific research, the last 1.9
version was released on 21 February 2007 and it is claimed to be stable
(see http://www.gnu.org/software/gsl/). I was told that there is a
problem with the GNU General Public License, but maybe it can be
overcome, being the library distributed with London's book. It's written
in C, not object-oriented, and somewhat old-style, but elegance is
secondary to correct results and computing speed, in my opinion.

I stop here, at this point I don't want to focus the discussion on GSL
in particular, but only to points A+B before, and arguments are heavy
enough for a discussion. I suspect the latter has been already done
sometime in the past, but I decided to post this contribution in any
case, in the hope that an update could be useful.

Thank you for reading up to here, any comment is welcome.

Ciao
Marco

> -----Original Message-----
> From: qua...@li...=20
> [mailto:qua...@li...] On Behalf=20
> Of Luigi Ballabio
> Sent: 16 March 2007 15:28
> To: QuantLib developers
> Subject: [Quantlib-dev] Plans for future releases and call=20
> for contributions
>=20
>=20
>=20
> Hi all,
>     first of all, I'd like to say thanks to everybody who helped us
> releasing QuantLib 0.4.0 (as well as all previous releases) by
> contributing code, bug reports, comments---you name it. It's been a
> great six years.
>=20
> This year, we're planning to finally take the next step and release
> QuantLib 1.0.  I'll draft a plan and ask for specific contributions
> later in this post; but before that, please let me share a=20
> few thoughts.
>=20
> Lately I started to have the feeling that our development model has
> reached its limit. Until now, development of the library has=20
> been pushed
> forwards by a few dedicated individuals and by occasional=20
> contributions
> by other people. However, there's only so much that this can=20
> achieve; as
> witnessed, to name a couple of examples, by the lack of user
> documentation and my systematic delay in answering posts to=20
> the mailing
> lists.
>=20
> In short, we need to foster a community. We didn't give much effort to
> this so far; actually, I'm afraid we (the core developers) might have
> scared potential contributors away. Until now, we have had a somewhat
> cavalier attitude---when we wanted to do something, we just opened our
> editors and IDEs and started hacking. (Me? Guilty as charged.)
> Unfortunately, this might give the impression that the library is our
> playground and discourage people from entering our supposedly closed
> club.
>=20
> This will have to change. I'll try and bounce ideas on the developer
> mailing list before any major change. Of course, I also encourage the
> other developers to do the same---kudos to those that already do. In
> short, I'll do my best so that the library is owned (and felt as such)
> by the whole community gravitating around the mailing lists.
>=20
> Enough---and onwards to the plan for release 1.0.
>=20
> My idea (open to discussion, of course) was to get to 1.0 in two or
> three releases. The ones before 1.0 will give us a chance to make
> changes we've intended to do for quite a while, but that could not be
> done easily in a backward-compatible way. Some of them were made
> already.
>=20
> The next step would be QuantLib 1.0. In fact, the release before that
> one (0.9.0?) would almost be a beta release of 1.0. I wouldn't change
> much between the two; instead, I would focus on improving=20
> documentation
> and general usability (a task which should already start for the
> upcoming releases.)
>=20
> Needless to say, all such releases (as well as future ones) will need
> your contribution. You don't need to do anything exceptional; each of
> you can help by giving as little time and effort you can=20
> afford or want
> to spare.
>=20
> The easiest way to contribute would be to subscribe to the=20
> QuantLib-dev
> mailing list (the subscription page can be found at
> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>.)=20
> As I said,
> we'll try and discuss future developments there. Your contribution to
> the discussions, even if only an occasional one, will be useful.
>=20
> If you think you can get more involved, there's a number of=20
> other things
> you can do - apart from contributing code or patches to the=20
> library, of
> course. A few of them are:
>=20
> - answer questions on the QuantLib-users mailing list;
>=20
> - subscribe to the QuantLib-cvs mailing list and review the changes
>   committed to the repository. You might ask questions about the
>   change, make further suggestions, or report a bug you spotted. I'll
>   try and setup the mailing list so that replies to posts go to
>   QuantLib-dev.
>=20
> - provide examples. Those are easier to write than new parts of the
>   library, and are immensely useful to new users as they can act as
>   documentation of library features and their usage. If you don't have
>   the time to provide examples, you can still contribute by writing to
>   QuantLib-dev and proposing examples to be written by whoever accepts
>   the task.
>=20
> - We might put some kind of cookbook on the wiki (we'll have to
>   discuss the idea on the list.) In this case, you might provide code
>   snippets exemplifying how to perform simple (or less simple)
>   tasks. This would require less effort than full-fledged examples.
>=20
> All of the above are ways to contribute. Even if contributions were
> little, their cumulative effect would be a great help to improve the
> library. Moreover, each of the above are also ways to familiarize with
> the library and in time to become able to work on its internals.
>=20
> Thanks for listening. Comments are welcome.
>=20
> Later,
>         Luigi
>=20
>=20
> ----------------------------------------=20
>=20
> fix, n.,v.=20
> What one does when a problem has been reported too many times=20
> to be ignored.=20
> -- the Jargon file=20
>=20
>=20
>=20
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the=20
> chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge
&CID=3DDEVDEV
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Quantlib-dev] Plans for future releases and call for contributions

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

Hi all,
    first of all, I'd like to say thanks to everybody who helped us
releasing QuantLib 0.4.0 (as well as all previous releases) by
contributing code, bug reports, comments---you name it. It's been a
great six years.

This year, we're planning to finally take the next step and release
QuantLib 1.0.  I'll draft a plan and ask for specific contributions
later in this post; but before that, please let me share a few thoughts.

Lately I started to have the feeling that our development model has
reached its limit. Until now, development of the library has been pushed
forwards by a few dedicated individuals and by occasional contributions
by other people. However, there's only so much that this can achieve; as
witnessed, to name a couple of examples, by the lack of user
documentation and my systematic delay in answering posts to the mailing
lists.

In short, we need to foster a community. We didn't give much effort to
this so far; actually, I'm afraid we (the core developers) might have
scared potential contributors away. Until now, we have had a somewhat
cavalier attitude---when we wanted to do something, we just opened our
editors and IDEs and started hacking. (Me? Guilty as charged.)
Unfortunately, this might give the impression that the library is our
playground and discourage people from entering our supposedly closed
club.

This will have to change. I'll try and bounce ideas on the developer
mailing list before any major change. Of course, I also encourage the
other developers to do the same---kudos to those that already do. In
short, I'll do my best so that the library is owned (and felt as such)
by the whole community gravitating around the mailing lists.

Enough---and onwards to the plan for release 1.0.

My idea (open to discussion, of course) was to get to 1.0 in two or
three releases. The ones before 1.0 will give us a chance to make
changes we've intended to do for quite a while, but that could not be
done easily in a backward-compatible way. Some of them were made
already.

The next step would be QuantLib 1.0. In fact, the release before that
one (0.9.0?) would almost be a beta release of 1.0. I wouldn't change
much between the two; instead, I would focus on improving documentation
and general usability (a task which should already start for the
upcoming releases.)

Needless to say, all such releases (as well as future ones) will need
your contribution. You don't need to do anything exceptional; each of
you can help by giving as little time and effort you can afford or want
to spare.

The easiest way to contribute would be to subscribe to the QuantLib-dev
mailing list (the subscription page can be found at
<https://lists.sourceforge.net/lists/listinfo/quantlib-dev>.) As I said,
we'll try and discuss future developments there. Your contribution to
the discussions, even if only an occasional one, will be useful.

If you think you can get more involved, there's a number of other things
you can do - apart from contributing code or patches to the library, of
course. A few of them are:

- answer questions on the QuantLib-users mailing list;

- subscribe to the QuantLib-cvs mailing list and review the changes
  committed to the repository. You might ask questions about the
  change, make further suggestions, or report a bug you spotted. I'll
  try and setup the mailing list so that replies to posts go to
  QuantLib-dev.

- provide examples. Those are easier to write than new parts of the
  library, and are immensely useful to new users as they can act as
  documentation of library features and their usage. If you don't have
  the time to provide examples, you can still contribute by writing to
  QuantLib-dev and proposing examples to be written by whoever accepts
  the task.

- We might put some kind of cookbook on the wiki (we'll have to
  discuss the idea on the list.) In this case, you might provide code
  snippets exemplifying how to perform simple (or less simple)
  tasks. This would require less effort than full-fledged examples.

All of the above are ways to contribute. Even if contributions were
little, their cumulative effect would be a great help to improve the
library. Moreover, each of the above are also ways to familiarize with
the library and in time to become able to work on its internals.

Thanks for listening. Comments are welcome.

Later,
        Luigi


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

fix, n.,v. 
What one does when a problem has been reported too many times 
to be ignored. 
-- the Jargon file 

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

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

Hi, Luigi,

in pseudoSqrt.cpp the checking of symmetric matrix may fail due to
rounding errors in construction of a matrix.=20

For safety, line 235 and 343

=20

           QL_REQUIRE(matrix[i][j] =3D=3D matrix[j][i],

                           "matrix not symmetric");

=20

should be changed to  QL_REQUIRE(fabs(matrix[i][j] -matrix[j][i])<
QL_EPSILON ,

                           "matrix not symmetric");

=20

The current check thinks=20

0.026098788171586292  0.026098788171586288 are different.=20

=20

Thanks.

=20

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

Peter Li=20

=20

Re: [Quantlib-dev] New Basket Option Code and question about StochasticProcessArray

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

I did some more refactoring of the Basket options.  Now it takes a 
BasketPayoff class.  The BasketPayoff class takes another payoff class and 
then wrappers it with basket information.  This makes the system extensible 
to non-vanilla payoffs, and the engines use dynamic pointer casting to figure 
out what it can process.

One interesting extension would be to allow one to composite payoffs.  Have a 
payoff class that consists of a linear combination of payoff classes.  
Another interesting possibility is to hack the SWIG code to allow definition 
of payoff functions in the scripting language.  The hard part is to figure 
out how to avoid duplicating code with the cost functions.

On Monday 12 March 2007 12:51:31 Luigi Ballabio wrote:
> Joe,
> 	first of all, thanks for the effort---I've meant to do something of the
> sort for a long time but never got around to implement it.
> Just for clarity though, I'd call the base class BasketOptionPayoff
> (same for the children.) Since next release's purpose will be to get
> closer to release 1.0 (more on this later) we're not much concerned with
> backward compatibility at this time---in fact, we're trying to change a
> number of things that seemed right at some time, that we wanted to
> change after a while, but that weren't easy to change while maintaining
> backward compatibility.

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

Re: [Quantlib-dev] [QuantLib-cvs] QuantLib/ql period.hpp,1.9,1.10

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

I have a proposed fix that includes the Period declaration for Natural, but 
takes out the one for Size (which doesn't make any sense anyway).  Since we 
now have both a signed and unsigned QL_INTEGER declaration, this should 
compile on anything.

Thoughts?

On Thursday 08 March 2007 04:19:37 Luigi Ballabio wrote:
> On Thu, 2007-03-08 at 09:52 +0000, Francois du Vignaud wrote:
> > Modified Files:
> > 	period.hpp
> > Log Message:
> > msvc compilation error fix ->roll back of last J Wang commit:
> > fix so that code is ISO compliant
>
> Francois,
> 	I had the same problem on gcc 4.1, but I guess Joe had some other
> problem with his compiler, so just reverting the change is only likely
> to start an edit war like those on Wikipedia. The correct way to proceed
> would be to contact Joe and compare notes.
>
> I understand that you folks at Caboto want the library to compile, so
> it's fine if you commit the fix to distribute it to your colleagues (of
> course, your real problem is that you're relying on the main repository
> for production work, instead of having an internal one.)
>
> Just don't let the problem drop.
>
> Later,
> 	Luigi
>
>
> ----------------------------------------
>
> The box said "Use Windows 95 or better," so I got a Macintosh.



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

Re: [Quantlib-dev] Adding a data store

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

Hi Keith,

That's an impressive summary of the resources available to you for
your project, both in terms of the data and the potential support from
Sybase.

> Hmm, serialisation / data store. I think we might be talking
> "differently" here.

I accept that serialisation and data store are separate undertakings,
I'm just thinking that as we tackle data store we should keep in mind
the design for serialisation, in case the two projects have some
common building blocks.  If we get into the details and find that the
two projects have zero in common, then so be it.  I suspect we'll find
there's some overlap.

> Let me deal with the FPML bit first. This might be a little
> un-politically correct, but here goes anyway.
> I know a number of people who hold senior roles on the FPML committee
> for an assortment of different threads.
> It is a committee based thing that takes a little time to review stuff,
> agree stuff, document stuff and then publish stuff.
> Evidence of this is seen in the manner in which the SwapsWire people
> have built their own SWML and extended-FPML that deals with things that
> are not yet in the published FPML.
> There is a similar type of thing being done by the nice people at DTCC
> to encapsulate their electronic confirmation matching service called
> DerivServ.
> The nice people at MarkIT are also working with an extended variant of
> the FPML stuff.
> At some point this will all converge, but don't hold your breath as by
> the time the FPML people catch up, the others will have moved on.

Interesting story, I had no idea the whole process was so fraught.

When it comes time to move into FpML, I wouldn't lose sleep over the
implementation details, I'd just do whatever seems most sensible at
the time, with the option to adjust later as things evolve.

> I will now take the liberty of talking to the nice people at
> Sybase to see just how generous they feel about professional assistance
> in this little venture. (No Promises, no commitments, intended as a
> feedback thing to test the waters)

Sounds good, please keep me posted and let me know if there's anything
I can do to help.

Regards,
Eric

Re: [Quantlib-dev] Adding a data store

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

On Mar 13, 2007, at 7:58 PM, Keith Wood wrote:
> My suggestion had to do with the design and implementation of a data
> schema that would enable people who use QuantLib to store stuff in
> tables in a relational database. All of the holiday stuff belongs in a
> table. All of the day count convention could usefully be stored in a
> collection of tables.

I'm not sure that I follow here. I can see that the definition of, say, 
an equity option (exercise date, strike...) can be stored in a table. A 
calendar I might see---even though our calendars are not a collection 
of holidays, but rather a collection of rules such as "the third Monday 
in September" or "May 1st unless it's a Sunday, in which case the 
following Monday is a holiday instead". But a day-count convention is 
basically an algorithm. I might just have misinterpreted you, but how 
are you going to store them?

Later,
	Luigi

Re: [Quantlib-dev] Adding a data store

[Keith W. <kei...@gm...>]

Hmm, serialisation / data store. I think we might be talking
"differently" here.
Let me deal with the FPML bit first. This might be a little
un-politically correct, but here goes anyway.
I know a number of people who hold senior roles on the FPML committee
for an assortment of different threads.
It is a committee based thing that takes a little time to review stuff,
agree stuff, document stuff and then publish stuff.
Evidence of this is seen in the manner in which the SwapsWire people
have built their own SWML and extended-FPML that deals with things that
are not yet in the published FPML.
There is a similar type of thing being done by the nice people at DTCC
to encapsulate their electronic confirmation matching service called
DerivServ.
The nice people at MarkIT are also working with an extended variant of
the FPML stuff.
At some point this will all converge, but don't hold your breath as by
the time the FPML people catch up, the others will have moved on.

My suggestion had to do with the design and implementation of a data
schema that would enable people who use QuantLib to store stuff in
tables in a relational database. All of the holiday stuff belongs in a
table. All of the day count convention could usefully be stored in a
collection of tables. Having gone to the trouble of getting some market
rates from somewhere, using them to calculate the zero's, strips,
smiles, complicated volatility surfaces and so on for "today's" pricing,
it might be nice to save "stuff" in a relational table (or several).
FPML, SWML and all the other "flavours" that have to do with XML stuff,
lend themselves to being mapped to a collection of relational tables in
a sensible manner. There are already collections of tools that do most
of that for you.

There seems to be a need to apply some assistance to the choice of
which-XML, and this is loosely connected to a similar decision about
which-SQL. I will now take the liberty of talking to the nice people at
Sybase to see just how generous they feel about professional assistance
in this little venture. (No Promises, no commitments, intended as a
feedback thing to test the waters)

I will get back to you shortly.
Regards
Keith

p.s. please feel free in the meantime to bombard me with questions and
or flame me for not being politically correct.


eric ehlers wrote:
> Hi Keith,
>
> Many thanks for getting in touch.
>
> Some progress has already been made on a design for extending
> QuantLibAddin to support serialization, and my first thought is
> whether a common framework could serve as a basis both for
> serialization (say for distributed computing) and an RDB store.
>
> Here are the links to the previous discussion on serialization:
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=6507779&forum_id=4300
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=6539684&forum_id=4300
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=6540997&forum_id=4300
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=6543552&forum_id=4300
>
> http://sourceforge.net/mailarchive/forum.php?thread_id=6700844&forum_id=4300
>
>
> Please also take a look at the Value Objects feature, contributed to
> QuantLibAddin by Plamen Neykov.  Each time a QuantLib object is
> constructed in ObjectHandler, a Value Object is associated with it,
> the VO comprises a snapshot of the inputs to the constructor of the QL
> object, and the idea is that VOs would be used as the basis for, say,
> reconstituting the same object on another machine.  VOs can be
> interrogated with functions ohPropertyNames() and ohPropertyValues().
>
> I'd be interested to hear your reaction to these initial ideas.
>
> Kind Regards,
> Eric
>
> On 3/9/07, Keith Wood <kei...@gm...> wrote:
>> Greetings All,
>>
>> My name is Keith Wood and I currently work as the business development
>> manager for a little known consulting company based in Frankfurt,
>> Germany. As part of some business development work that I am currently
>> doing, I find myself wanting to suggest that someone add the required
>> functionality  such as would allow users of QuantLib to
>> Fetch/Process/Store data in a relational database.
>> I envisage this as being the next step up from QuantLibAddIn where
>> rather than providing the hooks to a spreadsheet, you get hooked into a
>> data schema. I was thinking something along the lines of a generic
>> open-source model that allowed you to "install" a bunch of tables and
>> "stuff" on your favorite flavor of relational data provider.
>> I find myself in the somewhat unique position of being able to call upon
>> the engineering group of Sybase as resources to implement this.
>>
>> Is there any interest from your side in talking about this further.
>> If so, who should I be talking to.
>>
>> Regards
>> Keith Wood
>>
>> -------------------------------------------------------------------------
>>
>> Take Surveys. Earn Cash. Influence the Future of IT
>> Join SourceForge.net's Techsay panel and you'll get the chance to
>> share your
>> opinions on IT & business topics through brief surveys-and earn cash
>> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
>>
>> _______________________________________________
>> QuantLib-dev mailing list
>> Qua...@li...
>> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>>
>

Re: [Quantlib-dev] Adding a data store

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

Hi Keith,

Many thanks for getting in touch.

Some progress has already been made on a design for extending
QuantLibAddin to support serialization, and my first thought is
whether a common framework could serve as a basis both for
serialization (say for distributed computing) and an RDB store.

Here are the links to the previous discussion on serialization:

http://sourceforge.net/mailarchive/forum.php?thread_id=6507779&forum_id=4300
http://sourceforge.net/mailarchive/forum.php?thread_id=6539684&forum_id=4300
http://sourceforge.net/mailarchive/forum.php?thread_id=6540997&forum_id=4300
http://sourceforge.net/mailarchive/forum.php?thread_id=6543552&forum_id=4300
http://sourceforge.net/mailarchive/forum.php?thread_id=6700844&forum_id=4300

Please also take a look at the Value Objects feature, contributed to
QuantLibAddin by Plamen Neykov.  Each time a QuantLib object is
constructed in ObjectHandler, a Value Object is associated with it,
the VO comprises a snapshot of the inputs to the constructor of the QL
object, and the idea is that VOs would be used as the basis for, say,
reconstituting the same object on another machine.  VOs can be
interrogated with functions ohPropertyNames() and ohPropertyValues().

I'd be interested to hear your reaction to these initial ideas.

Kind Regards,
Eric

On 3/9/07, Keith Wood <kei...@gm...> wrote:
> Greetings All,
>
> My name is Keith Wood and I currently work as the business development
> manager for a little known consulting company based in Frankfurt,
> Germany. As part of some business development work that I am currently
> doing, I find myself wanting to suggest that someone add the required
> functionality  such as would allow users of QuantLib to
> Fetch/Process/Store data in a relational database.
> I envisage this as being the next step up from QuantLibAddIn where
> rather than providing the hooks to a spreadsheet, you get hooked into a
> data schema. I was thinking something along the lines of a generic
> open-source model that allowed you to "install" a bunch of tables and
> "stuff" on your favorite flavor of relational data provider.
> I find myself in the somewhat unique position of being able to call upon
> the engineering group of Sybase as resources to implement this.
>
> Is there any interest from your side in talking about this further.
> If so, who should I be talking to.
>
> Regards
> Keith Wood
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> QuantLib-dev mailing list
> Qua...@li...
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>