commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sujit Pal <sujit....@comcast.net>
Subject [math] patch submitted for commons-math sparse matrix support
Date Mon, 01 Dec 2008 21:40:08 GMT
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 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: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message