quantlib-dev — Discussion of QuantLib development

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

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

On 4/19/07, Luigi Ballabio <lui...@gm...> wrote:
> On Wed, 2007-04-18 at 16:02 +0200, Luigi Ballabio wrote:
> > Aren't we going a bit too far? I mean, there's one evolver per subfolder
> > right now---with some subfolders being empty, too. At this point, this
> > much structure looks to me like a burden more than a help---especially
> > since using Doxygen, we can easily generate a reference page where all
> > the evolvers are listed and where it is stated whether each one is
> > normal/lognormal and what rate type they evolve.
>
> I just stumbled into another problem with an elaborate folder
> structure---"make dist" currently fails to produce the tarball of the
> library (tar insists on file paths being no longer than 99 characters.)

ok, this seems a final argument: I've put back all evolver files in
the plain evolver folder.

I've also renamed classes and files using the pattern Normal/LogNormal
+ FwdRate/CotSwapRate/CmSwapRate + Pc/Ipc/Euler + _/Constrained

ciao -- Nando

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

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

On 4/19/07, Luigi Ballabio <lui...@gm...> wrote:
> Just a thought: isn't the name TimeDependantCorrelationStructure
> redundant? (the general case being time dependence, and the constant
> case being a specialized one.) Maybe just CorrelationStructure?

I've just renamed TimeDependantCorrelationStructure class and folder
as PiecewiseConstantCorrelation. This should convey that all derived
classes are required to be piecewise constant in time.

hope it helps

ciao -- Nando

Re: [Quantlib-dev] Array vs std::vector + free operators

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

On Thu, 2007-04-19 at 18:52 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> I badly missed this point, I will slap myself with bjarne's book ;-)

I doubt it's an effective way to transfer its contents to one's brain :)

Luigi


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

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

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

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

On Thu, 2007-04-19 at 19:25 +0200, Ferdinando Ametrano wrote:
> On 4/19/07, lba...@us...
> <lba...@us...> wrote:
> > Delta, gamma and theta added to binomial engine for vanilla options (thanks to Steve Cook.)
> > Theta is currently not close enough to analytic values. Investigation would be needed.
> 
> why theta isn't just deduced from Delta and Gamma using Black
> equation? This approach is used elsewhere in QuantLib.

Yes, I can try that.

Later,
	Luigi


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

Dealing with failure is easy: work hard to improve. Success is also 
easy to handle: you've solved the wrong problem. Work hard to improve. 
-- Alan Perlis 

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

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

On 4/19/07, lba...@us...
<lba...@us...> wrote:
> Delta, gamma and theta added to binomial engine for vanilla options (thanks to Steve Cook.)
> Theta is currently not close enough to analytic values. Investigation would be needed.

why theta isn't just deduced from Delta and Gamma using Black
equation? This approach is used elsewhere in QuantLib.

ciao -- Nando

Re: [Quantlib-dev] Array vs std::vector + free operators

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

>Apart from adding operations to std::vector, the above is not as
>efficient as Array:operator+. if you write

>std::vector<Real> w =3D u+w;

>the addition returns a Disposable, but the std::vector constructor
>doesn't know what to do with it, so it copies its contents instead of
>swapping. If you want full efficiency, you have to write:

>std::vector<Real> w;
>w.swap(u+v);

>which is more awkward. On the other hand, Array defines a constructor
>taking a Disposable, so there's no moving in

>Array w =3D u+v;

I badly missed this point, I will slap myself with bjarne's book ;-)

Fran=E7ois

Re: [Quantlib-dev] Array vs std::vector + free operators

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

On Thu, 2007-04-19 at 17:11 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> >- you're changing the std::vector interface by adding operators. I'm not
> >sure that it is legal C++.  Moreover, this might be done without the
> >user knowing it if he happens to include a file which in turn includes
> >your new operators. Thus, code which according to the C++ standard is
> >not valid (such as w = u+v if u,v,and w are std::vectors) would silently
> >become legal. I'm not comfortable with this.
> 
> We could provide only specialized templates implementation. (for double, even if it some of them might also make sense with other data like Date,...) Anyway I'm pretty sure that any decent compiler would squeal if the corresponding elementwise operation doesn't exist.

