feat(gfql): searchAny WYSIWYG float + datetime search (#1695)

[lmeyerov]

What

Makes GFQL searchAny / search_nodes / search_edges match what the streamgl-viz inspector RENDERS for float and datetime columns — you search the displayed string, not the raw value (#1695). Adds WYSIWYG format call-params {floatPrecision, temporalFormat, tz}.

Floats were previously excluded from search because astype(str) diverges across engines (exponent regime + half-tie double-rounding). This makes the render byte-identical to the inspector and, per the parity-or-honest-NIE convention, keeps every engine either exact or an honest decline.

The decisive experiment (dgx cross-engine parity fuzzer)

Ran a float-render parity fuzzer on dgx-spark (all engines) with the real viz sprintf-js as the oracle. It settled the render and falsified the original "cross-engine decimal cast = parity" plan:

engine	verdict
pandas "%.4f" % v direct	✅ exact — byte-identical to sprintf-js (3.28045→"3.2805", 0.12345→"0.1235")
pandas w/ np.round prepass (old draft)	❌ double-rounds 73/210 half-ties (-3.74825→"-3.7482")
cuDF float→Decimal128	❌ truncates (wrong on generic values, not just ties)
polars Decimal cast	❌ diverges at 5th-decimal ties + drops sign on -0.0000

There is no native GPU printf, and a per-cell UDF would be a forbidden host-bridge. Datetime render verified byte-identical to real moment.utc for the UTC path.

Design

• Float: "%.4f" % v direct for fractional (single correctly-rounded conversion), str(int(v)) for whole. pandas-exact; cuDF/polars honest-NIE. inf→"Infinity" (matches JS).
• Datetime: reproduces the inspector's moment 'MMM D YYYY, h:mm:ss a z' via strftime, localized to a caller tz (per-timestamp DST-correct). pandas-only; cuDF/polars honest-NIE.
• Options API {floatPrecision, temporalFormat, tz}: threaded through the cypher option-map (strict typed parse), the ast op, call-validation, and the python twins; defaults to the inspector (4 decimals; UTC).
• Auto-gate (decision A, symmetric): float/datetime stay out of the auto-gate on every engine, so bare searchAny('...') behaves identically cross-engine; float/datetime are reached via explicit columns=. (@leo chose this over the "GPU raises" alternative.)

⚠️ Open decision for @lmeyerov

Datetime default tz='UTC' (chosen for determinism — a server-local default varies by deployment and would break the parity oracle / tests). You suggested "default to server time" — trivially switchable if you'd prefer that; the tz= call-param already delivers the localization knob either way.

Adversarial review (.agents/skills/review)

Multi-angle finders + verify. Three confirmed findings fixed: (1) inf/-inf render + RuntimeWarning; (2) am/pm lowercasing corrupting alpha tz abbrevs (AMT→amT) — now word-bounded; (3) negative/bool floatPrecision + empty tz silently misrendering via the twins (which bypass the safelist) — added kernel-level validate_format_opts + tightened the safelist. Cross-engine-safety and parity-invariant hypotheses were refuted (clean).

Testing

All on dgx-spark (test-rapids-official:26.02-gfql, pandas + cuDF + polars + polars-gpu):

• New test_search_any_float_wysiwyg, test_search_any_datetime_wysiwyg, test_search_any_format_options — pandas exact + cuDF/polars honest-NIE, half-tie/inf/tz/validation pinned.
• Full conformance + cypher suites: 2041 passed / 7 skipped / 15 xfailed, no regressions.

🤖 Generated with Claude Code

[lmeyerov]

Perf: interactive latency + the base-graph index question

Benchmarked the "typing into a search window" scenario on dgx-spark (pandas, 100K/1M rows, 8 mixed-typed columns), since each keystroke dispatches a fresh query but the columns+data are fixed.

Render optimizations landed (1ce40e6)

The per-keystroke render was the hot spot:

• Float: the np.char.mod/numpy-masked-scatter render was slower than a plain list-comp (multiple full-array passes + object boxing) — reverted to a list-comp, byte-identical, ~15% faster.
• Datetime: pandas dt.strftime is a ~20×-slow per-element path (~2.2s/1M). For the default format in UTC (common, deterministic) I now assemble the render vectorized from .dt components + a month lookup — byte-identical to strftime (verified incl. midnight/noon/single-digit-day/NaT). Custom temporalFormat / non-UTC tz keep strftime.

Per-keystroke @ 1M: datetime 3111ms → 1512ms (2.05×), float 674ms → 557ms.

The index question (base vs view) — quantified

The render is term-independent, so it should be computed once and reused. Measured @ 1M / 8 cols:

approach	per-keystroke	vs today
(A) today — render+match every keystroke	2903 ms	1×
(B) per-column render cache — render once, N Contains	439 ms	6.6×
(C) concatenated search-blob index — render+join once, 1 Contains	68 ms	43×

• One-time build (term-independent): blob 567 ms; per-column cache 2480 ms.
• Base vs view: slicing the base blob to a 50% filtered view = 8 ms slice + 36 ms keystroke — so the index lives at the base-graph level and slices to the filtered/rendered view; no per-keystroke re-render.

Recommendation: a base-graph search-text index — a single concatenated, lowercased WYSIWYG search-text column built once per (data, format-options), sliced to the active view, so each keystroke is one Contains. That's the 43× win and it's what turns 1M-row interactive search from ~3s to ~68ms/keystroke. It's an architectural addition (where the index lives on the Plottable, invalidation on data/option change, integration with the chain/viz dispatch) — proposing to track it as a follow-up unless we want it in this PR.

(The correctness feature in this PR is unchanged and CI-green; the render opts are pure speedups with byte-identical output.)

[lmeyerov]

Search-text index follow-up filed: #1703 (base-graph blob index, 43× interactive win, cross-referenced to the #531/#1658 CREATE INDEX stack per @lmeyerov). The render speedups in this PR are the standalone, byte-identical part.