[C++] Implement take kernel functions

[asfimport]

Among other things, this can be used to convert from DictionaryArray back to dense array. This is equivalent to ndarray.take in NumPy

Reporter: Wes McKinney / @wesm
Assignee: Ben Kietzman / @bkietz

Subtasks:

• [C++] Implement take kernel functions - primitive value type
• [C++] Implement take kernel functions - string/binary value type
• [C++] Implement take kernel functions - nested array value type
• [C++] Implement take kernel functions - properly handle special indices

Related issues:

• [C++/Python] Add pandas-like take method to Array (blocks)
• [C++] Take kernel on DictionaryArray does not preserve ordered flag (relates to)
• [C++] Return more specific invalid Status in Take kernel (relates to)

_{Note: This issue was originally created as ARROW-772. Please see the migration documentation for further details.}

[asfimport]

Jingyuan Wang / @alphalfalfa:
I'll take a stab at this one and get familiar with c++ code.

[asfimport]

Wes McKinney / @wesm:
OK, this is a pretty good sized project. You can start with supporting any signed integer indices to start. I suggest using the functor implementation approach used with cast since a particular take kernel will depend on 2 types (the value type and index type).

You're also welcome to create sub-JIRAs if you'd like to handle primitive arrays, string/binary arrays, and nested arrays in separate patches to keep the size of the patches (and number of test cases to write) smaller

Some other notes off the top of my head:

• In some cases, indices may be negative (e.g. arr.take([-4, -3, -2, -1, 0]) selects the last 5 elements of a NumPy arrays in reverse order), but negative indexing could be handled in follow up work

• Out of bounds indices could either yield null in the output array or cause an error, eventually we want to support both

• If the indices have a null, so should the output

[asfimport]

Jingyuan Wang / @alphalfalfa:
One question popped up after I started to implement the basic support of signed integers. I was mostly following the only-two existing cast and hash kernels. Take kernel would need to take some type of indices, either single integer or array of integers. I am wondering, should the kernel still be an UnaryKernel or the indices should be considered as a second input?

[asfimport]

Wes McKinney / @wesm:
UnaryKernel is a convenience for functions of one argument. I am not sure what will be the right structure long term, but for the moment I believe it should be to pass the arguments as a Datum with the COLLECTION type (possibly to be renamed later to "SEQUENCE") https://github.com/apache/arrow/blob/master/cpp/src/arrow/compute/kernel.h#L53

[asfimport]

Joris Van den Bossche / @jorisvandenbossche:
@bkietz all mentioned subtasks here are resolved. Are there more "take" tasks, or can this issue be closed?

[asfimport]

Wes McKinney / @wesm:
I think unions remain. Is there a JIRA about that already?

[asfimport]

Ben Kietzman / @bkietz:
Take against UnionArrays has been resolved: https://issues.apache.org/jira/browse/ARROW-5594