FLOAT/DOUBLE partition filters and manifest partition stats disagree with Java on NaN and -0.0 #1189

Search before asking

• I searched in the issues and found nothing similar.

Description

Follow-up to #1174, for FLOAT/DOUBLE partition values.

1. Row evaluation (eval_row, used by partition and bucket filters) compares with partial_cmp. Any NaN fails every comparison, and -0.0 == 0.0. Java's Float.compare / Double.compare put every NaN above +Inf and equal to itself, and -0.0 below 0.0. Against paimon-bundle 2.1.0, 144 of 768 value × literal × operator cases differ.
2. compute_partition_stats builds the manifest's partition min/max with <= / >=, so a NaN or -0.0 partition makes the bounds depend on entry order. That order changes between runs, and planning can then drop partitions that match.

Repro: a table partitioned by a DOUBLE p with partitions 0.0, -0.0, NaN and 1.0, one row each. Java's predicate matches the NaN and 1.0 partitions for p > 0.5. Rust returns the 1.0 row on some runs and nothing on others.

Not covered here: stats pruning also treats -0.0 as equal to 0.0, so p < 0.0 drops the -0.0 partition.

Are you willing to submit a PR?

• I'm willing to submit a PR!