# Further questions about mathrm and operatorname: spacing after \colon

EDIT: As clarified in the answers below, this appears to be a bug with amsmath and colon and thus doesn't really have anything to do with mathrm versus operatorname.

This question contains an enlightening discussion between using \mathrm and \operatorname. The tl;dr version is: whenever you have an operator, use \operatorname.

However it seems bad to use \operatorname if what you are defining is a set, since in general \operatorname adds a little space before it. This means that an expression like:

f \colon \operatorname{End}(V) \to \mathbb{R}


renders badly, as there is too much white space between the colon and the operatorname{End}. Using \mathrm (the RHS) is more visually appealing:

Thus if one views \operatorname{End}(V) as a set, then it makes more sense to write \mathrm{End}(V).

Now one can view \operatorname{End} also a functor on the category of vector spaces, for instance, then you would want the \operatorname:

My question is this: What is the best practice when dealing with a quantity that is used both as a set and an operator? Should one really switch between \mathrm and \operatorname as appropriate? Or is there a better option.

• IMHO, this looks like a bug in the (re)definition of \colon made by the amsmath package. Edit: Oh, by the way, welcome to TeX.SX! (:-) – GuM Nov 24 '18 at 10:55
• Please say exactly which packages you are using. With just amsopn there is no difference in the output – Andrew Swann Nov 24 '18 at 10:57
• See github.com/latex3/latex2e/issues/91 for discussion of the bug. – egreg Nov 24 '18 at 13:44

That's a very interesting observation.

The definition of \colon in amsmath is

\renewcommand{\colon}{
\nobreak
\mskip 2mu
\mathpunct{}
\nonscript
\mkern-\thinmuskip
{:}
\mskip 6mu plus 1mu\relax
}


(edited to show the various parts). The space you see is a consequence of the fact that \colon ends with an ordinary atom, namely {:}.

It would have been better to use \mathopen, as the following test shows. I first get an alias of \colon and patch it to change {:} into \mathopen:.

\documentclass{article}
\usepackage{amsmath}
\usepackage{etoolbox}

\let\pcolon\colon
\patchcmd{\pcolon}{{:}}{\mathopen:}{}{}

\begin{document}

$f \colon \operatorname{End}(V) \to R$

$f \pcolon \operatorname{End}(V) \to R$

\bigskip

\begin{tabular}{@{}*{8}{l}@{}}
&0&1&2&3&4&5&6 \\
\verb|\colon| &
$\colon A$ &
$\colon \max$ &
$\colon +$ &
$\colon \sim$ &
$\colon ($ &
$\colon )$ &
$\colon ,$
\\
\verb|\pcolon| &
$\pcolon A$ &
$\pcolon \max$ &
$\pcolon +$ &
$\pcolon \sim$ &
$\pcolon ($ &
$\pcolon )$ &
$\pcolon ,$
\end{tabular}

\end{document}


In the tests, \colon is followed by a symbol in each class.

The only noticeable differences are in the cases when \colon is followed by atoms of class 1 (operators) and 3 (relations), performing perhaps better in both.

If you want to follow this suggestion, your document can load etoolbox and do

\patchcmd{\colon}{{:}}{\mathopen:}{}{}


I don't think that it's possible to fix amsmath as many existing documents depend on it and such a change would affect the output and line breaks. It might be possible to add an option for using a fixed definition.

• Exactly what I meant! (+1) But why not replace : with \mathpunct: and compensate for the excess space in the final \mskip? – GuM Nov 24 '18 at 11:13
• @GuM That could be another idea. I wanted to do minimal changes. – egreg Nov 24 '18 at 11:14
• @GuM The original definition has \mathpunct{}\nonscript-\thinmuskip, which adds \thinmuskip in scriptstyle/scriptscriptstyle. Using \mathpunct: would need more computations. – egreg Nov 24 '18 at 11:22
• Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, using \mathpunct:\nonscript\mskip-\thinmuskip as the replacement code, which is what I was suggesting, amounts to having “(0)” glue after the colon, irrespective of the kind of atom that follows; which is precisely what \mathopen: does! (:-) – GuM Nov 24 '18 at 11:37
• any ideas on whether we should do that (and option names if we do)? perhaps best as a gh issue so any change can point to that discussion/ – David Carlisle Nov 24 '18 at 12:23