You would still be changing the interface of that particular
specialization of std::vector. The problem remains. I'm not referring to
the possibility of adding vectors of non-numeric types; the compiler
would reject that. I'm saying that the C++ standard states that w = u+v
doesn't work with std::vector, and you're making it work.


> I agree with you that a general purpose container and an Array are two different beasts. About the valarray Josuttis doesn't seem to be a great fan:
> "At the time of this writing, no such implementation is known, and standard valarrays are, generally speaking, quite inefficient at performing the operations for which they were designed." (C++ templates: The complete guide)
> 
> Maybe they have improved it since ... :-)

Maybe. Or maybe we could implement Array _in terms of_ std::vector. But
there should be no conceptual confusion between the two.


> PS: here is an example of the operators I have defined:
> 
> inline const Disposable<std::vector<Real> > operator+(const std::vector<Real>& v1, const std::vector<Real>& v2) {
>         QL_REQUIRE(v1.size() == v2.size(),
>                    " vectors with different sizes (" << v1.size() << ", "
>                    << v2.size() << ") cannot be added");
>         std::vector<Real> result(v1.size());
>         std::transform(v1.begin(),v1.end(),v2.begin(),result.begin(),
>                        std::plus<Real>());
>         return result;
>     }

Apart from adding operations to std::vector, the above is not as
efficient as Array:operator+. if you write

std::vector<Real> w = u+w;

the addition returns a Disposable, but the std::vector constructor
doesn't know what to do with it, so it copies its contents instead of
swapping. If you want full efficiency, you have to write:

std::vector<Real> w;
w.swap(u+v);

which is more awkward. On the other hand, Array defines a constructor
taking a Disposable, so there's no moving in

Array w = u+v;


> PPS: I don't want to be pushy about this. It is just an idea I'm playing with.

Same here.

Later,
	Luigi


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

Quote me as saying I was misquoted. 
-- Groucho Marx 

Re: [Quantlib-dev] Array vs std::vector + free operators

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

Fran=E7ois,
	it doesn't sound right to me, for a couple of reasons:

>- you're changing the std::vector interface by adding operators. I'm =
not
>sure that it is legal C++.  Moreover, this might be done without the
>user knowing it if he happens to include a file which in turn includes
>your new operators. Thus, code which according to the C++ standard is
>not valid (such as w =3D u+v if u,v,and w are std::vectors) would =
silently
>become legal. I'm not comfortable with this.

We could provide only specialized templates implementation. (for double, =
even if it some of them might also make sense with other data like =
Date,...) Anyway I'm pretty sure that any decent compiler would squeal =
if the corresponding elementwise operation doesn't exist.

>- there's a conceptual difference between the two classes, and using
>std::vector for both would confuse the issue. std::vector is a
>container; Array is the linear-algebra concept of an array. I, too, had
>been thinking of replacing Array with an STL class, but the right one
>would be std::valarray---which models the right concept and already
>defines the required operators.

I agree with you that a general purpose container and an Array are two =
different beasts. About the valarray Josuttis doesn't seem to be a great =
fan:
"At the time of this writing, no such implementation is known, and =
standard valarrays are, generally speaking, quite inefficient at =
performing the operations for which they were designed." (C++ templates: =
The complete guide)

Maybe they have improved it since ... :-)

Rgds,
Fran=E7ois

PS: here is an example of the operators I have defined:

inline const Disposable<std::vector<Real> > operator+(const =
std::vector<Real>& v1, const std::vector<Real>& v2) {
        QL_REQUIRE(v1.size() =3D=3D v2.size(),
                   " vectors with different sizes (" << v1.size() << ", =
"
                   << v2.size() << ") cannot be added");
        std::vector<Real> result(v1.size());
        std::transform(v1.begin(),v1.end(),v2.begin(),result.begin(),
                       std::plus<Real>());
        return result;
    }

PPS: I don't want to be pushy about this. It is just an idea I'm playing =
with.

[Quantlib-dev] Market-model tests

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

Hi all,
	now that the market-model tests for the callable-swap were re-enabled,
the test suite seems to take forever (as in more than one hour on a
recent machine.) Is it because CurveState's methods are now virtual?

Later,
	Luigi

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

I'd never join any club that would have the likes of me as a member. 
-- 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 16:41
Message generated for change (Comment added) made by lballabio
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: Closed
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: Luigi Ballabio (lballabio)
Date: 2007-04-19 17:00

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

Steve's code is now in the repository.

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

Comment By: steve_affine (steve_affine)
Date: 2007-04-11 11: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] Array vs std::vector + free operators

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

On Thu, 2007-04-19 at 15:47 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS
GASAPRD PHI wrote:
> I have tried to removing the dependency on Array class from the
> optimization framework. One change leading to another it turns out
> that Arrray dependencies could be removed in the whole QL !
> The only change I had to do was to provide missing operators an
> independent header file and all worked fine. As a result I’m wondering
> if using plain std::vector instead of Arrray wouldn’t be more
> efficient in terms of compilation efficiency and flexibility of use.
> (if one want to use linear algebra he has just to include a file
> defining new operators…).

François,
	it doesn't sound right to me, for a couple of reasons:

- you're changing the std::vector interface by adding operators. I'm not
sure that it is legal C++.  Moreover, this might be done without the
user knowing it if he happens to include a file which in turn includes
your new operators. Thus, code which according to the C++ standard is
not valid (such as w = u+v if u,v,and w are std::vectors) would silently
become legal. I'm not comfortable with this.

- there's a conceptual difference between the two classes, and using
std::vector for both would confuse the issue. std::vector is a
container; Array is the linear-algebra concept of an array. I, too, had
been thinking of replacing Array with an STL class, but the right one
would be std::valarray---which models the right concept and already
defines the required operators.

Later,
	Luigi


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

If you can't convince them, confuse them. 
-- Harry S. Truman 

[Quantlib-dev] Array vs std::vector + free operators

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

Hi all,

=20

=20

I have tried to removing the dependency on Array class from the =
optimization framework. One change leading to another it turns out that =
Arrray dependencies could be removed in the whole QL ! The only change I =
had to do was to provide missing operators an independent header file =
and all worked fine. As a result I'm wondering if using plain =
std::vector instead of Arrray wouldn't be more efficient in terms of =
compilation efficiency and flexibility of use. (if one want to use =
linear algebra he has just to include a file defining new operators...). =
I haven't done serious tests but I don't think that it would cause any =
performance loss since std::vector is a sequential container and is =
"swapable" in constant time. On the other hand it would make the array =
implementation more transparent to the user thus much more difficult to =
replace if one want to provide another implementation (but is it likely =
to happen ?)

Any thought ?

Fran=E7ois

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

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

On Wed, 2007-04-18 at 16:02 +0200, Luigi Ballabio wrote:
> Aren't we going a bit too far? I mean, there's one evolver per subfolder
> right now---with some subfolders being empty, too. At this point, this
> much structure looks to me like a burden more than a help---especially
> since using Doxygen, we can easily generate a reference page where all
> the evolvers are listed and where it is stated whether each one is
> normal/lognormal and what rate type they evolve.

I just stumbled into another problem with an elaborate folder
structure---"make dist" currently fails to produce the tarball of the
library (tar insists on file paths being no longer than 99 characters.)

Later,
	Luigi


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

Brady's First Law of Problem Solving: 
When confronted by a difficult problem, you can solve it more 
easily by reducing it to the question, "How would the Lone 
Ranger have handled this?" 

[Quantlib-dev] Repository maintenance

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

Hi all,
	just a quick note to announce that this Saturday and Sunday I'll be
