On 11/15/12 9:22 AM, Ted Dunning wrote:
> 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.

Do you know how to do that with a primitive array?  Can you provide
some sample code?

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

Reply via email to