[Feature request]: Support numbers with multiple uncertainty descriptions

[RungeCC]

Motivation

In physics (particularly high-energy and nuclear physics), it is common to encounter values with more than one uncertainty component. This is usually due to multiple sources of error, such as "Statistical" vs. "Systematic" uncertainties. Sometimes, specific parts of the systematic error are even distinguished separately (e.g., luminosity error, calibration error).

It would be highly beneficial if zero could support multiple, labeled uncertainty components to accurately represent data.

Proposed API

#import /* zero path */: num
#let num1 = num.with(
  uncertainty-mode: "separate",
  uncertainty-labels: ("stat", "sys", ), // array or a function with type int => content | str | none, `none` means no label
  uncertainty-label-function: (u, l) => $#u_#l$ // or we could combine this with `uncertainty-labels`, it becomes a function that receive (index, uncertainty) and return content.
)
#let num2 = num.with(
  uncertainty-mode: "compact",
// by default no label
)
$
num1("1.48(23)(42)", )
// equivalent to: 1.48 plus.minus 0.23_"stat" plys.minus 0.42_"sys"
num1("1.48+.20-.31+.14-.22", )
// equivalent to: 1.48^(+0.20_"stat"+0.14_"sys")_(-0.31_"stat"-0.22_"sys")
num2("1.48+-0.32+-0.42", )
// equivalent to: 1.48(32)(42)
$

Table Alignment should also work for each part of uncertainties.

Affect on Current Behavior

Shall be none, since originally those would cause syntax errors in zero.

[Mc-Zen]

Hi @RungeCC ,

sounds like a reasonable addition! I need to think a bit about the design and will come back to you.

[Mc-Zen]

Hi @RungeCC ,

A few thoughts on your proposal.

• The idea with setting the uncertainty labels once is good to reduce redundancy. I'm just a bit unsure with encoding the uncertainty labels into index positions. Could this be an easy source of errors when the order is messed up accidentally? But maybe it's okay.
• In the case of the design proposed by you, I want labels to be implemented in a way that they are always there and not something added explicitly: By default, all labels will be thus set to none. This will lead to num[21+-3+-4] -> $21\pm3\pm4$. When setting uncertainty-labels: ("stat", "sys"), this will set the first two labels to the corresponding string values. Any further uncertainties will still have labels none, i.e., num[21+-3+-4+-1] -> $21\pm3_\mathrm{stat}\pm4_\mathrm{sys}\pm1$.
• Another problem with the index-based ordering: What if there is a number with no statistical but a systematic error? Should we write num[21+-0+-3] and all uncertainties with value 0 are always omitted? Edit: with parentheses notation it would be not as bad and much more readable: num("21()(3)").
• Do you think uncertainty-label-function will be necessary? Are there other possible formats instead of subscript qualifiers? I think customization of this part is better suited through show rules once the components of Zero becomes types.

An alternative option for the interface would be

// first define all possible labels and their look
#set-num(uncertainty-labels: (stat: [stat.], sys: [sys.]))

// explicitly label each uncertainty
#num("123.2", uncertainty: (stat: [.2])) // or just "pm" instead of "uncertainty"

This would solve the index-related issues and is clearer to read but it is also much more verbose.