I am trying to typeset the value 2.4 +/- 0.009 using the siunitx package and the \num command. However, once I switch siunitx to show the uncertainty with a \pm character, it removes one decimal zero.




    \num[separate-uncertainty=true]{2.4 \pm 0.009} \\
    \num[separate-uncertainty=false]{2.4 \pm 0.009}


2.40 ± 0.09 (missing one decimal)

2.40(9) (also incorrect, see comment)

Am I making a mistake, or is there something wrong in the siunitx package? Or did I miss a necessary option?

Edit: I apparently misunderstood the meaning of the parenthesis notation, where the number in parenthesis is the ± value for the digit(s) left of it. However, this just means both typesetted values are wrong, and not only the first as I had assumed initially.

Edit 2: I just contacted the package's author. Apparently he is aware of the problem, and as Bernard commented below, consideres the input invalid (since it does not have enough digits for the given uncertainty). However, he will have a look at it.

  • 2
    Nothing is wrong - you have just misunderstood the notation of uncertainty. en.wikipedia.org/wiki/Uncertainty Apr 17, 2017 at 22:46
  • @hpekristiansen: Admittedly, I misunderstood the meaning of the parenthesis notation (will edit this in a second). However, that just means that both results are simply wrong? If I explicitly state to have 2.4 \pm 0.009, I do NOT want anything to change this to 2.4 \pm 0.09, since this isn't a question of notation anymore.
    – Timm
    Apr 17, 2017 at 22:59
  • Ok - I see now. Bernard gives the solution - you need the correct number of digits on the number part of the input. Apr 17, 2017 at 23:03
  • 1
    There is a bug but the input is defective (there simply are not enough significant digits).
    – Joseph Wright
    Apr 26, 2017 at 21:24

1 Answer 1


Write \num{2.40\pm 0.009} or \num{2.400 (9)}.

  • This actually solves the problem. Would anyone consider this a bug to report, or is there reason behind it that I don't see?
    – Timm
    Apr 17, 2017 at 23:04
  • 2
    Not sure,but I think conventionally, an uncertainty cannot have more decimal digits than the estimated value.
    – Bernard
    Apr 17, 2017 at 23:07
  • I accepted this answer now. I understand the idea about the number of digits, however still think the current behaviour of the package simply is wrong since it modifies the numbered input.
    – Timm
    Apr 19, 2017 at 8:52

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .