Menu
▾
▴
quantlib-dev
|
From: Luigi B. <lui...@gm...> - 2007-04-18 14:02:25
|
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 |
|
From: Luigi B. <lui...@gm...> - 2007-04-18 16:13:11
|
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 |
|
From: Ferdinando A. <na...@am...> - 2007-04-18 16:31:24
|
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 |
|
From: Luigi B. <lui...@gm...> - 2007-04-18 16:50:53
|
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. |
|
From: Luigi B. <lui...@gm...> - 2007-04-19 13:06:36
|
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?" |
|
From: Ferdinando A. <na...@am...> - 2007-04-20 21:27:08
|
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 |
|
From: Luigi B. <lui...@gm...> - 2007-04-23 10:08:14
|
On Fri, 2007-04-20 at 23:27 +0200, Ferdinando Ametrano wrote: > On 4/19/07, Luigi Ballabio <lui...@gm...> wrote: > > 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. Ok, thanks. Speaking of tarballs, how about branching for release? Later, Luigi ---------------------------------------- Hofstadter's Law: It always takes longer than you expect, even when you take Hofstadter's Law into account. |
|
From: DU V. DE V. F. G. P. <fra...@ca...> - 2007-04-23 13:22:12
|
>> Integration refactoring in progress: >> the old GaussKronrod class has been renamed in = GaussKronrodNonAdaptive >and adapted to the new framework, client code = and tests updated accordingly >Francois, > may you describe the new framework? What do we gain with respect to = >the >previous implementation? Well, maybe new framework was a bit exagerated, however here are the = improvements you should gain: ->all the cumbersome implementation code will be moved in cpp file ->all Integrators will derive from the same base class and share some = common code. This standardization might help users to use and compare different = integrations algorithms in a more convenient way. I intend to ask people = to review this new framework when it will be finished. If you want to = start now please feel free... :-) Fran=E7ois |
|
From: Luigi B. <lui...@gm...> - 2007-04-23 13:41:57
|
On Mon, 2007-04-23 at 15:22 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI wrote: > >Francois, > > may you describe the new framework? What do we gain with respect to >the > >previous implementation? > > Well, maybe new framework was a bit exagerated, however here are the improvements you should gain: > > ->all the cumbersome implementation code will be moved in cpp file Yes, that's a big plus. Switching to boost::function was a good idea. > ->all Integrators will derive from the same base class and share some common code. Ok. I'm still not sure whether or not the base class should be virtual, but the principle is sound. > I intend to ask people to review this new framework when it will be > finished. If you want to start now please feel free... :-) No, just go ahead. I'll have a look at it when it's finished. Later, Luigi ---------------------------------------- Cogito ergo I'm right and you're wrong. -- Blair Houghton |
|
From: DU V. DE V. F. G. P. <fra...@ca...> - 2007-04-26 10:56:39
|
> shouldn't they be removed from SegmentIntegral's constructor? Sure I will fix that asap, Fran=E7ois |
|
From: DU V. DE V. F. G. P. <fra...@ca...> - 2007-05-07 17:31:45
|
It should be reviewed by Ferdinando because I'm not sure that the = results are satisfactory, and also because it is not integrated in the = pseusodsqrt function yet. When is the 0.8.0 release to be packaged ?=20 Fran=E7ois -----Original Message----- From: qua...@li... = [mailto:qua...@li...] On Behalf Of Luigi = Ballabio Sent: Monday, May 07, 2007 6:21 PM To: qua...@li... Subject: Re: [Quantlib-dev] [QuantLib-svn] SF.net SVN: quantlib: = [10623]trunk/QuantLib On Mon, 2007-05-07 at 09:10 -0700, fd...@us... wrote: > Revision: 10623 > = http://quantlib.svn.sourceforge.net/quantlib/?rev=3D10623&view=3Drev > Author: fdv1 > Date: 2007-05-07 09:10:52 -0700 (Mon, 07 May 2007) >=20 > Log Message: > ----------- > triangularAnglesParametrization ready to be reviewed Does this mean it wasn't ready before? Should I exclude it from the 0.8.0 release? Later, Luigi ----------------------------------------=20 Though this be madness, yet there is method in't.=20 -- Hamlet, Act II, scene II=20 -------------------------------------------------------------------------= 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 |
|
From: Luigi B. <lui...@gm...> - 2007-05-08 07:06:03
|
On Mon, 2007-05-07 at 19:31 +0200, DU VIGNAUD DE VILLEFORT FRANCOIS GASAPRD PHI wrote: > It should be reviewed by Ferdinando because I'm not sure that the results are satisfactory, and also because it is not integrated in the pseusodsqrt function yet. When is the 0.8.0 release to be packaged ? I'll try and release 0.8.0 this month. Don't hurry though, it's not a problem if it doesn't make this release. We still have another release before 1.0, so take your time. Later, Luigi ---------------------------------------- Green's Law of Debate: Anything is possible if you don't know what you're talking about. |
|
From: DU V. DE V. F. G. P. <fra...@ca...> - 2007-06-19 17:22:16
|
>No, this is not correct. If the nodes are far apart, there's nothing >that forbids the discount at a node to be less than half of the = previous >value; yet you're preventing such a curve from bootstrapping. I agree with you that even if this is unlikely to happen it is not = satisfactory to leave such a hole. Let say that it is a quick fix. >If the minimum at 0 was wrecking havoc on the spline, we could use the >other solve() method in Solver1D, namely, the one that takes a guess = and >a step and tries to bracket the solution on its own. It's going to be >slower, but probably more robust. Thanks for your suggestion, I was not aware of this method,=20 Fran=E7ois |
