Search before asking
Paimon version
master @ 005dbff
Compute Engine
Engine-agnostic Java code generation.
Minimal reproduce step
Generate a RecordEqualiser for a DOUBLE or FLOAT field and compare rows containing NaN, non-canonical NaN payloads, or signed zero. The same issue appears through GenericRow, the current BinaryRow fast path, nested arrays, and map keys containing floating-point fields.
What doesn't meet your expectations?
The generated equaliser uses primitive == for floating-point fields. This makes NaN unequal to itself and treats signed zero as equal, while generated comparators already use Float.compare and Double.compare. Raw row/array fast paths and Java map key lookup can also bypass generated floating-point comparison semantics.
Anything else?
The adjacent comparator issue was fixed in PR #8295. This fixes the same floating-point semantics for generated equality, including nested generated scalar equality and raw equality/key-lookup guards.
Are you willing to submit a PR?
Search before asking
Paimon version
master @ 005dbff
Compute Engine
Engine-agnostic Java code generation.
Minimal reproduce step
Generate a
RecordEqualiserfor aDOUBLEorFLOATfield and compare rows containingNaN, non-canonical NaN payloads, or signed zero. The same issue appears throughGenericRow, the currentBinaryRowfast path, nested arrays, and map keys containing floating-point fields.What doesn't meet your expectations?
The generated equaliser uses primitive
==for floating-point fields. This makesNaNunequal to itself and treats signed zero as equal, while generated comparators already useFloat.compareandDouble.compare. Raw row/array fast paths and Java map key lookup can also bypass generated floating-point comparison semantics.Anything else?
The adjacent comparator issue was fixed in PR #8295. This fixes the same floating-point semantics for generated equality, including nested generated scalar equality and raw equality/key-lookup guards.
Are you willing to submit a PR?