simplify_expressions misoptimizes +0.0 vs -0.0 literal equality/inequality conjunctions via ScalarValue::PartialEq
Maintainer antworten meist innerhalb von 1 Tag
@AnuragRaut08 arbeitet bereits daran.
Seit 12.11.2026.
Bewertung
- Schwierigkeit
- 3/5
- Geschätzter Aufwand
- 1-2 Tage
- Anfängerfreundlichkeit
- 69/100
Rechercherichtung
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.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
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
- Vorherrschende Sprache
- Rust
- Sterne
- 9.6k
- Forks
- 2.6k
- Ø Merge
- 3 T. 4 Std.
- Gemergte PRs (30 T.)
- 345
Entwicklungsumgebung
Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.
- Kein Dockerfile und keine Docker-Compose-Datei
- Hat eine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus apache/datafusion
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
apache/datafusion#27315 · 2 Kommentare ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
apache/datafusion#27094 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
-
Substrait consumer doesn't recognise `shift_left` / `shift_right` from functions_arithmetic.yamlEvtl. vergeben @jonasHanhan hat das vor 9 Tagen übernommen. Offenbug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
apache/datafusion#27059 ·
Maintainer antworten meist innerhalb von 1 Tag
-
`ProjectionExprs::project_statistics` computes approximate `Statistics::total_byte_size` ignoring column statsEvtl. vergeben @joseph-isaacs hat das vor 10 Tagen übernommen. Offenbug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
apache/datafusion#27050 ·
Maintainer antworten meist innerhalb von 1 Tag
-
physical-plan: decoding an Unnest or Explain node with an unset field panicsEvtl. vergeben @geoHeil hat das vor 8 Tagen übernommen. Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
apache/datafusion#26999 · 1 Kommentar ·
Maintainer antworten meist innerhalb von 1 Tag
Alle Issues in apache/datafusion
Ähnliche Issues
-
P3
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
HerringtonDarkholme/hd-lang#1770 ·
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 82/100
jonathanong/no-mistakes#3332 ·
Maintainer antworten meist innerhalb von 1 Tag
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
swc-project/swc-next-issues#310 ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
swc-project/swc-ai-issues#653 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
lbjlaq/Antigravity-Manager#3937 ·
Maintainer antworten meist innerhalb von 1 Tag