performing some maintenance on the Subversion repository. Please do not
perform any commits during that time since it might result in your
changes being lost.

Later,
	Luigi


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

When all else fails, pour a pint of Guinness in the gas tank, 
advance the spark 20 degrees, cry "God Save the Queen!", and pull 
the starter knob. 
-- MG "Series MGA" Workshop Manual 

Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: [10238] trunk/QuantLib/ql/models/marketmodels

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

On Wed, 2007-04-18 at 14:40 -0700, dr...@us... wrote:
> Revision: 10238
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=10238&view=rev
> Author:   drjoe
> Date:     2007-04-18 14:40:50 -0700 (Wed, 18 Apr 2007)
> 
> Log Message:
> -----------
> fix automake files.
> the build is causing new all.hpp files to be created, these should
> probably be removed

Never mind, Joe. I'll fix those on the release branch once the tree is
stable.

Thanks anyway,
	Luigi


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

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

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

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

On Wed, 2007-04-18 at 10:19 -0700, na...@us... wrote:
> Revision: 10231
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=10231&view=rev
> Author:   nando
> Date:     2007-04-18 10:19:55 -0700 (Wed, 18 Apr 2007)
> 
> Log Message:
> -----------
> refactoring/renaming/moving (part 1): using TimeDependantCorrelationStructure for achiving correlation model abstraction

Just a thought: isn't the name TimeDependantCorrelationStructure
redundant? (the general case being time dependence, and the constant
case being a specialized one.) Maybe just CorrelationStructure?

Later,
	Luigi


P.S. Believe it or not, the quotation below was chosen at random by my
mail client among about one hundred...

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

Perfection is reached, not when there is no longer anything to add, but 
when there is no longer anything to take away. 
-- Antoine de Saint-Exupery 

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

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

On Wed, 2007-04-18 at 18:31 +0200, Ferdinando Ametrano wrote:
> I've created the folder structure that I feel will be ok for proper
> categorization of all evolvers we're going to develop and which will
> be much more than the current 7.

Assuming that categorization should be done by means of the folder
structure and not, say, by documentation. I'm not opposing it, I'm just
pointing out it's an assumption. You know I'm picky...

> The possible evolvers I would like to see in QuantLib are about 6 (pc,
> ipc, euler, capc, cani, and PPR terminal measure) for each of the 6
> dynamics (log-normal cot swap rate, log-normal cm swap rate,
> log-normal fwd rate, normal cot swap rate, normal cm swap rate, normal
> fwd rate)

I confess my ignorance here (it's a while since I looked at the
evolvers, and some I haven't seen yet) but can't the 6 evolvers and the
6 dynamics be made orthogonal? Do we really need 36 distinct classes?

> As a matter of fact the folder reorganization was just the step before
> asking for volunteers to implement the next batch of 6 evolvers: ipc
> and euler for log-normal coterminal, log-normal constant maturity swap
> rates, and normal fwd rates. The task is not hard and given the
> current 7 evolvers is mostly copy/paste/adapt (and hopefully test).

Coding these 6 might be ok, but once we get to 13 (or maybe sooner than
that) it might be worthwhile to step back and look at the differences
between the various evolvers to see if anything can be abstracted (and
since the task is mostly copy/paste/adapt, there should be plenty.) In
an ideal world, we might be able to declare specific evolvers as
   Evolver<NormalFwd,IPC>
which would remove the need for categorization altogether.

However, since we're about to branch for the next release and any
further work on the evolvers will likely be done afterwards, do you have
anything against my _temporarily_ reverting the folder structure for
such release?

> Any volunteer would get a lot of credit for not so much work ;-) and
> it would be a good chance to get familiar with the current code base.

True. People, please give a though to this request.

Later,
	Luigi


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

Steinbach's Guideline for Systems Programming: 
Never test for an error condition you don't know how to handle. 

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

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

Hi Luigi and all

I've created the folder structure that I feel will be ok for proper
categorization of all evolvers we're going to develop and which will
be much more than the current 7.

