velvia commented on a change in pull request #8688:
URL: https://github.com/apache/arrow/pull/8688#discussion_r528052210
##########
File path: rust/arrow/src/compute/kernels/boolean.rs
##########
@@ -457,4 +517,42 @@ mod tests {
assert_eq!(true, res.value(2));
assert_eq!(false, res.value(3));
}
+
+ fn assert_array_eq<T: ArrowNumericType>(
+ expected: PrimitiveArray<T>,
+ actual: ArrayRef,
+ ) {
+ let actual = actual
+ .as_any()
+ .downcast_ref::<PrimitiveArray<T>>()
+ .expect("Actual array should unwrap to type of expected array");
+
+ for i in 0..expected.len() {
+ if expected.is_null(i) {
+ assert!(actual.is_null(i));
+ } else {
+ assert_eq!(expected.value(i), actual.value(i));
+ }
+ }
+ }
+
Review comment:
@vertexclique ... I had a quick look at the PR but slicing() method was
not defined in it. Is it from bitvec crate or something?
@jorgecarleitao well `bitwise_unary_op_helper` (and `bitwise_bin_op_helper`
also) both use `bit_chunks()` which basically gives you an iterator of 64-bit
chunks starting at offset.... essentially "left-shifting" into 0 position.
I need a reverse operation, which is take 64-bit chunks and right shift
them. It can be kind of simulated by "pre-pending" 64 0-bits into a buffer,
then using bit_chunks() again to get a shift into whatever alignment is needed,
and finally writing out the final buffer, though all of that is slightly
convoluted.
I'm wondering if it's worth trying that out, or just wait for @vertexclique
's PR.
Actually, what's better than shift-shift-zip-operate-rshift would be simply
to shift the right bitmap into the left's position, then use a mask to operate
on both of them. That reduces the number of shifts.
----------------------------------------------------------------
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.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
