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
