simplify_expressions misoptimizes +0.0 vs -0.0 literal equality/inequality conjunctions via ScalarValue::PartialEq
Los mantenedores suelen responder en 1 día
@AnuragRaut08 ya está trabajando en esto.
Desde el 12/11/2026.
Evaluación
- Dificultad
- 3/5
- Tiempo estimado
- 1-2 días
- Aptitud para principiantes
- 69/100
Línea de trabajo
Start in datafusion/optimizer/src/simplify_expressions/expr_simplifier.rs, around the literal comparison conjunction logic at lines 1151–1166, and trace how it compares ScalarValues for SQL equality. Check the existing optimizer tests and the equality semantics used by DataFusion's eq kernel, especially signed zero and NaN. Add regression coverage for the reported conjunctions; done means optimized and unoptimized queries return matching results.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Describe the bug
In datafusion/optimizer/src/simplify_expressions/expr_simplifier.rs (verified on DataFusion 55.0.0 and main HEAD e1c625fdf5, lines 1151–1166), literal comparison conjunction simplification rewrites:
f = 0.0 AND f != -0.0$\rightarrow$f = 0.0f = 0.0 AND f = -0.0$\rightarrow$falsef IN (0.0) AND f NOT IN (-0.0)$\rightarrow$f = 0.0
because distinctness between two literal ScalarValues (l1 != l2) is checked using Rust's ScalarValue::PartialEq (which uses totalOrder / bit-aware comparison where Float64(0.0) != Float64(-0.0) is true), whereas DataFusion/Arrow's SQL = and != operators follow IEEE-754 numeric equality where 0.0 = -0.0 is true and 0.0 != -0.0 is false.
As a result, disabling the logical optimizer (datafusion.optimizer.max_passes = 0) vs. running with default optimizations produces opposite query results.
To Reproduce
import datafusion
import pyarrow as pa
tbl = pa.table({
"id": pa.array([1, 2, 3], type=pa.int64()),
"f": pa.array([0.0, -0.0, 1.5], type=pa.float64()),
})
ctx_unopt = datafusion.SessionContext(
datafusion.SessionConfig().set("datafusion.optimizer.max_passes", "0")
)
ctx_opt = datafusion.SessionContext()
ctx_unopt.from_arrow(tbl, name="t")
ctx_opt.from_arrow(tbl, name="t")
for q in [
"SELECT id FROM t WHERE f = 0.0 AND f != -0.0 ORDER BY id",
"SELECT id FROM t WHERE f = 0.0 AND f = -0.0 ORDER BY id",
]:
r_unopt = [r["id"] for b in ctx_unopt.sql(q).collect() for r in b.to_pylist()]
r_opt = [r["id"] for b in ctx_opt.sql(q).collect() for r in b.to_pylist()]
print(q)
print(" max_passes=0:", r_unopt)
print(" default opt :", r_opt)
Output on DataFusion 55.0.0:
SELECT id FROM t WHERE f = 0.0 AND f != -0.0 ORDER BY id
max_passes=0: []
default opt : [1, 2]
SELECT id FROM t WHERE f = 0.0 AND f = -0.0 ORDER BY id
max_passes=0: [1, 2]
default opt : []
Expected behavior
Under IEEE-754 floating-point equality (0.0 = -0.0 is true):
SELECT id FROM t WHERE f = 0.0 AND f != -0.0should return[](matchingmax_passes=0, PostgreSQL, DuckDB, and SQLite).SELECT id FROM t WHERE f = 0.0 AND f = -0.0should return[1, 2].
Additional context
In expr_simplifier.rs (around lines 1151–1166, introduced in #19731, and similarly in A = L1 AND A = L2 -> false), comparing floating-point ScalarValues (Float16, Float32, Float64) for SQL = / != simplification needs numeric zero-sign-insensitive equality (+0.0 == -0.0 and NaN handling matching DataFusion's eq kernel) rather than ScalarValue::PartialEq.
Willingness to contribute
I would like to contribute a fix for this bug, but request guidance from the DataFusion community
- Lenguaje dominante
- Rust
- Estrellas
- 9.6k
- Forks
- 2.6k
- Merge medio
- 3 d 4 h
- PR fusionados (30 d)
- 345
Preparar el entorno
Inicia el contenedor de desarrollo del proyecto en tu navegador, con tu propia cuenta de GitHub.
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de apache/datafusion
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
apache/datafusion#27315 · 2 comentarios ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
apache/datafusion#27094 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Substrait consumer doesn't recognise `shift_left` / `shift_right` from functions_arithmetic.yamlPosiblemente ocupada @jonasHanhan la tomó hace 9 días. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
apache/datafusion#27059 ·
Los mantenedores suelen responder en 1 día
-
`ProjectionExprs::project_statistics` computes approximate `Statistics::total_byte_size` ignoring column statsPosiblemente ocupada @joseph-isaacs la tomó hace 10 días. Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
apache/datafusion#27050 ·
Los mantenedores suelen responder en 1 día
-
physical-plan: decoding an Unnest or Explain node with an unset field panicsPosiblemente ocupada @geoHeil la tomó hace 8 días. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
apache/datafusion#26999 · 1 comentario ·
Los mantenedores suelen responder en 1 día
Todos los issues de apache/datafusion
Issues similares
-
area:schema documentation
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 82/100
ElectronicWave/Elemental#252 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
dekobon/big-code-analysis#1887 ·
Los mantenedores suelen responder en 1 día
-
Shell中文符号输入异常Abiertobug
Dificultad 2/5 1-3 horas Aptitud para principiantes 76/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
Los mantenedores suelen responder en 1 día