Confidence intervals override rounding digits

[Ants-Aare]

#num(digits:1 round:(precision:1))[20+-0.200000000000]

this displays with a dozen zeroes after the decimal point, I'd expect it to display as 20.0 +- 0.2 I'm creating these confidence interval values using a function and don't want to manually do calc.round(0.20000000, digits:2) as that kind of defeats the purpose. Just let me set the amount of significant digits.

#num(digits:2, round:(precision:2, mode:"uncertainty"))[20+-0.065333333333333333]\
#num(digits:2, round:(precision: 2, mode:"uncertainty"))[20+-0.23556268333031394]

the only way I’ve found to do this is to set mode to “uncertainty” but then the number is still inconsistent. the first renders as 20.000+-0.065 and the second as 20.00+-0.24 why do they have different amounts of digits with the same settings of 2 digits? I would expect them to be the same with the first rounded to 0.07 and the second to 0.24 this is really annoying when in a table.

#num(digits:2, round:(precision:1, mode:"uncertainty"))[20+-0.065333333333333333]\
#num(digits:2, round:(precision: 1, mode:"uncertainty"))[20+-0.23556268333031394]

I can set the precision to 1 but then both have the same amount of digits, but the second value is shown as 20.00+-0.20 instead of 20.00+-0.24.

ideally I’d just set round to precision:2 without any additional settings and be done with it, but then it's showing way too many digits.

[Mc-Zen]

Hi @Ants-Aare ,

let me first explain what is going on and why.

this displays with a dozen zeroes after the decimal point, I'd expect it to display as 20.0 +- 0.2

When you give it a very precise uncertainty like 0.2000000000, Zero retains all digits and adapts the number to match the uncertainty. A trailing 0 is no different than any other digit, it carries information about how precise the value of the number is known. 0 is only different for leading digits.

the only way I’ve found to do this is to set mode to “uncertainty” but then the number is still inconsistent.

As mentioned in the documentation, in the uncertainty rounding mode, the precision relates to significant figures of the uncertainty. And in this regard the numbers are actually consistent: both uncertainties have 2 significant figures.

Note that the digits parameter is most likely not the right tool here. I know that it is very prominent in the docs because it is listed as almost the first parameter but this is not what you're looking for in most cases. I should move this parameter down in the documentation and clarify it's meaning better.

On a sidenote: With #85 , the rounding model has just changed quite a bit (this will be in the next release) but for your case I think it makes no big difference.

Could you maybe explain where the numbers, in particular the uncertainties come from? Usually you'll want to specify uncertainties with just one figure (rarely two) and should be fairly consistent with it. If an uncertainty is larger (in an absolute way), the corresponding value is known less accurate and it just makes sense that the value could have less digits specified. So good style would actually be to display 20.00+-0.07 and 20.0+-0.2 and I see no issue on the differing absolute precision.

But that might depend on your particular use case, so it would be helpful to know more about that.

[Ants-Aare]

The values I shared are just random examples to reproduce my issues. I have a column in a table showing the values with their uncertainties and I want all of them to have the same amount of digits both for the main value and the uncertainty across all the rows, which I can’t do with the current implementation.
Unless I pass in the result of my confidence interval calculation into a round function. It works perfectly fine this way if I manually round. I do know to which extent I need to round the uncertainties, but I would like to be able to do it using the same tools I use for everything else. It just seems a bit odd that both round: precision:2 and digits: 2 don’t give me what I want. I'll take a look at the mentioned PR though, maybe it solves the problem! Great package by the way!

On another note, do you intend on adding percent as a default unit to zi? or maybe as a display option for num? maybe even so that I don’t have to multiply by 100 and that it automatically displays 0-1 values as 0-100 values. If that's something you'd be open to, I'd be happy to make a PR for it.

[Mc-Zen]

with the new rounding model, digits: 2 applies strictly, giving you almost the desired behavior. However, it does not apply to the uncertainty but only to the value currently. I am open to change this. But be careful: this feature only ever pads or truncates the number without applying proper rounding.

For this reason I feel still this should be solved with rounding. With the new model, #num(round:(follow-uncertainty: false, precision: 2, mode:"places"))[..] is almost what you want: It rounds the value to two places regardless of the uncertainty. The only issue is that the uncertainty will be left unchanged in the current implementation. But I am open to discuss the behavior of this case, an option would also be the following: when follow-uncertainty is set to false and mode is set to "places", value and uncertainty are rounded the same way. This would leave the question open what should happen when the mode is set to "figures".

[Mc-Zen]

On another note, do you intend on adding percent as a default unit to zi? or maybe as a display option for num? maybe even so that I don’t have to multiply by 100 and that it automatically displays 0-1 values as 0-100 values. If that's something you'd be open to, I'd be happy to make a PR for it.

Yes, there could definitely be a unit zi.percent! As a unit, there should be no automatic conversion (i.e. multiplication with 100), because zi.percent[50] directly states 50% as I see it.