Hi Micah,
Sounds good. Thanks.
I have prepared some initial code, in the hope that it will make
discussions easier.
Anyway, we can ignore it for now, until we have consensus.
Best,
Liya Fan
On Fri, Aug 23, 2019 at 11:05 AM Micah Kornfield
wrote:
> I'm in favor of this, but still think we are
I'm in favor of this, but still think we are gather feedback on the
proposal, so we should hold off on coding these up, until we have consensus
on the approach.
Thanks,
Micah
On Wed, Aug 21, 2019 at 9:22 PM Fan Liya wrote:
> Hi Micah,
>
> Thanks for the comments.
> By storing the run-length end
Hi Micah,
Thanks for the comments.
By storing the run-length ends (partial sum of run-lengths), it provides
better support for random access (O(log(n)), at the expense of larger
buffer width.
Generally, I think this is a better design, so the design should be changed
as follows:
2. the data stru
Hi Liya Fan,
Perhaps comment on the original thread? This differs from my proposal in
terms on details of encoding. For RLE, I proposed encoding run end indices
instead of run-lengths. This allows for sublinear access to elements at
the cost of potentially larger bit-widths for the lengths.
Th
Hi Wes,
Thanks for the good suggestion.
It is intended to be sent through IPC. So it should implement FieldVector,
not just ValueVector.
This can be considered a sub-item of Micah's proposal about
compression/decompression.
I will spend more time on that discussion.
Best,
Liya Fan
On Wed, Aug 2
hi Liya,
Do you intend to be able to send RLE vectors using the IPC protocol?
If so, we need to spend some time on Micah's discussion about
sparseness and encodings/compression.
- Wes
On Wed, Aug 21, 2019 at 7:33 AM Fan Liya wrote:
>
> Dear all,
>
> RLE (run length encoding) is a widely used en
