commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Arne Ploese <aplo...@gmx.de>
Subject Re: [Math] "iterator" and "sparseIterator" in "RealVector" hierarchy
Date Wed, 17 Aug 2011 15:29:51 GMT
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 <aploese@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.steitz@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 <
> > > > 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 <
> > ted.dunning@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 <
> > > > >>>> 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
> >
> >



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


Mime
View raw message