Incorrect formatting with round-mode set to uncertainty

[AxelKrypton]

Before describing the issue I am having, let me stress that I am amazed by the effort of the authors of this package and in particular a huge hat-off to @josephwright for all you managed to implement! :sunglasses: :top:

The feature I have been missing for lot of time is the following. When it comes to format numbers with uncertainties it would be extremely useful to delegate this task to siunitx, e.g. while including results in a scientific paper, where the results should be formatted in a very precise way. In particular, the uncertainty should have one significant digit and the number should be rounded accordingly. With v3 I guess we are almost there, but I am not sure all many corner cases - yes, many not so realistic, I know - are covered. I took from #179 the data in there and tried to see what the last version produces and I would have expected different outcome for quantities whose uncertainty is on the left than the unit digit. I tried to summarize in the table below what I believe it should be happening.

In general, I also find #415 a rather powerful enhancement and if e.g. \num{5.22e+07 +- 7.11e+06} could produce 52(7)\times 10^6 would be fantastic. The rationale behind is that it would then be possible to simply paste the full analysis outcome (with all digits) in the TeX source file and then let siunitx do the rest for the final paper. I am convinced that this would be a very welcome feature (at least for physicists in my area).

What you mention in #345 would also definitely be worth to have and, in particular, it would be nice to be able to keep a second significant digit for uncertainties that start not only with 1 but also with 2. This is the rule that physicists usually follow and an example can be found in the last column here below.

\listfiles
\documentclass{article}
\usepackage{siunitx,booktabs,array,pifont}

\newcommand{\yes}{\ding{51}}
\newcommand{\noo}{\textcolor{red}{\ding{55}}}
\newcolumntype{L}{>{$}l<{$}}

\begin{document}
  \begin{tabular}{c
    S[table-format=5.1]
    @{${}\pm{}$}
    S[table-format=3.1]
    @{$\quad\to\quad$}
    S[table-format=5.1(1), round-mode = uncertainty, round-precision = 1]
    LL}
    \toprule
    & \multicolumn{2}{c}{Number} & {\texttt{siunitx v3.0.23}} & \text{Expected} & \text{Alternatively}\\
    \midrule
    \yes &    126.0  &    0.5  &     126.0 +-   0.5  &  126.0(5)            & \\
    \noo &   3014.2  &   35.5  &    3014.2 +-  35.5  &  301(4)  \times 10   & \\
    \yes &    115.9  &    1.9  &     115.9 +-   1.9  &  116(2)              & 115.9(1.9)\\
    \noo &   2859.9  &   31.7  &    2859.9 +-  31.7  &  286(3)  \times 10   & \\
    \noo &   4560.4  &  216.2  &    4560.4 +- 216.2  &  46(2)   \times 10^2 & 456(22)\times 10\\
    \yes &    310.2  &    3.0  &     310.2 +-   3.0  &  310(3)              & \\
    \noo &  11552.7  &   44.0  &   11552.7 +-  44.0  &  1155(4) \times 10   & \\
    \yes &   4135.7  &    8.2  &    4135.7 +-   8.2  &  4136(8)             & \\
    \noo &   4087.1  &  106.4  &    4087.1 +- 106.4  &  41(1)   \times 10^2 & 409(11)\times 10\\
    \noo &  26301.0  &  251.4  &   26301.0 +- 251.4  &  263(3)  \times 10^2 & \\
    \noo &    992.0  &   11.8  &     992.0 +-  11.8  &  99(1)   \times 10   & 992(12)\\
    \noo &   1704.4  &   10.1  &    1704.4 +-  10.1  &  170(1)  \times 10   & 1704(10)\\
    \yes &  13646.0  &    6.6  &   13646.0 +-   6.6  &  13646(7)            & \\
    \bottomrule
  \end{tabular}
\end{document}

[josephwright]

There are two parts here: a bug (which I think I understand the reason for, but may take a few days to fix), and one or possibly two feature requests. Could you log the latter separately - I have some comments on it but I'd rather deal with in a different place.

[josephwright]

Ah, I see the feature requests are already logged :)

[josephwright]

I've never seen an uncertainty keeping 2x as well as 1x: can you point to an example? (I know the rule only from single crystal X-ray crystallography, where the floor is typically treated as 14, so 15 rounds to 2 whereas 14 is left as is.)

[josephwright]

On the bug part: it arises as I've taken a few attempts to get to a workable position for what to do with the case where the uncertainty is in the integer part. With for example your input 3014.2 \pm 35.5 I've always taken the position that any exponent shift is independent of any other manipulation, so it will be (internally) 3010(40) - if someone wants to handle non-significant zeros, they really need to first adjust so the situation is clear (i.e. the zeros are present if at all in the decimal part).

[AxelKrypton]

About the aspect of retaining two figures with 2x as well as 1x, I simply was taught like that during my physics studies and many international colleagues share the same knowledge. I have to be honest, though: It does not seem to be either something people tend to remember and use, or a very strict rule. I just looked around in the web and it is hard to find something precise. Apparently (I did not know it), it is not uncommon to always report two digits and the CODATA TGFC (Task Group Fundamental Constants) is doing so. Here some more discussion along the line. I also found what I learnt in my studies e.g. here. So, after all, I guess the package has already most of what people need, but maybe you could still in #345 let the user choose whether to keep a second digit with 1 only or with 2 as well (it should not be tough once you have it implemented for 1).

On the bug side, thanks for fixing it and I totally agree with how you went. Actually I just noticed now that using scientific notation via exponent-mode = scientific will automatically handle trailing zeroes and transform 3014.2 \pm 35.5 into 3.01(4)\times 10^3 which is actually what I was looking for.

Just a last comment to share. I will never forget the day I naively wrote on my lab book that I used a resistance of 1000Ohm instead of writing 1kOhm. My professor came to me and asked: Do you think this cheap resistance is guaranteed by the manufacturer to be exactly one thousand ohm with not more than one per thousand uncertainty!? - implicitly, writing 1000 means to know that the last three digits are zeroes, whereas 1\times 10^3 gives a completely different message. :sweat_smile:

[josephwright]

@AxelKrypton I have a few more things to check but expect a release today/tomorrow. Glad that rounding-to-uncertainty is useful: it's been requested for years.