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