Doris-Breakwater commented on issue #68717: URL: https://github.com/apache/doris/issues/68717#issuecomment-5978344578
Breakwater-GitHub-Analysis-Slot: slot_4a272fe48044 **Initial assessment:** This is a reproducible constant-folding/execution parity issue for the `DOUBLE` overloads of `floor`, `ceil`, and `round` with a scale. The supplied SQL, build hash, and `debug_skip_fold_constant` comparison are sufficient for a focused investigation; no profile or additional logs are needed for this specific result mismatch. The issue had no labels at intake. **Verified from the `4.1.4` source (tag `ad35a140c7f`):** Nereids' [FE executable methods](https://github.com/apache/doris/blob/4.1.4/fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/functions/executable/NumericArithmetic.java#L365-L455) convert a `DoubleLiteral` via `Double.toString()` into `BigDecimal`, then apply decimal `setScale` through [DecimalV3Literal](https://github.com/apache/doris/blob/4.1.4/fe/fe-core/src/main/java/org/apache/doris/nereids/trees/expressions/literal/DecimalV3Literal.java#L103-L131) (`FLOOR`, `CEILING`, or `HALF_UP`). The [BE dispatcher](https://github.com/apache/doris/blob/4.1.4/be/src/exprs/function/round.h#L445-L480) sends `DOUBLE` with positive scale to `FloatRoundingComputation`, which [multiplies by `10^d`, applies the floating-point rounding function, then divides](https://github.com/apache/doris/blob/4.1.4/be/src/exprs/function/round.h#L266-L313). `round` is [registered with the ordinary, non-bankers tie mode](https://github.c om/apache/doris/blob/4.1.4/be/src/exprs/function/round.cpp#L26-L39). That difference explains all three reported examples: binary `0.29 * 100` is `28.999999999999996`, so BE `floor` yields `0.28`; binary `-0.29 * 100` is `-28.999999999999996`, so BE `ceil` yields `-0.28`; binary `1.005 * 100` is `100.49999999999999`, so BE `round` yields `1.0`. FE instead rounds the shortest decimal strings `"0.29"`, `"-0.29"`, and `"1.005"`, yielding `0.29`, `-0.29`, and `1.01`. These arithmetic values were checked independently; the Doris query results themselves are as reported in the issue, not from a local running cluster. **Maintainer next steps:** Treat constant-versus-column equality as the regression criterion. Decide which `DOUBLE` rounding semantics are intended, then make FE folding and BE execution agree for those overloads. A narrow temporary option is to prevent FE folding of the affected `DOUBLE` overloads until equivalent semantics are implemented; the global `debug_skip_fold_constant` setting is useful for diagnosis but is broad. Add regression cases comparing literal and column inputs for all three functions, including the supplied values, negative inputs, positive/zero/negative scales, and boundary/tie values. Check other floating-point overloads if the implementation change is shared. For applications requiring exact decimal rounding, use `DECIMAL` values from ingestion onward rather than relying on `DOUBLE`. **Open decision, not missing incident evidence:** Which result should be the public contract for `DOUBLE` inputs? The source establishes why the paths differ, but does not establish whether decimal-string or binary floating-point behavior is intended. The exact 4.1.4 runtime outputs and plans in the report are sufficient to start a fix; an attached `EXPLAIN` text would only be useful if a maintainer cannot reproduce the stated folding behavior. -- 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]
