A few days ago, Joel Courtheyn posted the following issue in the `errors`

package repository on GitHub:

Experimenting with the new package I detected a difference in calculation of the error depending on the way a formula was written. Originally I tried to calculate the error for

`z1 <- (x^3 - 2y)/x^0.5`

but this gave me a value which was different from the manual calculated error. When I transformed this formula to`z <- x^2.5 - 2y*x^(-1/2)`

, then I came to the right results.

As I wrote there, the TL;DR version is that both calculations are correct, but the first formula is an abuse of notation. What do I mean by that? Let us consider a shorter but more intuitive version of the issue: `x + x`

vs. `2*x`

. In the first place, we define a quantity with a relative uncertainty of 5 %:

```
library(errors)
options(errors.notation = "plus-minus")
x <- 30
errors(x) <- x * 0.05
x
```

`## 30 +/- 2`

Now, let us see what happens:

`x + x`

`## 60 +/- 2`

`2*x`

`## 60 +/- 3`

First of all, we need to keep in mind that measurements with errors are not mathematical variables anymore: they are physical (in a broad sense) quantities. Imagine that we want to measure the width of a table, but we have a ruler that is only about half its width. So we manage to put a mark, by the means of some method (using a string, for instance), approximately at about half of the table. Then, we have two options: 1) to measure the first half and multiply it by two, or 2) to measure both halves and sum them.

Intuitively, 1), which corresponds to the `2*x`

case, has a larger uncertainty, because we are not measuring the second half of the table (and note that this is exactly what we obtained before!). But in 2), even if the result of the second measurement matches the first one, `x + x`

is an abuse of notation: **they are different measurements**, so we should write `x + y`

instead, and the derived uncertainty is smaller.

Therefore, we can scale a certain measurement, apply any function to it… but to sum, multiply, divide… a measurement by itself has no physical meaning. is mathematically true, but `x + x`

has no physical sense. We should say `x + y`

(even if`x`

is the same value as `y`

), and `x + y != 2*x`

when it comes to propagation of the uncertainty. The `errors`

package helps us in the arduous task of uncertainty propagation, but checking the physical correctness of the expressions of derived measurements cannot be automated, and it is still our responsibility.