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 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 <
> > gsterijevski@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
> > >>> 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 <
> > >>>> gilles@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-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
> >
> >
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org