Return-Path: X-Original-To: apmail-commons-dev-archive@www.apache.org Delivered-To: apmail-commons-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 11356777A for ; Wed, 17 Aug 2011 09:30:50 +0000 (UTC) Received: (qmail 70636 invoked by uid 500); 17 Aug 2011 09:30:46 -0000 Delivered-To: apmail-commons-dev-archive@commons.apache.org Received: (qmail 70315 invoked by uid 500); 17 Aug 2011 09:30:41 -0000 Mailing-List: contact dev-help@commons.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Commons Developers List" Delivered-To: mailing list dev@commons.apache.org Received: (qmail 70283 invoked by uid 99); 17 Aug 2011 09:30:33 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 17 Aug 2011 09:30:33 +0000 X-ASF-Spam-Status: No, hits=0.0 required=5.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of aploese@gmx.de designates 213.165.64.22 as permitted sender) Received: from [213.165.64.22] (HELO mailout-de.gmx.net) (213.165.64.22) by apache.org (qpsmtpd/0.29) with SMTP; Wed, 17 Aug 2011 09:30:24 +0000 Received: (qmail invoked by alias); 17 Aug 2011 09:30:03 -0000 Received: from pD9E9408F.dip.t-dialin.net (EHLO [192.168.69.11]) [217.233.64.143] by mail.gmx.net (mp036) with SMTP; 17 Aug 2011 11:30:03 +0200 X-Authenticated: #1436251 X-Provags-ID: V01U2FsdGVkX18HBwRi9qAHa/qTvBy6/ql6k8W+llJ/68pdNj9rNo ad9DwqWLbJBaj6 Subject: Re: [Math] "iterator" and "sparseIterator" in "RealVector" hierarchy From: Arne Ploese Reply-To: aploese@gmx.de To: Commons Developers List In-Reply-To: References: <20110814225211.GD18819@dusk.harfang.homelinux.org> <20110815110458.GF18819@dusk.harfang.homelinux.org> <20110815220646.GH18819@dusk.harfang.homelinux.org> <20110815232831.GJ18819@dusk.harfang.homelinux.org>

<20110816114617.GG2590@dusk.harfang.homelinux.org> <4E4AD959.1040908@gmail.com> Content-Type: text/plain; charset="UTF-8" Date: Wed, 17 Aug 2011 11:30:02 +0200 Message-ID: <1313573402.3087.7.camel@knuffelchen> Mime-Version: 1.0 X-Mailer: Evolution 2.32.2 Content-Transfer-Encoding: 7bit X-Y-GMX-Trusted: 0 X-Virus-Checked: Checked by ClamAV on apache.org Ted, please just take your code and move Iterator 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 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