Sujit Pal a écrit : > Hello, > > I am a new, but fairly happy user of commons-math 1.2 and I have begun > to use it in my code. I needed a sparse matrix implementation for some > data analysis work I was doing, and unfortunately the code with > RealMatrixImpl was coming back with an OOME. So I built a > SparseRealMatrixImpl as a subclass of RealMatrixImpl, which uses a > Map<Point,Double> as its backing store, storing only the non-zero > entries. I would like to contribute this implementation back to the > commons-math project. > > I have opened a JIRA enhancement request MATH-230 with a patch against > the 2.0 branch. Patch and detailed description of the changes are > available here. > http://issues.apache.org/jira/browse/MATH-230 > > I have also had to make some changes to RealMatrixImpl and > LUDecompositionImpl, mainly replacing the data[][] references with > RealMatrix.getEntry(i,j) calls to insulate the backing store from being > accessed directly by calling code, and thus making it possible for > subclasses to provide their own internal backing stores. > > Would appreciate if you folks can take a look and let me know if it is > feasible to add this into the 2.0 release. That way I can continue using > commons-math future versions without having to patch it after every > upgrade.
I'll have a look at it tomorrow evening. For now, one thing that bother me is the removal of the dedicated code that explicitely avoided getEntry(). This was added a few months ago for performance reason, since the previous generic code was painfully slow. The trick with the ClassCastException allows really fast check since the virtual machine can completely optimize it out in some cases, it is an enhancement of what was discussed here: http://markmail.org/message/36fgg7vx6gzd3ziu. Our discussion at that time was that the more common case (RealMatrixImpl) should be as efficient as possible (and Ted wants now it to be even faster by changing the underlying storage which is a good thing). This trick is not beautiful perfectly generic code, it is a pragmatic way to be fast in a common case and removing it will most probably induce poorer performances. Luc > > I noticed that there has been some previous discussion about sparse > matrix support here: > http://markmail.org/message/2k5dk4fbewdtn5rz > so I sent a personal email to John Iacona asking him about about the > code he speaks of here. But he is working on other things, and doesn't > know when he will be able to check in his sparse matrix support changes. > His approach is a little different from mine (he has a SparseMatrix > interface, which is implemented by a SparseMatrixImpl). I considered > that approach initially, but came to the conclusion that it would mean > quite a bit of code duplication, which I wanted to avoid as far as > possible. > > Thanks > -sujit > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
