On Thu, Nov 15, 2012 at 8:42 AM, Phil Steitz <phil.ste...@gmail.com> wrote:
> On 11/15/12 8:01 AM, Ted Dunning wrote: > > > > The typical answer to this when adding a functional method like compute > is to also add a view object. The rationale is that a small number of view > methods can be composed with a small number of compute/aggregate methods to > get the expressive power of what would otherwise require a vast array of > methods. > > If I understand correctly, we already have a view object exposed - > getElements. The challenge is that this method returns a copy and > what we would like is a way to get a function computed directly on > the data encapsulated in the RDA. Without function pointers or real > array references, I don't see a straightforward way to do this. > > When I say view, I mean something that is a reference and is not a copy. The getElements method is a copy, not view under this terminology. 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.
