alamb opened a new issue #1068:
URL: https://github.com/apache/arrow-rs/issues/1068


   **Is your feature request related to a problem or challenge? Please describe 
what you are trying to do.**
   We are trying to implement more generic "scalar" kernels -- see discussion 
on https://github.com/apache/arrow-rs/pull/984
   
   If one wants to call 
[`eq_scalar`](https://docs.rs/arrow/6.4.0/arrow/compute/kernels/comparison/fn.eq_scalar.html)
 on a `PrimtiveArray`,
   
   ```rust
       let array: Int8Array = vec![1,2,3]
           .into_iter()
           .map(Some)
           .collect();
   
       let comparison = arrow::compute::eq_scalar(&array, 2).unwrap();
   
       let expected: BooleanArray = vec![false, true, false]
           .into_iter()
           .map(Some)
           .collect();
   
       assert_eq!(comparison, expected);
   ```
   
   In this case, since the data type (`Int8Type` ) is an associated type of the 
`PrimitiveArray` type, Rust can infer the correct type for argument `2` into 
the `2i8` needed for calling eq_scalar.
   
   However as soon as you have an `ArrayRef` (aka dynamic array), it becomes 
challenging. To write a generic "compare this array to a scalar value" we would 
liek to write something like this:
   
   
   ```rust
   /// Perform `left == right` operation on an array and a numeric scalar
   /// value. Supports PrimtiveArrays, and DictionaryArrays that have primitive 
values
   pub fn eq_dyn_scalar<T>(
       left: &dyn Array,
       right: T::Native,
   ) -> Result<BooleanArray>
   where
       T: ArrowNumericType,
   {
   ...
   }
   ```
   
   However, to actually call this function, the type of `right` needs to match 
`T`, but there is a potentially infinite number of concrete T types that could 
have a matching associated type `Native`, as explained by @shepmaster in 
https://github.com/apache/arrow-rs/pull/984#issuecomment-992777187
   
   Practically that means that all calls to `eq_dyn_scalar` would require type 
annotations which matched the values of the array, which largely defeats the 
purpose of `eq_dyn_scalar`
   
   ```rust
           let array = builder.finish();
           // still need the UInt8Type annotations
           let a_eq = eq_dyn_scalar::<UInt8Type>(&array, 123u8).unwrap();
           assert_eq!(
               a_eq,
               BooleanArray::from(vec![Some(true), None, Some(false)])
           );
   ```
   
   **Describe the solution you'd like**
   
   So the proposal from @shepmaster at 
https://github.com/apache/arrow-rs/pull/984#issuecomment-992806010 is to add a 
trait that maps in the reverse direction, so we could have something like:
   
   
   ```rust
   struct UInt8Type;
   struct Int64Type;
   struct DictionaryArray<K>(K);
   
   // ----
   
   trait ArrowNumericType {
       type Native;
   }
   
   trait IntoArrowNumericType {
       type Arrow: ArrowNumericType<Native = Self>;
   }
   
   // ----
   
   impl ArrowNumericType for UInt8Type {
       type Native = u8;
   }
   
   impl IntoArrowNumericType for u8 {
       type Arrow = UInt8Type;
   }
   
   impl ArrowNumericType for Int64Type {
       type Native = i64;
   }
   
   impl IntoArrowNumericType for i64 {
       type Arrow = Int64Type;
   }
   
   // ----
   
   fn eq_dict_scalar<K, T>(left: &DictionaryArray<K>, right: T)
   where
       K: ArrowNumericType,
       T: IntoArrowNumericType,
   {
       todo!()
   }
   
   // ----
   
   fn usage<K>(d: &DictionaryArray<K>)
   where
       K: ArrowNumericType,
   {
       eq_dict_scalar(d, 8u8);
       eq_dict_scalar(d, -64i64);
   }
   
   ```
   
   **Describe alternatives you've considered**
   A clear and concise description of any alternative solutions or features 
you've considered.
   
   **Additional context**
   Add any other context or screenshots about the feature request here.
   


-- 
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: github-unsubscr...@arrow.apache.org

For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


Reply via email to