commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Ted Dunning <ted.dunn...@gmail.com>
Subject Re: [Math] MATH-894
Date Thu, 15 Nov 2012 17:22:01 GMT
On Thu, Nov 15, 2012 at 8:42 AM, Phil Steitz <phil.steitz@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message