re: diff the legacy IDXD reader against the field table -- 17.54% wrong, with an exact predicate

Answers the backlog's open "first step: diff the two readers across the disc and
count disagreements", statically over every IDXD object.

Of 7750 objects and 738922 named fields whose true value is numeric, legacy
get_f32 is correct 39.42%, returns None (harmless) 43.04%, and returns a WRONG
NUMBER 17.54% (129612 fields).

The wrongness has an exact predicate: single-record objects 0 of 29822 wrong
(0.00%); multi-record objects 129612 of 709100 (18.28%).  The mechanism is in
get_raw itself -- it flattens the pool to a token list, finds the FIRST occurrence
of the key, and returns the preceding token, with no notion of records.  So every
record after the first inherits record 0's value: Weight truth=1.0 legacy=0.3,
Points truth=10000 legacy=4000.

Practical rule recorded: a get_f32 number from a single-record object is safe; from
a multi-record object only the first record is.

Withdrawn in the same document: my first sweep compared against "the string before
THIS field's own key" and reported 65.90% -- that is not what get_raw does, so the
figure is not the legacy reader's error rate.
This commit is contained in:
Sylpheed RE agent
2026-08-27 04:52:05 +00:00
parent a8e387b564
commit ef4e975a47
2 changed files with 70 additions and 0 deletions

View File

@@ -1559,6 +1559,13 @@ premise was wrong.**
of `get_f32`/`get_raw` is re-checkable against ground truth but **not yet
re-checked**. First step: diff the two readers across the disc and count
disagreements. Also open: recover the 504 unnamed hash keys.
**(2026-08-27) DIFFED — see [idxd-legacy-reader-diff](idxd-legacy-reader-diff.md).**
Over 7 750 objects and 738 922 numerically-valued named fields, legacy
`get_f32` is correct 39.42 %, safely `None` 43.04 %, and **returns a wrong
number 17.54 %**. The error has an exact predicate: **0 of 29 822** fields wrong
in single-record objects, 18.28 % wrong in multi-record ones — because
`get_raw` finds the *first* occurrence of the key in a flat token list and has
no notion of records, so every record after the first inherits record 0's value.
***(2026-08-25) Both guest hash routines located** — `sub_82447DF0` (IDXD)
and `sub_82447E70` (IXUD), transcribed instruction-for-instruction into Python
and Rust; `cargo test -p sylpheed-formats --lib hash` 10/10. **IXUD SOLVED:**