Am Mittwoch, den 17.08.2011, 07:25 -0700 schrieb Ted Dunning: > Arne, > > Please read the thread again. I am providing an example of how I think > things *should* be. OK. if I understand you right: isSparse() should be added to RealVector and the interface SparseRealVector can be dropped?
> > The point of doing so is that things are not that way now. Telling me that > they are not that way is pretty redundant. > > On Wed, Aug 17, 2011 at 2:37 AM, Arne Ploese <aplo...@gmx.de> wrote: > > > 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 > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
