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: operatorname vs mathrm

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: End as a functor

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.

  • 2
    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, 2018 at 10:55
  • Please say exactly which packages you are using. With just amsopn there is no difference in the output Nov 24, 2018 at 10:57
  • 2
    See github.com/latex3/latex2e/issues/91 for discussion of the bug.
    – egreg
    Nov 24, 2018 at 13:44

1 Answer 1


That's a very interesting observation.

The definition of \colon in amsmath is

  \mskip 2mu
  \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:.




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

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


&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 ,$


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

enter image description here

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


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, 2018 at 11:13
  • @GuM That could be another idea. I wanted to do minimal changes.
    – egreg
    Nov 24, 2018 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, 2018 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, 2018 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/ Nov 24, 2018 at 12:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .