14

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 '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
  • 2
    See github.com/latex3/latex2e/issues/91 for discussion of the bug. – egreg Nov 24 '18 at 13:44
13

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.

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

\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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.