Ted,
please just take your code and move Iterator<Entry> sparseIterator();
from RealVector to SparseRealvector. Look then at the compiler errors,
that are in most cases misuses of sparseIterator().
By the way most(all?) functions in CM return an array (dense)
impementation as return type.
You mention the method isSparse in your posts  there is currently no
such method, if you want to detect, if you have a sparse implementation
you will have to check for SparseRealvector. So there is no big deal in
a following cast to SparseRealVector to access sparseIterator().
As I am no math guru, I cant follow your example, some real code
probaply will do the trick.
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 override 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 nonlattice typing structure is still required to make this all
> > work.
> > >> Java doesn't really do that. Pretending that what Java does is
> > sufficient
> > >> is hammerlookingforanail, 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 "hammerlookingforanail", 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, email: devunsubscribe@commons.apache.org
> > > For additional commands, email: devhelp@commons.apache.org
> > >
> > >
> >
> >
> > 
> > To unsubscribe, email: devunsubscribe@commons.apache.org
> > For additional commands, email: devhelp@commons.apache.org
> >
> >

To unsubscribe, email: devunsubscribe@commons.apache.org
For additional commands, email: devhelp@commons.apache.org
