morrySnow commented on code in PR #68029:
URL: https://github.com/apache/doris/pull/68029#discussion_r4058963674


##########
fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/functions/executable/NumericArithmetic.java:
##########
@@ -755,6 +756,45 @@ public static Expression factorial(BigIntLiteral first) {
         return new BigIntLiteral(ArithmeticUtils.factorial((int) value));
     }
 
+    /**
+     * gamma
+     *
+     * <p>The BE computes this with std::tgamma and maps the poles to NULL, so 
this
+     * evaluation reproduces that outcome rather than the raw library 
behaviour:
+     * commons-math3 returns NaN for everything that is not finite, while 
std::tgamma
+     * returns an infinity at zero, at a large enough argument and at positive 
infinity.
+     *
+     * <p>-Infinity is the one input where the two classifications differ in a 
way that
+     * matters: the BE sees it as a negative integer, hence a pole, and yields 
NULL.
+     *
+     * <p>Positive and negative inputs need different routes through 
commons-math3.
+     * Gamma.gamma saturates to an infinity well before std::tgamma does - it 
already
+     * overflows at 165, while std::tgamma still returns a finite 3.29e293 
there - so
+     * positive inputs go through exp(logGamma(x)), which stays finite across 
the range and
+     * agrees with std::tgamma to the last place. logGamma is not defined for 
negative
+     * inputs, but that half has no overflow problem, so Gamma.gamma is used 
there.
+     */
+    @ExecFunction(name = "gamma")
+    public static Expression gamma(DoubleLiteral first) {
+        double x = first.getValue();
+        if (Double.isNaN(x)) {
+            return new DoubleLiteral(Double.NaN);
+        }
+        if (Double.isInfinite(x)) {
+            // +inf overflows to itself; -inf is treated as a negative 
integer, i.e. a pole.
+            return x > 0 ? new DoubleLiteral(Double.POSITIVE_INFINITY)

Review Comment:
   If this function does not contribute to partition pruning and bucket 
pruning, and cannot simply align the implementations of fe and be, then not 
implementing the version of fe might be a better choice.



-- 
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]

Reply via email to