Github user setjet commented on a diff in the pull request:
https://github.com/apache/spark/pull/18113#discussion_r118914424
--- Diff:
sql/core/src/main/scala/org/apache/spark/sql/execution/aggregate/typedaggregators.scala
---
@@ -99,3 +97,67 @@ class TypedAverage[IN](val f: IN => Double) extends
Aggregator[IN, (Double, Long
toColumn.asInstanceOf[TypedColumn[IN, java.lang.Double]]
}
}
+
+class TypedMinDouble[IN](val f: IN => Double) extends Aggregator[IN,
Double, Double] {
+ override def zero: Double = Double.PositiveInfinity
--- End diff --
Turns out I made a typo which caused me to miss a permutation of handling
null in the parameters...
Comparing both solutions (tuple with `OUT` as `java.lang.Double` vs
non-tuple with both `BUF` and `OUT` as `java.lang.Double`), it seems we have
the following trade-offs:
- tuple will require more data to be shuffled around as we are adding an
additional value
- non-tuple solution requires the developer to know a bit about the
internals, i.e.:
`val tuple = (x: (Double, Double)) => x._2
emptyDataSet.agg(typed.min(tuple)).show()`
`val nontuple = (x: (Double, java.lang.Double)) => x._2
emptyDataSet.agg(typed.min(nontuple)).show()`
This is because function `f` passed in into typed.min outputs a `BUF`,
forcing the caller to know about it the internals.
Given that users can always implement their own (non-tuple version) if
needed, I'd argue in favor of the tupled solution beacuse it is a bit more
developer friendly. What do you think?
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature is enabled but not working, please
contact infrastructure at infrastruct...@apache.org or file a JIRA ticket
with INFRA.
---
---------------------------------------------------------------------
To unsubscribe, e-mail: reviews-unsubscr...@spark.apache.org
For additional commands, e-mail: reviews-h...@spark.apache.org