The possible evolvers I would like to see in QuantLib are about 6 (pc,
ipc, euler, capc, cani, and PPR terminal measure) for each of the 6
dynamics (log-normal cot swap rate, log-normal cm swap rate,
log-normal fwd rate, normal cot swap rate, normal cm swap rate, normal
fwd rate)

As a matter of fact the folder reorganization was just the step before
asking for volunteers to implement the next batch of 6 evolvers: ipc
and euler for log-normal coterminal, log-normal constant maturity swap
rates, and normal fwd rates. The task is not hard and given the
current 7 evolvers is mostly copy/paste/adapt (and hopefully test).
Any volunteer would get a lot of credit for not so much work ;-) and
it would be a good chance to get familiar with the current code base.

ciao -- Nando

On 4/18/07, Luigi Ballabio <lui...@gm...> wrote:
> On Wed, 2007-04-18 at 16:02 +0200, Luigi Ballabio wrote:
> > Aren't we going a bit too far? I mean, there's one evolver per subfolder
> > right now---with some subfolders being empty, too. At this point, this
> > much structure looks to me like a burden more than a help---especially
> > since using Doxygen, we can easily generate a reference page where all
> > the evolvers are listed and where it is stated whether each one is
> > normal/lognormal and what rate type they evolve.
>
> Moreover, since there were just 7 evolvers in the folder and since you
> had done a good job in naming them properly, it was hardly any difficult
> to find what one was looking for...
>
> Luigi

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

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

On Wed, 2007-04-18 at 16:02 +0200, Luigi Ballabio wrote:
> Aren't we going a bit too far? I mean, there's one evolver per subfolder
> right now---with some subfolders being empty, too. At this point, this
> much structure looks to me like a burden more than a help---especially
> since using Doxygen, we can easily generate a reference page where all
> the evolvers are listed and where it is stated whether each one is
> normal/lognormal and what rate type they evolve.

Moreover, since there were just 7 evolvers in the folder and since you
had done a good job in naming them properly, it was hardly any difficult
to find what one was looking for...

Luigi


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

Prediction is very difficult, especially if it's about the future. 
-- Niels Bohr 

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

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

On Wed, 2007-04-18 at 06:46 -0700, na...@us... wrote:
> Revision: 10219
>           http://quantlib.svn.sourceforge.net/quantlib/?rev=10219&view=rev
> Author:   nando
> Date:     2007-04-18 06:46:40 -0700 (Wed, 18 Apr 2007)
> 
> Log Message:
> -----------
> evolvers classified in their own folder tree, depending on rate type (fwd, cotswap, cmswap) and dynamic (normal, lognormal)

Aren't we going a bit too far? I mean, there's one evolver per subfolder
right now---with some subfolders being empty, too. At this point, this
much structure looks to me like a burden more than a help---especially
since using Doxygen, we can easily generate a reference page where all
the evolvers are listed and where it is stated whether each one is
normal/lognormal and what rate type they evolve.

Thoughts?
	Luigi


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

What is written without effort is, in general, read without pleasure. 
-- Samuel Johnson 

Re: [Quantlib-dev] long andpossiblyinifiniteobserver/observablenotifying loops ->erratum

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

Sorry to spam your mailboxes folks, the CapStripper dependencies graph =
was slightly wrong in that FloatingRateCoupon is not observing the YC =
directly. Anyway, the problem remains the same...
Fran=E7ois

-----Original Message-----
From: qua...@li... =
[mailto:qua...@li...] On Behalf Of DU =
VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI
Sent: marted=EC 17 aprile 2007 15.42
To: qua...@li...
Subject: Re: [Quantlib-dev] long =
andpossiblyinifiniteobserver/observablenotifying loops



Hi all,

