josephwright/siunitx

Angle uncertainties are broken for angle-mode=arc and arc format

kmjc opened this issue · 2 comments

kmjc commented

Using \pm with angles that are either input in arc format or need to convert to it seems to be broken.
I have some older tex files which use this syntax, so I believe it used to work.

\documentclass{article}
\usepackage{siunitx}
\begin{document}

\ang[angle-mode = arc]{16.7878 \pm 0.0003}
\ang[angle-mode = decimal]{22;56;33.787 \pm 0.007}

\ang{22;56;33.787 \pm 0.007}


\end{document}

The first two examples throw Use of \??? doens't match its definition and display the wrong number, but the document compiles.
The last line throws siunitx Error: Invalid number '33.787 \pm 0.007' and the document doesn't compile.

I would have expected, for example, 22◦56′33.787(7)′′

So what you are seeing reflects a bug in v2 which you've taken advantage of :)

In v2, something like

\documentclass{article}
\usepackage{siunitx}[=v2]
\begin{document}
\ang{22;56;33.787(7)}
\end{document}

yields an error

! Package siunitx Error: Token '33.787(7)' forbidden in restricted numerical
(siunitx)                input.

For immediate help type H <return>.
 ...                                              
                                                  
l.8 \ang{22;56;33.787(7)}
                       
? h

The current input must be a real number and cannot contain:
 - an exponent;
 - an uncertainty;
 - a complex part.

because I decided that angle syntax would be for 'simple' cases. However, the way I set that up internally is to adapt the parser in a way that I overlooked the x.xx \pm y.yy form of input. So your existing files are set up for v2 taking advantage of this oversight on my part.

In v3, I've used a more careful method to suppress uncertainties in numbers - this does deal with both forms. However, I can see that at least for the seconds part of an arc (and I guess for decimal angles), an uncertainty does make sense. So I will need to address that. I'm putting down as a feature request for the next release as this isn't really a bug in v3 (which is working as expected). My plans are to try to sort v3.4 over the next month or two, as it's been a while since v3.3 and bits and pieces are there to do. I hope this helps.

kmjc commented

Ha, that makes sense :)
Thanks for adding it to the list for 3.4! It's really useful/common in astronomy