Plans for future releases and call for contributions

[Luigi Ballabio]

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

[Bianchetti Marco]

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

[Alan King-2]

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

-------------------------------------------------------------------------
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

[Toyin Akin]

Hi all,

I've looked at GSL in the past and it's quite an impressive library.

The only problem with it is that you cannot use it within a commercial
application... unless that rule has changed recently.

Toy out.

>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
>
>
>

>-------------------------------------------------------------------------
>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

_________________________________________________________________
Solve the Conspiracy and win fantastic prizes.  
http://www.theconspiracygame.co.uk/



-------------------------------------------------------------------------
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

[steve.affine]

Luigi Ballabio wrote

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.

I think this is great news, and look forward to the official release.

I'm spending a bit of time with QuantLib for some securities consulting work at Affine, and one general comment about QuantLib is that IMHO it's fairly complex to use if you just want to do some simple option pricing.
a) I think it would be great if we can produce some high-level documentation/tutorials on how the class library is designed, what are the fundamental classes (Instrument, PricingEngine etc) and how these hang together.
b) I think it would also be valuable if we can write some simple facade classes (or example code) for e.g. vanilla B&S/Binomial where you can just pass in a simple instrument definition (strike, put/call, expiry etc.), pricing parameters (underlying, vol, rate) and get the NPV and greeks (maybe based on the EquityOption.cpp example).

I would imagine that (a) would need to be done by one of the core developers, but I'd be happy to contribute on (b) if it's something we feel would be useful.

cheers
Steve

affine group limited
http://www.affine.hk

[Xiaoming Lai]

Luigi & all,

I know it is a late reply.
But today when I got time to review the historical emails, I think that it is a time for me to contribute something back to the project.

I had kept an eye on this project for more than three years, I really learned a lot from all people and project itself.

I will work the mortgage pricing as the start.

Thanks,
Xiaoming

----- Original Message -----
From: "Luigi Ballabio" <[hidden email]>
To: "QuantLib developers" <[hidden email]>
Sent: Friday, March 16, 2007 10:27 PM
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

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Luigi Ballabio]

On Thu, 2007-05-17 at 23:47 +0800, Xiaoming Lai wrote:
> I know it is a late reply.

No problem. We all have real works.

> But today when I got time to review the historical emails, I think that it is a time for me to contribute something back to the project.
>
> I had kept an eye on this project for more than three years, I really learned a lot from all people and project itself.
>
> I will work the mortgage pricing as the start.

Ok. Do you need any pointers on how to get started, or how to integrate
your code with the rest of the library?

Later,
        Luigi


----------------------------------------

Blessed is the man who, having nothing to say, abstains from giving
wordy evidence of the fact.
-- George Eliot



-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev

[Xiaoming Lai]

Luigi,

I'd like to implement the 30yr fixed rate mortgage with the PSA model as the
start, and extend it to the other mortgage types and other advanced
prepayment models later.

Thanks,
Xiaoming


----- Original Message -----
From: "Luigi Ballabio" <[hidden email]>
To: "Xiaoming Lai" <[hidden email]>
Cc: "QuantLib developers" <[hidden email]>
Sent: Tuesday, May 22, 2007 12:18 AM
Subject: Re: [Quantlib-dev] Plans for future releases and call
forcontributions

> On Thu, 2007-05-17 at 23:47 +0800, Xiaoming Lai wrote:
>> I know it is a late reply.
>
> No problem. We all have real works.
>
>> But today when I got time to review the historical emails, I think that
>> it is a time for me to contribute something back to the project.
>>
>> I had kept an eye on this project for more than three years, I really
>> learned a lot from all people and project itself.
>>
>> I will work the mortgage pricing as the start.
>
> Ok. Do you need any pointers on how to get started, or how to integrate
> your code with the rest of the library?
>
> Later,
> Luigi
>
>
> ----------------------------------------
>
> Blessed is the man who, having nothing to say, abstains from giving
> wordy evidence of the fact.
> -- George Eliot
>
>

-------------------------------------------------------------------------
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
_______________________________________________
QuantLib-dev mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/quantlib-dev