Re: [Quantlib-dev] Plans for future releases and call for contributions

[Bianchetti M. <mar...@ca...>]

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? :-)=20

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.=20
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.=20

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.=20
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: qua...@li...=20
> [mailto:qua...@li...] On Behalf=20
> Of Luigi Ballabio
> Sent: 16 March 2007 15:28
> To: QuantLib developers
> Subject: [Quantlib-dev] Plans for future releases and call=20
> for contributions
>=20
>=20
>=20
> 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.
>=20
> 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=20
> few thoughts.
>=20
> Lately I started to have the feeling that our development model has
> reached its limit. Until now, development of the library has=20
> been pushed
> forwards by a few dedicated individuals and by occasional=20
> contributions
> by other people. However, there's only so much that this can=20
> achieve; as
> witnessed, to name a couple of examples, by the lack of user
> documentation and my systematic delay in answering posts to=20
> the mailing
> lists.
>=20
> 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.
>=20
> 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.
>=20
> Enough---and onwards to the plan for release 1.0.
>=20
> 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.
>=20
> 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=20
> documentation
> and general usability (a task which should already start for the
> upcoming releases.)
>=20
> 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=20
> afford or want
> to spare.
>=20
> The easiest way to contribute would be to subscribe to the=20
> QuantLib-dev
> mailing list (the subscription page can be found at
> <https://lists.sourceforge.net/lists/listinfo/quantlib-dev>.)=20
> 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.
>=20
> If you think you can get more involved, there's a number of=20
> other things
> you can do - apart from contributing code or patches to the=20
> library, of
> course. A few of them are:
>=20
> - answer questions on the QuantLib-users mailing list;
>=20
> - 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.
>=20
> - 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.
>=20
> - 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.
>=20
> 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.
>=20
> Thanks for listening. Comments are welcome.
>=20
> Later,
>         Luigi
>=20
>=20
> ----------------------------------------=20
>=20
> fix, n.,v.=20
> What one does when a problem has been reported too many times=20
> to be ignored.=20
> -- the Jargon file=20
>=20
>=20
>=20
> --------------------------------------------------------------
> -----------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the=20
> chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge
&CID=3DDEVDEV
_______________________________________________
QuantLib-dev mailing list
Qua...@li...
https://lists.sourceforge.net/lists/listinfo/quantlib-dev