jorgecarleitao commented on a change in pull request #7967:
URL: https://github.com/apache/arrow/pull/7967#discussion_r471146570
##########
File path: rust/datafusion/src/execution/physical_plan/math_expressions.rs
##########
@@ -20,36 +20,62 @@
use crate::error::ExecutionError;
use crate::execution::physical_plan::udf::ScalarFunction;
-use arrow::array::{Array, ArrayRef, Float64Array, Float64Builder};
-use arrow::datatypes::{DataType, Field};
+use arrow::array::{Array, ArrayRef};
+use arrow::array::{Float32Array, Float64Array};
+use arrow::datatypes::DataType;
use std::sync::Arc;
+macro_rules! compute_op {
+ ($ARRAY:expr, $FUNC:ident, $TYPE:ident) => {{
+ let mut builder = <$TYPE>::builder($ARRAY.len());
+ for i in 0..$ARRAY.len() {
+ if $ARRAY.is_null(i) {
+ builder.append_null()?;
+ } else {
+ builder.append_value($ARRAY.value(i).$FUNC())?;
+ }
+ }
+ Ok(Arc::new(builder.finish()))
+ }};
+}
+
+macro_rules! downcast_compute_op {
+ ($ARRAY:expr, $NAME:expr, $FUNC:ident, $TYPE:ident) => {{
+ let n = $ARRAY.as_any().downcast_ref::<$TYPE>();
+ match n {
+ Some(array) => compute_op!(array, $FUNC, $TYPE),
+ _ => Err(ExecutionError::General(format!(
+ "Invalid data type for {}",
+ $NAME
+ ))),
+ }
+ }};
+}
+
+macro_rules! unary_primitive_array_op {
+ ($ARRAY:expr, $NAME:expr, $FUNC:ident) => {{
+ match ($ARRAY).data_type() {
+ DataType::Float32 => downcast_compute_op!($ARRAY, $NAME, $FUNC,
Float32Array),
+ DataType::Float64 => downcast_compute_op!($ARRAY, $NAME, $FUNC,
Float64Array),
+ other => Err(ExecutionError::General(format!(
+ "Unsupported data type {:?} for function {}",
+ other, $NAME,
+ ))),
+ }
+ }};
+}
+
macro_rules! math_unary_function {
($NAME:expr, $FUNC:ident) => {
ScalarFunction::new(
$NAME,
- vec![Field::new("n", DataType::Float64, true)],
+ // order: from faster to slower
+ vec![vec![DataType::Float32], vec![DataType::Float64]],
DataType::Float64,
Review comment:
Glad you asked! Yes! It just takes a bit more changes: the main issue is
that this has to be consistent with Logical expressions and they currently only
support a single return type. I am proposing a generalization of this whole
thing here: https://github.com/apache/arrow/pull/7974 , so that both logical
and physical plans yield a consistent and variable data type.
----------------------------------------------------------------
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
