To an extent, I think you're making a good point (it's counterproductive not to use already existing components -- that's why I'm completely fine with dependence on Boost, BTW).On the other hand, one can argue that the entire project basically constitutes "reinventing QuantLib." Admittedly, the reply to this would be the difference in design goals (more lightweight, loosely coupled). Perhaps this reply could be applied to numerics layer as well -- now that you mention how hard it is to find one, I find it not entirely inconceivable that a demand for open-source (as opposed to free-software/GPL) numerical integration library could even be far greater than that for yet-another-quantfin-lib (YAQL -- hey, did I just find another name for the project? :>) -- just think of the applications (numerical integration is everywhere)! Hence, a numerics library with a nonrestrictive, commercial-friendly open-source license (like BSL) is a valid goal. On the third hand (...), the numerics layer is arguably not the sole goal of the project at hand (but perhaps it's fundamental enough to warrant special treatment?) and so the interest (and, consequently, no. of contributors) could suffer. I don't suppose we can afford (in terms of our collective time) a clean room reverse engineering of GSL routines?Alternatively, there might be something on http://netlib.org/
and there's also public-domain QUADPACK (http://en.wikipedia.org/wiki/QUADPACK
) (which raises questions in regards to PD-code).Incidentally, some good news: a dlib C++ library (http://dlib.net/
) has some interesting parts, e.g., http://dlib.net/optimization.html
and is BSL-licensed (http://dlib.net/license.html
). Let's hope others chime in.