[AutoSparkUT] round returns different value on GPU

[GaryShen2008]

Describe the bug

The round function on GPU returns incorrect precision result. For round(3.1415, 3), GPU returns 3.142 while CPU correctly returns 3.141.

---

Steps/Code to reproduce bug

Spark-shell Reproduction Code

Environment Setup:

export SPARK_HOME=/path/to/spark-3.3.0
export RAPIDS_JAR=rapids-4-spark_2.12-25.12.0-SNAPSHOT-cuda12.jar

Reproduction Script: test-failures/reproduce-math-expressions-round.scala

// Test: round(3.1415, 3) returns 3.142 instead of 3.141

val floatTest = spark.range(1).select(
     |   lit(3.1415f).cast("float").as("original"),
     |   round(lit(3.1415f).cast("float"), 3).as("rounded")
     | )

floatTest.show(false)

Run Command (with all 32 configuration parameters):

$SPARK_HOME/bin/spark-shell \
  --master local[2] \
  --conf spark.sql.optimizer.excludedRules=org.apache.spark.sql.catalyst.optimizer.ConvertToLocalRelation,org.apache.spark.sql.catalyst.optimizer.ConstantFolding \
  --conf spark.rapids.sql.enabled=true \
  --conf spark.plugins=com.nvidia.spark.SQLPlugin \
  --conf spark.sql.queryExecutionListeners=org.apache.spark.sql.rapids.ExecutionPlanCaptureCallback \
  --conf spark.rapids.sql.explain=ALL \
  --conf spark.rapids.sql.test.isFoldableNonLitAllowed=true \
  --conf spark.rapids.sql.csv.read.decimal.enabled=true \
  --conf spark.rapids.sql.format.avro.enabled=true \
  --conf spark.rapids.sql.format.avro.read.enabled=true \
  --conf spark.rapids.sql.format.hive.text.write.enabled=true \
  --conf spark.rapids.sql.format.json.enabled=true \
  --conf spark.rapids.sql.format.json.read.enabled=true \
  --conf spark.rapids.sql.incompatibleDateFormats.enabled=true \
  --conf spark.rapids.sql.python.gpu.enabled=true \
  --conf spark.rapids.sql.rowBasedUDF.enabled=true \
  --conf spark.rapids.sql.window.collectList.enabled=true \
  --conf spark.rapids.sql.window.collectSet.enabled=true \
  --conf spark.rapids.sql.window.range.byte.enabled=true \
  --conf spark.rapids.sql.window.range.short.enabled=true \
  --conf spark.rapids.sql.expression.Ascii=true \
  --conf spark.rapids.sql.expression.Conv=true \
  --conf spark.rapids.sql.expression.GetJsonObject=true \
  --conf spark.rapids.sql.expression.JsonToStructs=true \
  --conf spark.rapids.sql.expression.StructsToJson=true \
  --conf spark.rapids.sql.exec.CollectLimitExec=true \
  --conf spark.rapids.sql.exec.FlatMapCoGroupsInPandasExec=true \
  --conf spark.rapids.sql.exec.WindowInPandasExec=true \
  --conf spark.rapids.sql.hasExtendedYearValues=false \
  --conf spark.unsafe.exceptionOnMemoryLeak=true \
  --conf spark.sql.session.timeZone=America/Los_Angeles \
  --jars $RAPIDS_JAR \
  < reproduce-math-expressions-round.scala

---

Expected behavior

When calling round(3.1415, 3), the function should return 3.141 (rounded to 3 decimal places).

Actual behavior

GPU returns 3.142 instead of 3.141.

---

Environment details

• Spark Version: 3.3.0
• RAPIDS Version: 25.12.0-SNAPSHOT
• CUDA Version: 12.x
• Test Suite: MathExpressionsSuite
• Test Name: round/bround/floor/ceil

---

Additional context

• Original Spark Test Location: spark/sql/catalyst/src/test/scala/org/apache/spark/sql/catalyst/expressions/MathExpressionsSuite.scala (line 643)
• Test Logic: Validates rounding functions with various scales and data types
• Impact: Affects numerical accuracy in calculations

[thirtiseven]

similar/duplicated issue: #1573

[mattahrens]

Ref: https://nvidia.github.io/spark-rapids/docs/compatibility.html#floating-point

[sameerz]

The difference between round on the CPU and GPU is documented here: https://nvidia.github.io/spark-rapids/docs/compatibility.html#floating-point.

Do we have a test case that is running that we need to investigate?

[GaryShen2008]

The difference between round on the CPU and GPU is documented here: https://nvidia.github.io/spark-rapids/docs/compatibility.html#floating-point.

Do we have a test case that is running that we need to investigate?

Spark UT has a test case "round/bround/floor/ceil" in MathExpressionsSuite. It failed because of this issue.

[wjxiz1992]

Root Cause Analysis

Investigated the difference between CPU and GPU for round(3.1415f, 3) → CPU returns 3.141, GPU returns 3.142.

CPU (Spark) algorithm

Spark converts the float to BigDecimal first, which preserves the exact IEEE 754 stored value:

3.1415f  →  IEEE 754 actual value: 3.14149999618530273437500...
BigDecimal(3.14149999...).setScale(3, HALF_UP)
→ 4th decimal digit = 4, which is < 5, so HALF_UP rounds DOWN → 3.141

This is documented in compatibility.md:

The Spark implementation of round converts it first to a decimal value with complex logic to make it 1.025 and then does the rounding.

GPU (cuDF / spark-rapids-jni) algorithm

The GPU uses a multiply-round-divide approach:

3.1415f × 1000 = 3141.49999...
               ↓ (float has only ~7 significant digits)
             = 3141.5f       ← intermediate precision loss at multiplication
round(3141.5) = 3142         (HALF_UP: .5 rounds up)
3142 / 1000   = 3.142

The key difference: the intermediate multiplication value × 10^scale causes float precision loss, converting 3141.4999... into 3141.5, which then triggers HALF_UP to round up.

Who is correct?

Per Spark's documented semantics (HALF_UP on the actual expression value), the CPU result 3.141 is technically more accurate — the float value stored in memory IS 3.14149999..., and HALF_UP rounding of that value at 3 decimal places should round down. The GPU result 3.142 is caused by intermediate precision loss in the multiply-round-divide algorithm, not by a different rounding mode.

This is the same pattern as round(1.025, 2) → CPU 1.03 vs GPU 1.02, documented in Floating Point compatibility and related to #1573.

Impact on Spark UT

The Spark UT "round/bround/floor/ceil" in MathExpressionsSuite is currently excluded via KNOWN_ISSUE in RapidsTestSettings.scala.

[revans2]

I think that eventually we can make this work, but it is very hard to do right. It is mostly about how important is it for us to do it. In spark it converts the float to a decimal, rounds the decimal, and then converts it back to a float. But a float to a decimal, in spark, goes through a string first. We don't have a perfect way to make the float->string work, but our current version is not too bad. Next the string to decimal is problematic because the decimal produces will have an arbitrary precision and scale. In reality any precision we produce will be less than 64-bits because even a double fits in 64 bits with the exponent. But the scale in cudf is not per-row so we would have to make sure that the conversion is always fused into a single kernel with the rounding.