Decimal point in uncertainty in "parenthesis" format

[alusiani]

When using parenthesis format, a value like 12.34 +- 5.67 is formatted as "12.34(567)". That is slightly misleading for the average reader, in my opinion. Would it be possible to change the behaviour and to keep the decimal point in the proper position for the uncertainty? That would mean formatting "12.34(5.67)". I did achieve that with the following modifications:

  # get exponent of uncertanty before it is modified
  e_expon = get_exponent(e)

and later on

  if (notation == "parenthesis") {
    sep <- "("
    append[] <- ")"
    ## commented statement that always removes dec. point in uncertainty
    ## e[is.finite(e)] <- (e * 10^(pmax(0, value_digits-1)))[is.finite(e)]
    e_scale_flag = (cond & e_expon < exponent) | (!cond & is.finite(e) & e_expon<0)
    e[e_scale_flag] <- (e * 10^(pmax(0, value_digits-1)))[e_scale_flag]
  } else {

[Enchufa2]

The default behaviour is recommended by GUM; it's very compact and well-known.

[alusiani]

The default behaviour is recommended by GUM; it's very compact and well-known.

Thanks for the quick reply. I think that the default behaviour is acceptable, but I am not sure it is actually recommended by GUM. As far as I can read in their document, when they report uncertainty digits that correspond to value digits before the decimal point (comma in their notation) they do include the decimal point in the proper position, as in bullet 3. below.

Quoting from GUM 2008:

[ 7.2.2]   When the measure of uncertainty is uc(y), it is preferable to
state the numerical result of the measurement in one of the following
four ways in order to prevent misunderstanding. (The quantity whose
value is being reported is assumed to be a nominally 100 g
standard of mass mS; the words in parentheses may be
omitted for brevity if uc is defined elsewhere in the
document reporting the result.)

1. mS = 100,021 47 g with (a combined standard
   uncertainty) uc = 0,35 mg."

2. mS = 100,021 47(35) g, where the number in
   parentheses is the numerical value of (the combined standard
   uncertainty) uc referred to the corresponding last
   digits of the quoted result."

3. mS = 100,021 47(0,000 35) g, where the number in
   parentheses is the numerical value of (the combined standard
   uncertainty) uc expressed in the unit of the quoted
   result."

[Enchufa2]

Methods 2 and 4 (plus-minus notation) are the ones implemented in this package, as reported in the paper/vignette. You are proposing method 3, which is a mix of 2 and 4. It could be implemented as an opt-in notation, but I definitely want to preserve the current default, which is more compact and elegant (and is used by NIST, IUPAC...).

[alusiani]

Methods 2 and 4 (plus-minus notation) are the ones implemented in this package, as reported in the paper/vignette. You are proposing method 3, which is a mix of 2 and 4. It could be implemented as an opt-in notation, but I definitely want to preserve the current default, which is more compact and elegant (and is used by NIST, IUPAC...).

I interpret the method I propose as the natural extension of method 2 in the case when the uncertainty is large enough to affect digits on the left of the decimal point. Method 3 is not what I propose, because in the mentioned case the uncertainty is not large enough to affect digits on the left of the decimal point, and with my modification no decimal point would appear with those value and uncertainty.

As you can see in this answer I report in the following, to a question on stackexhange, the author of the reply agrees with my interpretation of section 7.2.2 point 3 as recommending the use of the decimal point for the uncertainty in parenthesis. I quote the reply:

Both forms are correct, but the uncertainty is rarely if ever reported in an abbreviated form in cases like that of your example. The first form [h=8.3(12)m, for h=((8.3±1.2)m] is definitely ambiguous and can be easily mistaken. The second one [h=8.3(1.2)m] is less ambiguous, but not well known (it's correct anyhow, see the Guide to the expression of uncertainty in measurement, §7.2.2, point 3).

Thus, you're both right, but, generally speaking, I'd avoid ambiguous forms.

I don't think that there is a single example in NIST and IUPAC where the uncertainty is reported in parenthesis without any decimal point in the case when the uncertainty affects at least one digit at the left of the decimal point, as in the ambiguous expression above.

In case I will submit a PR, at any rate, given your opinion on the matter, I will make my preferred behaviour as optional on request.

[Enchufa2]

As you can see in this answer I report in the following, to a question on stackexhange, the author of the reply agrees with my interpretation of section 7.2.2 point 3 as recommending the use of the decimal point for the uncertainty in parenthesis.

I don't think so. The author of that response acknowledges that form 1 is method 2 and form 2 is method 3 of the GUM, just as I was saying.

I don't think that there is a single example in NIST and IUPAC where the uncertainty is reported in parenthesis without any decimal point in the case when the uncertainty affects at least one digit at the left of the decimal point, as in the ambiguous expression above.

The expression is not ambiguous. To me, the GUM is pretty clear: uncertainty in method 2 is "referred to the corresponding last digits". It's a simple rule. If you write 8.3(12): 12 is referred to the last digit, a tenth, so it's 12 tenths. There is no possible ambiguity: if the uncertainty was 12 units, then it should be written 8(12) instead (both in methods 2 and 3), because you cannot report more precision that the uncertainty you give.

In case I will submit a PR, at any rate, given your opinion on the matter, I will make my preferred behaviour as optional on request.

I'm open to implement method 3 as... parenthesis-long maybe? But I don't like the idea of mixing up both methods.

[alusiani]

Just for documentation, I found that one of the most important precision measurement of elementary particle Physics, the final report of BNL E821 on the muon anomalous magnetic moment, reports the main results using uncertainties with the decimal point in parenthesis, like I proposed above.

From Phys. Rev. D 73, 072003, 2006, the result is reported as:

aμ(Expt) = 11659208.0(5.4)(3.3) ×10^-10