Sorry to insist a little more on the market data dependencies removal. =
(Since the next release won't be backward compatible it is now or =
never!).=20
I would like to draw your attention on another shortcomings of the =
current indexes design. The YC bootstraping procedure needs swaps which =
need indexes which in turn refer to a fake YC. IMO this is the kind of =
hack which might cause nasty bugs or mislead users at least.

Regards,
Fran=E7ois

PS: One might argue that precising the YC at index level allows to =
distinguish between forward and discounting YC. Even if it is a nice =
feature (on purpose ?) I think that it could also be allowed if YC are =
known by pricing engines only.

-------------------------------------------------------------------------=

This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

Re: [Quantlib-dev] long and possiblyinifiniteobserver/observablenotifying loops

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

Hi all,

Sorry to insist a little more on the market data dependencies removal. =
(Since the next release won't be backward compatible it is now or =
never!).=20
I would like to draw your attention on another shortcomings of the =
current indexes design. The YC bootstraping procedure needs swaps which =
need indexes which in turn refer to a fake YC. IMO this is the kind of =
hack which might cause nasty bugs or mislead users at least.

Regards,
Fran=E7ois

PS: One might argue that precising the YC at index level allows to =
distinguish between forward and discounting YC. Even if it is a nice =
feature (on purpose ?) I think that it could also be allowed if YC are =
known by pricing engines only.

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

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

Hi all,

After further inquiries I have found out  what was going wrong in =
notification chains. Indeed, I discovered that the main culprit was the =
CapStripper. A drawing being worth more than thousand words (especially =
if your command of English is poor ;-) I have attached a picture showing =
dependencies between objects for the stripping of 3M volatilities. Let =
me point out that is only one part of the problem because this =
CapStripper is observed by another one which strips the 6M libor caps...
The fix proposal I tried to described last time is to make LazyObjects =
notifying their observers only once until they are recomputed. ( I hope =
it is clear enough this time).
This solves the problem quite efficiently (apart from the fact that all =
objects inheriting from TermStructure notify their observers twice =
systematically). Yet I can't refrain myself from suggesting further =
design improvements. What about removing all market data dependencies =
from instruments and indexes definitions ?  Not only it would simplify =
notifications chains, but it would also decouple Instrument/Indexes =
implementation from market data implementations.
Regards,
Fran=E7ois

[Quantlib-dev] HullWhiteProcess question

[<Paw...@ha...>]

Hello

Currently HullWhiteProcess::alpha(Time t) looks like this:
        Real alfa = a_ > QL_EPSILON ?
                (sigma_/a_)*(1 - std::exp(-a_*t)) :
                sigma_*t;
        alfa *= 0.5*alfa;
        alfa += h_->forwardRate(0.0,0.0,Continuous,NoFrequency);
        return alfa;

This looks to me like it would make the process revert to the time 0 short 
rate, while the rest of the curve gets ignored. I think that maybe the 
fifth line should read:
alfa += h_->forwardRate(t,t,Continuous,NoFrequency);

Also, if my understanding of HullWhiteForwardProcess is correct, then a 
similar line in HullWhiteForwardProcess::alpha(Time ) might need changing 
to:
alfa += h_->forwardRate(t, t + T_, Continuous, NoFrequency);

And HullWhiteForwardProcess::x0() should probably return:
h_->forwardRate(0.0, T_, Continuous, NoFrequency);
rather than the current:
process_->x0();

Of course the chances are I'm missing something, in which case I'll 
appreciate a pointer in the right direction.

Thank you,
Pawel

*************************************************************************
This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential and/or privileged information.  If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution is
strictly prohibited.  If you are not the intended recipient, please notify
the sender immediately by return e-mail, delete this communication and
destroy all copies.
*************************************************************************

Re: [Quantlib-dev] Subversion glitches

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

On Mon, 2007-04-16 at 11:15 +0200, Ferdinando Ametrano wrote:
> > 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.

Also, I might note (since I might not have been very clear) that
regrouping would follow your favorite approach as described above.

Later,
	Luigi


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

A programming language is low-level when its programs require attention 
to the irrelevant. 
-- Alan Perlis