0.1.7

pip install --upgrade rosetta-eclab

A missing harmonic is named again when several columns are unknown

• 0.1.6 stopped name elimination from giving every unknown column the name of the one missing sibling. That also lost the right answer: in 12 public impedance and MB files, the real |Ece h7| got ABSTAIN (7) or the wrong name Pwe (5).
• Now a missing harmonic goes to the one unknown column with the storage type EC-Lab uses for it and the sign and scale of its numbered siblings (|Ece h2| … |Ece h6| for |Ece h7|). It goes to no column in these cases:
  • fewer than two of its numbered siblings have data;
  • a second column fits, or the only one that fits is constant or a copy of a known column;
  • the siblings disagree on a scale;
  • another harmonic of a family the file holds is missing too;
  • the reader is not sure where the columns end.
• In all 12 of those files, |Ece h7| is named right, at confidence 0.9. On the 36 public files with columns galvani does not know, names that differ from the answer key fall from 17 to 12, and no other answer changes.
• Replays through Rosetta's reader gave two to five known columns of the public files new IDs: 81,718 cases with a missing harmonic. The rule named the harmonic right in 70,934 and never gave its name to a wrong column.
• Gaps whose siblings differ in a word, such as THD Ece next to THD Ewe and NSD Ece, are not filled by elimination when several columns are unknown. Those siblings are other quantities, and their size says too little.
• This is not a blind result. The rule was designed on those 12 files, and its failures were found and fixed on the same files and replays. Details are in results/open_runs.md.

The reader tries every split of the record

• With several unknown columns, the reader tried only the first 200 ways to split the unexplained bytes into columns. It now tries all of them. A public file with 8 unknown columns reads in a second or two instead of about 100 s.
• Among the splits nearly as plausible as the best, it takes the one that leaves the most known columns readable as their own type. It notes when another split would read more of them.
• All 932 distinct public files decode exactly as before.
• In recoded copies of public files with two or three unknown columns, 1,744 that were split wrong are now split right: 829 among 6,260 recodings of test files and 915 among 40,509 of hold-out files. In those recodings, none that was split right is split wrong, and 881 are still split wrong.
• With six or more unknown columns, a split that the old search never tried can look more plausible than the right one. In one reviewer's search of 14,289 recodings with 6 to 8 unknown columns, 4,991 decoded better than in 0.1.6 and 20 worse, comparing every column's values. Across all their runs, reviewers found 45 distinct recodings that 0.1.6 decoded right and the reader now decodes wrong, all with 6 to 8 unknown columns.
• Corrupt columns can also mislead the reader. In copies of the one public file with corrupt harmonic columns, reviewers found 10 recodings, with 3 to 7 unknown columns, that 0.1.6 split right and the reader now splits wrong.

Unchanged

• With one unknown column, and in --self-check on every public file, every answer is the same as in 0.1.6. Golden: 1527 answers, 0 differences. The every-column sweep is identical.
• Eight tests were added.