zeroshade commented on code in PR #14176: URL: https://github.com/apache/arrow/pull/14176#discussion_r1065006737
########## docs/source/format/Columnar.rst: ########## @@ -765,6 +765,72 @@ application. We discuss dictionary encoding as it relates to serialization further below. +.. _run-end-encoded-layout: + +Run-End Encoded Layout +------------------------- + +Run-end encoding (REE) is a variation of run-length encoding (RLE). These +encodings are well-suited for representing data containing sequences of the +same value, called runs. In run-end encoding, each run is represented as a +value and an integer giving the index in the array where the run ends. + +Any array can be run-end encoded. A run-end encoded array has no buffers +by itself, but has two child arrays. The first one holds a signed integer +called a "run end" for each run. The run ends array can hold either 16, 32, or +64-bit integers. The actual values of each run are held in the second child array. +For the purposes of determining field names and schemas, these child arrays +are prescribed the standard names of **run_ends** and **values** respectively. + +The values in the first child array represent the length of each run. They do +not hold the length of the respective run directly, but the accumulated length +of all runs from the first to the current one, i.e. the logical index where the +current run ends. This allows relatively efficient random access from a logical +index using binary search. The length of an individual run can be determined by +subtracting two adjacent values. (Contrast this with run-length encoding, in +which the lengths of the runs are represented directly, and in which random +access is less efficient.) + +A run must have have a length of at least 1. This means the values in the +run ends array all positive and in strictly ascending order. A run end cannot be +null. + +As an example, you could have the following data: :: + + type: Float32 + [1.0, 1.0, 1.0, 1.0, null, null, 2.0] + +In Run-end-encoded form, this could appear as: + +:: + + * Length: 7, Null count: 2 + * Children arrays: + + * run_ends (Int32): + * Length: 3, Null count: 0 + * Validity bitmap buffer: Not required Review Comment: I'll look back at the mailing list discussion and see if that was addressed. Offhand, I can think of one reason why its a child rather than just a buffer: ease of slicing. Currently, if you slice an REE array, you can track the *logical* offset in the REE array directly, which will correspond to a *physical* offset into the values and run-ends. Then to determine run-ends in the slice it's just the *run-end value - **physical** offset*. This makes it very easy to handle sliced arrays, sliced buffers, and constructing a new REE array from a slice. When slicing you can compute the physical offset and store it as the offset of the sliced child. If the run-ends were just a buffer instead of a child, the *logical* offset for a sliced REE array wouldn't correspond with the actual index into the buffer, so every time you do a lookup into a sliced REE array, you need to re-compute the physical offset (log n) from the logical offset before you can do anything. So having it as a child maintains an O(1) random access when indexing into a sliced REE array, whereas having it as a buffer would mean O(log n) random access for a sliced REE array. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
