Size score-column precision to the column's variation, not its minimum

[matthewcornell]

Fixes #88.

Score columns took their decimal count from the smallest value in the column and applied it to every value via toFixed(), so a column's significant figures tracked its minimum rather than its variation. On the flusight dashboard wis__log spans [0.19, 1.27], so one decimal cleared the old rule's "nothing rounds to zero" bar and 21 of 58 models rendered as the same 0.3 — while wis next to it carried four digits nobody could act on.

What changed

min_decimals_for_values() → score_decimals(): picks the decimals that resolve the column's variation (two effective digits, Ehrenberg 1977) and caps how many significant figures the column may carry. get_round_decimals() keeps its name, signature, and its relative-skill / coverage special cases, and delegates the rest.

New render_score() for the per-cell string. Values too small to survive the column's rounding render as <0.01 / >-0.01 rather than a bare 0, so a column-wide rule never claims a real non-zero score is zero.

Effect on the real 58-model flusight data:

column	IQR	before	after	renders
wis__log	0.161	1	2	0.19 0.42 0.26
ae_median__log	0.176	1	2	0.32 0.68 0.39
wis	35.5	1	0	184 67 53 393
ae_median	36.5	1	0	291 101 77 498

Distinct rendered strings in WIS (log): 7 → 34 across 58 rows.

Two decisions from the #88 thread, for review

No minSigFigs floor. WIS and MAE land at 0 decimals — 7.65 → "8", 183.7 → "184". @sbfnk: a short value isn't really one sig fig when the column's shared decimal position supplies the place value. @nickreich: fine dropping the decimal place on whole-number-scale columns. The floor considered earlier in the thread would have forced 183.70, so it's gone.

The cap is anchored on Q3, not Math.max — the one deviation from the code in my issue comment. A max-anchored cap lets one blown-up submission set the digit count for everyone:

values [0.42, 0.55, 0.61, 0.73, 0.88, 1.02, 1.19, 1.41, 2.05, 52000]
  max-anchored cap → 0 decimals → "0"  "1"  "1"  "1"  …  "52000"
  Q3-anchored cap  → 2 decimals → "0.42" "0.55" "0.61" …  "52000.00"

That is the same failure the IQR anchoring exists to prevent, reintroduced one line later. It's a no-op on all four real columns.

Not signif()

The issue suggested d3's .3~r / .3g, i.e. R's signif() — but that rounds left of the decimal point, and a national-scale MAE of 12345.6 would render as 12300. This rule stays decimals-based: toFixed() never touches integer digits, and the cap only ever removes decimals, bottoming out at 0. Every integer digit survives at national scale. Pinned by a test.

Also worth a look

• The table's render callback now guards on the DataTables type. render() runs for every type including sort, and a <0.01 sort key would silently switch the column to lexicographic ordering. Display and filter get the string; everything else gets the number.
• Both hovertemplates consume pre-formatted customdata instead of interpolating a .Nf spec, so a hover value and its table cell can't disagree about rounding. Colorbar tickformat unchanged.
• One judgment call I'd like a second opinion on: zeros are filtered out of the magnitude anchors but still count toward the IQR, so [0, 1.5, 2.3, 47.7] gives 1 decimal where [1.5, 2.3, 47.7] gives 2. My reasoning is that a zero is a real score and belongs in the column's distribution. Pinned by a test either way — easy to flip if you disagree.

Testing

npm test — 82 pass, 0 fail. The min_decimals_for_values tests are replaced wholesale (they asserted the min-anchored contract directly). New coverage: the 58-value flusight wis__log fixture, the national-scale case, both outlier directions, and a test/ui.js module running column values → decimals → cell string end to end plus the sort-key regression. Bundles rebuilt.

🤖 Generated with Claude Code

[matthewcornell]

I've created a live preview here: http://hub-data-preview.s3-website-us-east-1.amazonaws.com/eval.html . You can compare it to production: https://reichlab.io/flusight-dashboard/eval.html

[nickreich]

I checked it out and it looks good to me. Thanks for tackling this, @matthewcornell !

[matthewcornell]

Thanks, @nickreich ! @sbfnk : Any thoughts, or does this look good to you too?

[matthewcornell]

I had Claude do a fresh analysis of this PR, and it found some issues. I had it address them (see 762d77f message for details) and updated the preview site. I think we're good to merge.

[nickreich]

Could this be more explicit about exactly what it is testing and what our stated desired behavior is?

I can't quite tell what the tests are asserting the desired behavior is. If we had the set of scores [0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.5, 0.52, 52000] then I think we'd want 1 decimal place (maybe 2?). But I can't read from the code what it is testing.

[matthewcornell]

[Claude reply] Good call — that was hard to read, and I've pushed comments that state the case and the desired behavior for every test in get_round_decimals, score_decimals and render_score, plus a header over the score_decimals module laying out the rule as four numbered statements the individual tests refer back to.

On your example specifically: [0.5 ×8, 0.52, 52000] gives 3 decimals, not the 1–2 you expected, and I think 3 is right — but the disagreement is worth settling, since it's the rule itself and not a fallback misfiring.

Q1 and Q3 are both 0.5, so the IQR is zero and the window widens to P10–P90, giving a spread of 0.02. The rule then shows roughly two digits of that spread — 0.020 — which is 3 decimals. Two decimals is all it takes to merely tell 0.50 from 0.52; the third is the same two-effective-digits rule that gives the flusight wis__log column 2 decimals from its 0.161 spread. So the choice is between "enough to separate adjacent rows" and "two digits of the spread", applied consistently. The rows render as 0.500 and 0.520 (and the outlier as 52000.000, which is the ugly part).

If you'd rather target the first of those, that's a change to effDigits and not to the tests. The test comment now names the discrepancy in as many words so the next reader meets it where the surprise is.

[nickreich]

I'm approving, but ... I was trying to look over the test cases to assess how well the current code is capturing and dealing with the various scenarios that we laid out. I found it hard to read the code and understand this. It would help me if each test had a specific natural language statement of the situation that it is solving (the brief test('...') lines are not enough for me) and the desired behavior. I left one specific comment to this effect.

[matthewcornell]

@nickreich I had Claude add test comments. Please take a look. Thank you.