commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gilles Sadowski <>
Subject Re: [math] OpenGamma library
Date Fri, 14 Oct 2011 21:12:14 GMT

> I believe that the BlockMatrix approach you have taken is actually quite
> good and might yield a bit more stable optimization improvement than simple
> loop unrolling. Consider operations on non-overlapping blocks. You could
> easily dispatch those in parallel. I agree that it is a bit painful to use,
> but in solver (for example) it is very quick. I would not be quick to
> dispatch it. Its taken me a couple of months to appreciate its subtle
> elegance. There is many more tricks you can play with your approach. Also,
> don't forget the timings they present are for one very specific
> operation-one where the block approach is at a slight disadvantage.
> One place where the Open Gamma approach is better is using single dimension
> arrays, but that's not compatible with your block approach. If you recall, I
> asked to add a SymmetricMatrix implementation storing the data in a single
> dimension array with compressed row major storage. That proposal was not
> well received.

I might have missed the goal of your proposal but I think that main point
of the discussion had been about having a separate class for operations. I
don't recall that a new implementation ("SymmetricMatrix") with a
specifically optimized storage was not approved.

In fact, it has been a few weeks that I wanted to ask whether someone would
be interested in providing a symmetric matrix; the primary motivation for me
would be that it will simplify some code in "BOBYQAOptimizer".
I see no reason why you would not be welcome to create a new
"SymmetricMatrix" class.

> I suspect when the time comes to debate 'their' approach with
> the commons approach the same issues will crop up.
> On other aspects, the group will not like use of factories. They seem to be
> everywhere in the code. Again, there is reticence in this community with
> respect to non constructor construction.

This is not an accurate summary of the discussion we had on that subject.
The point (mine, at least) was not that we should or should not use
factories; it was that we should not mix both styles. As it happens, the
codebase is currently written with the "explicit" construction style (and
the rare uses of factories that still existed in 2.2 were not appropriate
IMHO), so the argument went that the proponents of factories did not provide
explicit examples of why the codebase should be moved to another paradigm (I
recall people only saying: "I like factories").

Finally, I can connect this with what you report about "OpenGamma" being a
framework for finance computations; the keyword is "framework" which CM is
not: It's "just" a low-level library, a collection of algorithms not
targetted toward a specific application domain.  My impression is that is
much easier to get the framework wrong for CM (meaning: not appropriate for
certain uses of those low-level tools).


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

View raw message