KarpagamKarthikeyan commented on PR #23962: URL: https://github.com/apache/datafusion/pull/23962#issuecomment-5121631547
> how is this different from the datafusion functions ver? @Jefffrey Good question. The element-wise math is the same underlying `f64::atan2`, but the **return type differs**: - Core `atan2` returns **Float32 when both inputs are Float32** (single-precision path), Float64 otherwise — this is asserted in core's own tests (`scalar.slt`): `atan2(Float32, Float32)` → `Float32`, every other combination → `Float64`. - This Spark version is `exact(Float64, Float64) -> Float64`: `atan2(Float32, Float32)` coerces to Float64 and returns **Float64**, matching Spark, where `atan2` is defined over `double` and always returns `double`. So `atan2(float_col, float_col)` gives `Float32` in core but `Float64` here — Spark-compatible. I think this is the same reason `abs`/`ceil`/`floor`/`round`/`rint` are reimplemented in `datafusion-spark` rather than delegating to core: the crate enforces Spark's type semantics (double-only, no Float32-specific path), following the guideline of only accepting Spark-supported types. Happy to adjust if you'd prefer a different approach here or think otherwise. -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
