zanmato1984 commented on code in PR #51611:
URL: https://github.com/apache/arrow/pull/51611#discussion_r4369015614
##########
cpp/src/arrow/compute/kernels/scalar_nested.cc:
##########
@@ -537,6 +540,439 @@ const FunctionDoc list_element_doc(
"is emitted. Null values emit a null in the output."),
{"lists", "index"});
+// The types "equal" compares `values` and `queries` as, raising the errors it
would.
+// float16, which "equal" lacks, is compared as float32, and binary views as
large
+// binary.
+Result<std::vector<TypeHolder>> ComparableTypes(
+ KernelContext* ctx, const std::shared_ptr<DataType>& values_type,
+ const std::shared_ptr<DataType>& queries_type) {
+ std::vector<TypeHolder> types;
+ for (const auto& type : {values_type, queries_type}) {
+ types.emplace_back(type->id() == Type::HALF_FLOAT ? float32() : type);
Review Comment:
Could we unwrap dictionary types before applying the float16-to-float32
normalization, for both operands? The current check misses float16 inside a
dictionary, while `equal->DispatchBest` unwraps it only afterward, leaving an
unsupported `(halffloat, float)` or `(float, halffloat)` comparison. For
example, dictionary-encoded float16 values representing `[[NaN], [1], [null]]`,
queried with a float32 NaN, should return `[true, false, false]`, just like
decoded values. The reverse direction, with dictionary-encoded float16 queries,
needs the same handling. Could we add regression tests for both directions?
--
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: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
