# Wrong value with Decimals and Uncertainty in siunitx

I am using siunitx to typeset values with uncertainty, and I'm getting (what I think is) the wrong value in some cases. I'm using separate-uncertainty=true because it makes my examples clearer, but the problem occurs either way.

First, note that \num{3} produces 3 while \num{3.} produces 3.0. I don't really agree with this choice, but it's reasonable because otherwise the decimal wouldn't mean anything. This is directly relevant to the problem I'm having.

The number \num{3 \pm 3} yields 3±3, as I expect. However, \num{3. \pm 3.} yields 3.0 ± 0.3, which I do not expect. This is true for values in scientific notation, too; \num{3. \pm 3. e10} yields (3.0 ± 0.3) × 10^{10}. Whether the uncertainty value has a decimal doesn't seem to matter: \num{3. \pm 3.} gives the same incorrect result as \num{3. \pm 3}.

A minimal example is:

\documentclass{article}
\usepackage{siunitx}

\begin{document}
\num[separate-uncertainty=true]{3  \pm 3}
\num[separate-uncertainty=true]{3. \pm 3.}
\num[separate-uncertainty=true]{3. \pm 3. e10}
\num[separate-uncertainty=true]{3. \pm 3}
\end{document}


From the logfile, the version of siunitx is:

Package: siunitx 2016/03/01 v2.6q A comprehensive (SI) units package


I think this means the bug mentioned in a different question about integer values being typeset with a decimal has already been fixed, but I'm not sure.

My question is, what is going on here? Is there a way to avoid this behavior?

Edit: This question came about because I'm generating a data-rich table using a float format specifier ((fX.Y) in Fortran). If the number of digits to print after the decimal is zero, the decimal is still printed. I can modify this specific behavior - if the trailing character is a decimal, remove it - and I'll probably make this change. However, I would like to understand the behavior better, avoid it by other means if possible, and let others know about the issue.

• Is there a reason for writing 3.? Aug 14, 2018 at 22:12
• I've added something to the question to answer your question @egreg . Basically, I don't have to but it's inconvenient to fix.
– Ross
Aug 14, 2018 at 22:20
• Clearly a bug: I'll have to think whether it's fixable in the 2.x series (3.x is now working at a core level, for testing, and the bug isn't present.) Aug 15, 2018 at 6:10
• Thanks for the response - let me know what you decide. I have my workaround working now, but it wouldn't surprise me if others haven't noticed it occurring.
– Ross
Aug 15, 2018 at 6:23
• Also, @JosephWright, if you make an answer specifically describing what's bugged and what's as-designed (ie, 3. interpreted as 3.0 is ok, but uncertainty of 0.3 is wrong), I'd be happy to accept it.
– Ross
Aug 15, 2018 at 6:24