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.


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

Reply via email to