On 11/15/12 10:52 AM, Patrick Meyer wrote: > I misunderstood an earlier email and I though the compute method was public. > It seems that adding a public compute method may be more complication and > effort than it is worth. My apologies for the misunderstanding. The compute > method would only be of value if it can be an easy addition.
It is easy to add and that was the original proposal. The problem was the type of the actual parameter - UnivariateStatistic - seeming out of place. That is what led me to suggest a more general type - ArrayFunction. Unless there are better ideas, I think that is the best way to handle this. Phil > > -----Original Message----- > From: Phil Steitz [mailto:phil.ste...@gmail.com] > Sent: Thursday, November 15, 2012 1:42 PM > To: Commons Developers List > Subject: Re: [Math] MATH-894 > > On 11/15/12 10:29 AM, Ted Dunning wrote: >> On Thu, Nov 15, 2012 at 10:04 AM, Phil Steitz <phil.ste...@gmail.com> wrote: >> >>> Do you know how to do that with a primitive array? Can you provide >>> some sample code? >>> >> You don't. See my next paragraph. >> >> See the assign method in this class: >> >> https://github.com/apache/mahout/blob/trunk/math/src/main/java/org/apa >> che/mahout/math/VectorView.java > Interesting. I see no assign method, but I can see what this thing does. It > is not clear to me though how this idea could be meaningfully applied to > solve the problem we have with applying > statistics to an RDA without doing any array copying. Most likely > I am missing the point. > > Phil >> >> >> >> >>> Thanks for your help on this. >>> >>> Phil >>>> The Colt/Mahout approach is to define a view object which opaquely >>>> remembers a reference to the original, an offset and a length. >>>> Functions and other arguments can be passed to this view object >>>> which operates on a subset of the original contents by calling the >>>> function. Performance is actually quite good. The JIT seems to >>>> in-line the view object access to the underlying object and also >>>> in-lines evaluation of the function so >>> that >>>> the actual code that is executed is pretty much what you would write >>>> in >>> C, >>>> but you don't have to worry as much since the pattern of access is >>>> more controlled. >>>> >>>> For completeness, this is essentially what java.nio does with the >>>> *Buffer classes as well. You can wrap an array and then you can ask >>>> for slices >>> out >>>> of that array while retaining the reference semantics. >>>> > > --------------------------------------------------------------------- > 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 > > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
