commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sujit Pal <sujit....@comcast.net>
Subject Re: [math] patch submitted for commons-math sparse matrix support
Date Mon, 01 Dec 2008 22:31:52 GMT
Hi Ted,

I considered that possibility too, peeked at one of the posts where this
representation was suggested :-).

Pros:
1) the representation is more elegant.

Cons:
1) it would have required me to implement SparseVector, which we should
do anyway, imo. But I wanted to keep the code changes to a minimum.
2) possibly greater memory usage, since we have reference to a bunch of
maps hanging off the int key. The Point class is a private inner class
so it is invisible outside the class and unlike the java.awt.Point,
contains almost no baggage, its simply a struct with equals() and
hashCode() implemented.

Speed wise, I don't think there is going to be much difference between
either approach. The current approach has some overhead in building up
the Point object for each getEntry() and setEntry() call, and the one
you suggest has an overhead to do the double lookup. Either one is
instantaneous for all practical purposes.

However, if Map<Integer,SparseVector> data structure is preferred, the
only methods that need to change are the getEntry() and setEntry()
methods of SparseRealMatrixImpl, which I can do if needed.

On a slightly different note, I've been thinking about some other ways
to reduce the memory footprint (of my application), and I think there
may be some justification for having things like ConstantVector, ie a
large non-sparse Vector which contains the same data for all its
elements. The idea is similar, the getEntry() method would return a
value that is set into the constructor.

-sujit

On Mon, 2008-12-01 at 14:13 -0800, Ted Dunning wrote:
> Sujit,
> 
> What do you think the trade-offs are between the representation that you
> used and another one where you have a Map<int, SparseVector> that contains
> rows or columns?
> 
> On Mon, Dec 1, 2008 at 1:40 PM, Sujit Pal <sujit.pal@comcast.net> wrote:
> 
> > 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
> >
> >
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message