Skip to content

Unsigned dtype blindness in remaining consumers: TUI grid, filter predicates, Calcite U32/U64 #216

Description

@dfa1

Follow-up to #208 (fixed for CSV export in #213). The survey done there found the same dtype-blindness — stringifying or widening typed getters without consulting unsignedness — in these consumers:

  • cli/src/main/java/io/github/dfa1/vortex/cli/tui/GridRender.java:61-64Long.toString(getLong) / Integer.toString(getInt) / Short.toString(getShort) / Byte.toString(getByte): U8–U64 high-half values render negative in the TUI grid.
  • cli/src/main/java/io/github/dfa1/vortex/cli/tui/InspectorRender.java:51-54 — identical pattern.
  • cli/src/main/java/io/github/dfa1/vortex/cli/FilterCommand.java:203-206compareValue compares raw signed getters, so filter predicates on unsigned columns are wrong for high-half values (e.g. magnesium >= 130 on uci-wine misses rows).
  • calcite/src/main/java/io/github/dfa1/vortex/calcite/VortexTable.java:812-817 — U8/U16 correctly widen via getInt, but U32 -> getInt and U64 -> getLong surface raw signed values to Calcite.
  • calcite/src/main/java/io/github/dfa1/vortex/calcite/VortexAggregates.java:107,112scanSum accumulates raw getInt/getLong into a signed sum; U32/U64 sums are wrong for high-half values.

The filter and Calcite items are silent-corruption class (wrong query results); the TUI items are display-only. ByteArray.getInt/ShortArray.getInt already zero-extend per dtype — the U32/U64 cases need the same treatment CSV export got in #213 (isUnsigned gate + unsigned widening/strings, and for sums an unsigned-aware accumulation or a documented refusal).

Found by the Raincloud conformance work (#205).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions