Re: Plans for future releases and call for contributions

Posted by Bianchetti Marco on
URL: http://quantlib.414.s1.nabble.com/Plans-for-future-releases-and-call-for-contributions-tp9272p9277.html

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