Currently sparseIterator is only used in RealVector, no matrix class will be affected, because there is no sparseIterator. Search you sources for "sparseIterator" ?
Arne Am Dienstag, den 16.08.2011, 14:09 -0700 schrieb Ted Dunning: > Here is an example from the perspective of somebody adding a new kind of > matrix. > > Take the two kinds of matrix as RandomTrinaryMatrix(rows, columns, p) that > has elements that are -1, 0 or 1. 1 and -1 have equal probabilities of p/2. > The value of p should be in [0,1]. > > It would be very nice if the implementor of this matrix could extend an > abstract matrix and over-ride get() to generate a value and set() to throw > an unsupported operation exception. If p < 0.1, then the matrix should be > marked as sparse, else as dense. > > All operations against other matrices, sparse or dense should work well > without any special handling by the implementor of this matrix. > > This works in Mahout for instance by having the default operations in > AbstractMatrix test for sparseness of left or right operands and do the > right thing. Obviously, a type test will not tell you whether this matrix > is sparse or not. > > This matrix and siblings is very important in compressed sensing and > stochastic projection algorithms. > > On Tue, Aug 16, 2011 at 1:55 PM, Phil Steitz <phil.ste...@gmail.com> wrote: > > > On 8/16/11 4:46 AM, Gilles Sadowski wrote: > > > Hi. > > > > > >> I understood what he was suggesting. I still disagree. Dynamic > > dispatch > > >> and non-lattice typing structure is still required to make this all > > work. > > >> Java doesn't really do that. Pretending that what Java does is > > sufficient > > >> is hammer-looking-for-a-nail, not solving the problems at hand. > > > Maybe that *I* don't understand what you are hinting at. Sorry for being > > > dense. [Although that seems appropriate in this discussion :-).] > > > > > > Polymorphism provides dynamic dispatch, overloading does not; that's why > > my > > > proposition is that when you manipulate "unknown" types, those should > > come > > > as "this", not as the argument of the method. > > > > > > What's wrong with that? > > > > > > As for "hammer-looking-for-a-nail", I also don't see what you mean: What > > is > > > the problem? I guess that there are lots of applications who never need > > to > > > know about sparse vectors/matrices. In those cases, the added complexity > > is > > > not a "feature". The issue reported contends that the current design in > > CM > > > can cause problems for dense implementations. I'm not even sure that the > > > current design is usable for the type of applications that make heavy use > > of > > > sparseness. Those are problems, IMHO. > > > > I have been out of pocket the last couple of days and may not have > > time to dig into this until late tonight, but I agree with Gilles > > that we need to get the conversation here more concrete. I know we > > discussed this before and Ted and others had good examples > > justifying the current setup. Can we revisit these, please? What > > would be great would be some examples both from the perspective of > > the [math] developer looking to add a new or specialized class and > > [math] users writing code that leverages the setup. > > > > Phil > > > > > > > > > Gilles > > > > > >> On Mon, Aug 15, 2011 at 6:52 PM, Greg Sterijevski < > > gsterijev...@gmail.com>wrote: > > >> > > >>> Forgive me for pushing my nose under the tent... I couldn't resist. > > >>> > > >>> I think Gilles is saying that each specialization of the matrix/vector > > >>> objects would need to support pre (and post) multiplication with a > > dense. > > >>> So > > >>> the type issue would not be problematic. > > >>> > > >>> On Mon, Aug 15, 2011 at 6:34 PM, Ted Dunning <ted.dunn...@gmail.com> > > >>> wrote: > > >>> > > >>>> No. > > >>>> > > >>>> You can't. This is because the type is lost as you enter the generic > > >>>> library. > > >>>> > > >>>> On Mon, Aug 15, 2011 at 4:28 PM, Gilles Sadowski < > > >>>> gil...@harfang.homelinux.org> wrote: > > >>>> > > >>>>>> They know that their own object is dense, but they don't know what > > >>> kind > > >>>>> of > > >>>>>> input they were given. They should still run fast if the input is > > >>>>> sparse. > > >>>>> > > >>>>> Couldn't we still rely on polymorphism by implementing "preTimes": > > >>>>> unknown.preTimes(dense) > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
