>From: Alan King <
[hidden email]>
>To: "QuantLib developers" <
[hidden email]>
>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/>
>
>
>
[hidden email] 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:
[hidden email]
>
> > > [mailto:
[hidden email]] 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
>
> >
[hidden email]
>
> >
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
>
> >
[hidden email]
>
> >
https://lists.sourceforge.net/lists/listinfo/quantlib-dev>
>
>