Road to 1.0
Locked
 
|
Hi all, I guess we should start making plans if we want to get release 1.0 out this year. Here's what I'm thinking: please follow up if you have any comments or additions. Thanks, Luigi ----------------------------------------------- 1) scope of the release: What we have now, plus the contributions I had in the past few months. They include credit and commodity frameworks, which are the most important pieces we're missing. I'll add them to the repository during the next weeks. 2) goals: - Coverage (which is pretty much ok, see point (1) above.) - Documentation. Not quite enough right now. At the very minimum, we should add more examples to showcase other parts of the library (bond calculations spring to mind, for instance.) - Stability (which has been a sore point for the last few releases.) The idea is that client code written against 1.0 should keep compiling against any future 1.x.y release. This means that once 1.0 is out, the interfaces cannot be changed (note that since we're providing a library, the interfaces include the protected methods and data members,) files cannot be renamed or moved, and code cannot be moved from one header file to another. Of course, new files, classes, methods and/or data members can still be added. Three notes: a) one way to ensure stability is to freeze the test-suite and example code. We can add new examples and test cases, but the existing ones should not be changed. This will give us a decent code base (about 50k lines) against which backward compatibility can be checked. b) we should determine what interfaces still need to be changed (as in "agree on a list and stick to it", more on this in point (4) below) and make the changes before 1.0. c) This does not apply to stuff in the ql/experimental folder, which is fair game until it's moved out (at which point, it freezes.) 3) schedule: shortly before 1.0, I'd put out a 0.9.9 release---kind of a beta, if you like. We might call it 1.0b1, too, but I suspect that more people will try it out if there's no "beta" label attached. Release 1.0 would come out about a month after, when we've seen that there's no obvious problems in 0.9.9. The release branch for 1.0 might actually be made from the 0.9.9 branch, to ensure that new stuff on the trunk doesn't break anything. The 0.9.9 interfaces should be almost frozen---changes from 0.9.9 to 1.0 should have a compelling reason. Depending on how fast we're working, 0.9.9 might be the next release. But it seems more probable that we'll have a 0.9.5 in April or May, the 0.9.9 in the summer, and the 1.0 shortly after. 4) list of breaking changes: The ones that I would make are: - engine refactoring for a few instruments (asset swap, variance swap, inflation swaps...) The idea is to put market data in the engine, as we did for swaps and bonds. - decrease the number of template parameters in IterativeBootstrap, from <Curve,Traits,Interpolator> to just <Curve>. The other parameters can be retrieved from the curve as typedefs. It increases a bit the readability, and shouldn't break much code (I doubt that many people wrote their own curve based on it yet.) - clearer instantiation of a few Monte Carlo engines, by replacing withTolerance() with both withRelativeTolerance() and withAbsoluteTolerance(). The ambiguity has bitten us already in the past. - finally, if I can make a request (most likely, I won't be doing this one myself): would it be possible to have a look at the SwaptionVolCube1 and SwaptionVolCube2 classes and see whether they can be merged? At least, they should be given names that describe their differences. -- 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. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
Hi Luigi and the rest,
Thanks a lot for showing us such a clear picture about future 1.0 release! I just have one addition: - modify the interfaces of finite difference pricing engines (like FDEuropeanEngine class) so that users can specifiy different solver (Explicit, Implicit or Crank-Nicolson) and different asset price range. Currently the solver is fixed to Crank-Nicolson. Does this change make sense to you? and any advice? Cheers, Max On Feb 16, 2008 12:07 AM, Luigi Ballabio <[hidden email]> wrote: > > 4) list of breaking changes: > The ones that I would make are: > > - engine refactoring for a few instruments (asset swap, variance swap, > inflation swaps...) The idea is to put market data in the engine, as we > did for swaps and bonds. > > - decrease the number of template parameters in IterativeBootstrap, from > <Curve,Traits,Interpolator> to just <Curve>. The other parameters can be > retrieved from the curve as typedefs. It increases a bit the > readability, and shouldn't break much code (I doubt that many people > wrote their own curve based on it yet.) > > - clearer instantiation of a few Monte Carlo engines, by replacing > withTolerance() with both withRelativeTolerance() and > withAbsoluteTolerance(). The ambiguity has bitten us already in the > past. > > - finally, if I can make a request (most likely, I won't be doing this > one myself): would it be possible to have a look at the SwaptionVolCube1 > and SwaptionVolCube2 classes and see whether they can be merged? At > least, they should be given names that describe their differences. ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
|
|
On Mon, 2008-02-18 at 10:00 +0800, Max wrote:
> I just have one addition: > - modify the interfaces of finite difference pricing engines (like > FDEuropeanEngine class) so that users can specifiy different solver > (Explicit, Implicit or Crank-Nicolson) and different asset price > range. Currently the solver is fixed to Crank-Nicolson. > > Does this change make sense to you? and any advice? Hmm, you're right. I'll have to look into it... Luigi -- Things should be made as simple as possible, but no simpler. -- Albert Einstein ------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ _______________________________________________ QuantLib-dev mailing list [hidden email] https://lists.sourceforge.net/lists/listinfo/quantlib-dev |
«
Return to quantlib-dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |