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:


\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}

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.?
    – egreg
    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
  • 2
    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.)
    – Joseph Wright
    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


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.