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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
