You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
I spent quite a while reading the code for various bitwise kernels while working
with @rluvaton on
I found there are many different, somewhat overlapping functions that are spread over the codebase
This makes it
Hard to find the appropriate API
Harder to optimize the correct operations as it is not clear always where
the relevant code is is located
I also think my experience in #8793 suggests there is significant room for optimization,
and that it is important to have two sets of functions: Modify in place and return new buffer
I think part of the current state is somewhat due to history and some of these functions predated the Buffer APIs
Describe the solution you'd like
I would like the implementation for the "core" APIs to be clear:
Create a new Buffer from a unary / binary bitwise operation
Apply a unary/binary bitwise operation to an existing Mutable buffer in place
Add new Buffer::bitwise_unary and Buffer::bitwise_binary functions (that do the same thing as bitwise_bin_op_helper and bitwise_unary_op_helper) but are easier to find and use, and consistently named with PrimitiveArray::unary and PrimitiveArray::binary functions: Add Buffer::from_bitwise_unary and Buffer::from_bitwise_binary me… #8854
Add BooleanArray::binary and BooleanArray::unary functions that use the new Buffer functions internally
Deprecate bitwise_bin_op_helper, and bitwise_unary_op_helper in favor of the new Buffer methods
Deprecate special methods such as buffer_bin_or methods in favor of using the new Buffer methods directly
Is your feature request related to a problem or challenge? Please describe what you are trying to do.
I spent quite a while reading the code for various bitwise kernels while working
with @rluvaton on
apply_unary_opandapply_binary_opbitwise operations #8619I found there are many different, somewhat overlapping functions that are spread over the codebase
This makes it
the relevant code is is located
I also think my experience in #8793 suggests there is significant room for optimization,
and that it is important to have two sets of functions: Modify in place and return new buffer
I think part of the current state is somewhat due to history and some of these functions predated the Buffer APIs
Describe the solution you'd like
I would like the implementation for the "core" APIs to be clear:
Bufferfrom a unary / binary bitwise operationAfter #8619 we have 2
Describe alternatives you've considered
Thus, I propose we do the following:
Buffer::bitwise_unaryandBuffer::bitwise_binaryfunctions (that do the same thing asbitwise_bin_op_helperandbitwise_unary_op_helper) but are easier to find and use, and consistently named withPrimitiveArray::unaryandPrimitiveArray::binaryfunctions: AddBuffer::from_bitwise_unaryandBuffer::from_bitwise_binaryme… #8854BooleanArray::binaryandBooleanArray::unaryfunctions that use the new Buffer functions internallybitwise_bin_op_helper, andbitwise_unary_op_helperin favor of the new Buffer methodsbuffer_bin_ormethods in favor of using the new Buffer methods directlyThen we'll basically have two core APIs:
apply_unary_opandapply_binary_opbitwise operations #8619)Buffer::bitwise_unary/Buffer::bitwise_binary)Then all other APIs will then be thin wrappers around the core APIs and we can spend optimziation and testing efforts on these two core APIs.
Additional context