Support negative rounding and rounding by significant figures

[marcelgerber]

Overview

Rounding is a helpful strategy to reduce visual clutter and indicate true rather than false precision in our numbers.

Today, Grapher only allows you to round decimal places, e.g. a rounding level of 1 rounds 1.23423 to 1.2. In the past we supported negative rounding, but that has been broken for ~1y (as of Oct 2023).

Proposal

The research and data team would love two things to improve their data communication:

• Negative rounding. The ability to specify a rounding level of e.g. -3 to turn 12341 into 12000
• Rounding strategies. The ability to choose whether to round by decimal places or by significant figures.

Examples

• Deaths by cause has numbers that go from 16 to 25,724
  • If we rounded to e.g. 3 significant figures, it would become 16 and 25700.

Technical notes

• It might make sense to look at some implementations of number formatting:
  • Intl.NumberFormat
  • d3-format
• We currently display numbers in different fidelity in different places, e.g. in map legends, bar charts, tables, map sparklines.
  • It may be tough to find a heuristic that works well for all of these.

Related discussions

• (Mar 2022) https://owid.slack.com/archives/C035CTYEQE5/p1646391761911919
• (Jan 2023) https://github.com/owid/owid-issues/issues/918
• (Jan 2023) Requested by @bastianherre: https://owid.slack.com/archives/C46U9LXRR/p1672941627501059
• (Oct 2023) https://owid.slack.com/archives/C03NA1B2P1U/p1697018175122209

[ikesau]

This will probably be a matter of adding a new bit of config and adjusting formatValue (a wrapper for d3-format) as necessary. Fortunately there are lots of unit tests for the function so it shouldn't be too hard to implement once acquainted with how the function works.

[pabloarosado]

For the record, I've done a small analysis on the possibility of changing from 2 to 1 decimal digits. The conclusion is that we shouldn't do it without going case by case.
Fixing the problem of how to show significant figures (current issue) is much more meaningful than defining the number of decimals to show.

[marcelgerber]

@spoonerf requested sigfig-based rounding today.

[larsyencken]

This came up in discussion again just today around CO2 data for COP 28.

[larsyencken]

Reduced prio -- it shouldn't block today's work, but it's something we obviously really really would like.

[sophiamersmann]

• Related: Grapher omits decimals that happen to be zero, even when that decimal is a significant figure #1931

[danyx23]

This issue has a lot of relevant discussion on the data side that should be checked out in detail to get this to be ready to work on: https://github.com/owid/owid-issues/issues/918

One rabbit hole to figure out is how to combine this with the currently existing decimal points setting that we can use to limit the digits after the decimal point. To some degree this could be seen as redundant if we have significant figures but if we were to combine these it would mean doing a big migration that would involve a lot of manual work.

Sizing this issue properly will have to wait until we know more exactly what we want to do.

[larsyencken]

@danyx23 To secure agreement on the next step here.

[danyx23]

Just to document my current understanding of how we should tackle this (before chatting with Ed and Pablo R tomorrow) - I think we should:

• Add a new enum field in the display config of a variable in the ETL and in the grapher config to enable rounding to significant digits instead of normal decimal place based rounding (i.e. the new field "roundingMode" or sililar should have the default value "decimal" but accept also "significance")
• Enable negative numbers for rounding again that should work with decimal rounding (so that -3 rounds to thousands always)
• for significant digit rounding only, negative decimals could be confusing and probably when significant digit rounding is enabled, both 2 and -2 should round to 2 significant digits, 3 and -3 to 3 SD and so on
• The main change in the codebase (aside from the infrastructure to handle the new config fields) would be to change utils/src/formatValue.ts:getType() to use not just the f (fixed decimal points) or s (significant rounding with SI units which we than convert to say "1.2 Million", ...) but also use r (significant rounding with decimal points). See also Ike's number format observable notebook.

[danyx23]

I discussed this with Pablo R and Ed today. These were some additional findings:

• Negative rounding is a nice to have - it probably makes sense if it's not a lot of work but we'll probably use significance rounding most of the time instead of negative decimal rounding
• We'll want the new significance rounding to work on tooltips and on the values display in bar charts. Other uses should probably be discussed on a case by case basis. We also chatted about what to show in tables - for now we'll stay with non-rounded values but in the future it might be useful to have a use option to switch to showing rounded values if they are configured for the chart view
• Values above 1 million should be shown as they currently are even when significance rounding is enabled (i.e. with the s rounding mode that we then translate to show 1.4 billion or whatever and not show 1.400.000)
• In the tooltip, when significance rounding is active, a small gray note at the bottom of the tooltip should mention this and say "Values are rounded to N significant figures". If showing the values for N is complicated then just a general note would also be fine.
• We didn't discuss if such a note should also be present for bar charts - maybe not?