commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <>
Subject Re: [math] OpenGamma library
Date Fri, 14 Oct 2011 18:28:15 GMT
Le 14/10/2011 20:08, Greg Sterijevski a écrit :
> I looked more closely at the package and it am impressed with the breadth of
> material covered. Moreover, this package will do to finance what Mahout is
> doing to companies like SAS and SPSS. Having spent a good part of my career
> in finance, this package (and others) will put a lot of small 'analytics'
> companies out of business (as well as people like me). There is excellent
> coverage of pricing models (options and otherwise), fitting techniques (as
> it pertains to term structures, volatility surfaces and so forth), but the
> most impressive thing is that all of the functionality is presented in
> framework. You can integrate what is called front office functionality
> (trading, pricing, hedging) with middle and back office (risk and clearing)
> operations. Most closed source packages are not this good.
> So, a bit amateurish on the 'optimization' front, but the big picture is
> very strong. Comparable closed source packages like this would run upward of
> 1M USD.
> -Greg
> On Fri, Oct 14, 2011 at 11:24 AM, Phil Steitz<>  wrote:
>> On 10/14/11 7:47 AM, Emmanuel Bourg wrote:
>>> Hi,
>>> I just saw this article, that might be of interest for some of the
>>> [math] devs. They claim to have found an optimization that is 1.6
>>> times faster than Commons Math :
>> Thanks for sharing this.  We can certainly look at the specific case
>> and evaluate pros and cons; but it looks like there may be some
>> interesting areas for collaboration.  The license and CLA-type
>> thingy look compatible and it looks like there are [math]
>> dependencies and maybe some [math] source already used in there, so
>> it would be great to get some collaboration going.

Yes, this would be a very good thing. Our linear algabra is not fast, we 
already know that. I think we need to address several different needs 
like simple API, numerical accuracy, robustness and speed. We 
concentrated on robustness up to now, mainly because our SVD was really 
really bad on this point. Now that this part seems to be OK, I would 
very much like to see some speed improvements (and sparse matrices too, 
as we also suck at this).

Our block matrices implementation seems to improve some operations 
computation time, but it has a very awkward design and is not backed by 
any theoretical studies so it is probably also amateurish with respect 
to cache. I designed and wrote it but would really be happy to get rid 
of it and have it replaced by something more efficient. I would also 
like to know how it behaves in the article bench.

So a big +1 for collaboration if the author is ready for this.


>> Phil
>>> Emmanuel Bourg
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail:
>>> For additional commands, e-mail:
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail:
>> For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message