Support asymmetry uncertainties/tolerances
Spun out from #24 as the core multipart idea is now stable and it is only the asymmetrical aspect that needs addressing.
Current thinking on the interface is 123.4(+5:-6), but there is an open question as to whether one can 'read in' the signs, e.g. 123.4(5:6)?
Usually I prefer things to be set explicitly, yet, in this particular case I've used to read/say the number in order (+, then -) and I guess this should be ok for most of the people. So the signs may be omitted.
OK, current thinking is
- New option
input-asymmetrical-uncertainty-signstaking two brace groups, one positive, one negative; most likely users will stick with a defaultnput-asymmetrical-uncertainty-signs = {+}{-} - New option
input-uncertainty-dividerwhich will be the suggested:as standard
These two will let me cover the 'compact' input form, but I am still wondering about the 'long' form: I am wondering whether to go with just 'compact' for v3.3 and see what extensions make sense for v3.4: thoughts?
I think that having the short form will be amazing by itself and propose not to wait for the long form.
As for the long form, I do not know what it actually means. In case it means multiple groups of asymmetric uncertainties, the thing is used much more rare, at least in my field. Thus, again, I do not think you need to wait to provide both the features in the same version.
@maxfl The 'long' form here would be 1.23 + 0.04 - 0.06 or similar, comparable to 1.23 \pm 0.4
OK, I have basic support checked in: at the moment, only one input and one output format. I have a feeling this will need some refinement, but I will look at other issues and hope I get some feedback here!
Given this is an area I'm less confident about, I'm going to go with what I have now for v3.3 and push any refinements to v3,4.
OK, I have basic support checked in: at the moment, only one input and one output format. I have a feeling this will need some refinement, but I will look at other issues and hope I get some feedback here!
thank you a lot! I will check.
I've checked the new features and they are amazing. Thanks a lot! Having a long format (+x-y) would be nice, but the current one seem to fulfill all the needs.
The only issue I've found is that using uncertainty descriptors in a subscript mode together with multipart uncertainties produces the $x_1_2$-like code and issues an error due to the double subscript. Perhaps, the protection should be added.
as a side note, it took me a while to figure out how to compile the code and produce the sty file. Maybe a few lines may be added to the README.md on this. I've also noticed the build.lua file, but have no idea on whether it may help compiling the package and which particular application could do it.
as a side note, it took me a while to figure out how to compile the code and produce the
styfile. Maybe a few lines may be added to theREADME.mdon this. I've also noticed thebuild.luafile, but have no idea on whether it may help compiling the package and which particular application could do it.
Very few users install themselves: almost everyone gets the package from their TeX system. For those that don't, there's a TDS-style zip on CTAN. And for those who want to extract, the classical instructions for DocStrip ('run tex siunitx.ins) work. I tend to assume the latter group know what they are doing :)
Thanks for adding this really nice new feature! Asymmetric uncertainties are formatted perfectly using the compact input form with ansiunitx macro, but it doesn't seem to be possible to use this form without a macro in the S column of a table. As a minimal example, the following:
\documentclass[a4paper]{article}
\usepackage[separate-uncertainty]{siunitx}
\begin{document}
\begin{table}
\begin{tabular}{S[table-format=2.2(1)]}
\num{20.01(2:3)} \\ % Asymmetric uncertainties with macro okay.
20.01(2) \\ % Symmetric uncertainties without macro okay.
30.01(2:3) \\ % This line gives an error.
\end{tabular}
\end{table}
\end{document}
generates the error message:
! Package siunitx Error: Invalid number '30.01(2'
Do I have something wrong in the syntax, or is parsing of the compact form for asymmetric uncertainties not yet enabled?
Thanks!
@kh296 Please log a separate issue
OK, I'm going to close here as done - if there are more specific issues or requirements, please open a new issue.