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.
math-operators
add a comment |
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.
math-operators
2
IMHO, this looks like a bug in the (re)definition ofcolon
made by theamsmath
package. Edit: Oh, by the way, welcome to TeX.SX! (:-)
– GuM
Nov 24 at 10:55
Please say exactly which packages you are using. With justamsopn
there is no difference in the output
– Andrew Swann
Nov 24 at 10:57
2
See github.com/latex3/latex2e/issues/91 for discussion of the bug.
– egreg
Nov 24 at 13:44
add a comment |
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.
math-operators
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.
math-operators
math-operators
edited Nov 24 at 14:44
asked Nov 24 at 10:22
Howard
735
735
2
IMHO, this looks like a bug in the (re)definition ofcolon
made by theamsmath
package. Edit: Oh, by the way, welcome to TeX.SX! (:-)
– GuM
Nov 24 at 10:55
Please say exactly which packages you are using. With justamsopn
there is no difference in the output
– Andrew Swann
Nov 24 at 10:57
2
See github.com/latex3/latex2e/issues/91 for discussion of the bug.
– egreg
Nov 24 at 13:44
add a comment |
2
IMHO, this looks like a bug in the (re)definition ofcolon
made by theamsmath
package. Edit: Oh, by the way, welcome to TeX.SX! (:-)
– GuM
Nov 24 at 10:55
Please say exactly which packages you are using. With justamsopn
there is no difference in the output
– Andrew Swann
Nov 24 at 10:57
2
See github.com/latex3/latex2e/issues/91 for discussion of the bug.
– egreg
Nov 24 at 13:44
2
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 at 10:55
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 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 at 10:57
Please say exactly which packages you are using. With just
amsopn
there is no difference in the output– Andrew Swann
Nov 24 at 10:57
2
2
See github.com/latex3/latex2e/issues/91 for discussion of the bug.
– egreg
Nov 24 at 13:44
See github.com/latex3/latex2e/issues/91 for discussion of the bug.
– egreg
Nov 24 at 13:44
add a comment |
1 Answer
1
active
oldest
votes
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 1murelax
}
(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}
letpcoloncolon
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:
withmathpunct:
and compensate for the excess space in the finalmskip
?
– GuM
Nov 24 at 11:13
@GuM That could be another idea. I wanted to do minimal changes.
– egreg
Nov 24 at 11:14
@GuM The original definition hasmathpunct{}nonscript-thinmuskip
, which addsthinmuskip
in scriptstyle/scriptscriptstyle. Usingmathpunct:
would need more computations.
– egreg
Nov 24 at 11:22
Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, usingmathpunct:nonscriptmskip-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 whatmathopen:
does! (:-)
– GuM
Nov 24 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 at 12:23
|
show 3 more comments
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "85"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f461537%2ffurther-questions-about-mathrm-and-operatorname-spacing-after-colon%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
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 1murelax
}
(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}
letpcoloncolon
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:
withmathpunct:
and compensate for the excess space in the finalmskip
?
– GuM
Nov 24 at 11:13
@GuM That could be another idea. I wanted to do minimal changes.
– egreg
Nov 24 at 11:14
@GuM The original definition hasmathpunct{}nonscript-thinmuskip
, which addsthinmuskip
in scriptstyle/scriptscriptstyle. Usingmathpunct:
would need more computations.
– egreg
Nov 24 at 11:22
Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, usingmathpunct:nonscriptmskip-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 whatmathopen:
does! (:-)
– GuM
Nov 24 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 at 12:23
|
show 3 more comments
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 1murelax
}
(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}
letpcoloncolon
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:
withmathpunct:
and compensate for the excess space in the finalmskip
?
– GuM
Nov 24 at 11:13
@GuM That could be another idea. I wanted to do minimal changes.
– egreg
Nov 24 at 11:14
@GuM The original definition hasmathpunct{}nonscript-thinmuskip
, which addsthinmuskip
in scriptstyle/scriptscriptstyle. Usingmathpunct:
would need more computations.
– egreg
Nov 24 at 11:22
Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, usingmathpunct:nonscriptmskip-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 whatmathopen:
does! (:-)
– GuM
Nov 24 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 at 12:23
|
show 3 more comments
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 1murelax
}
(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}
letpcoloncolon
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.
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 1murelax
}
(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}
letpcoloncolon
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.
edited Nov 24 at 11:11
answered Nov 24 at 11:05
egreg
708k8618813163
708k8618813163
Exactly what I meant! (+1) But why not replace:
withmathpunct:
and compensate for the excess space in the finalmskip
?
– GuM
Nov 24 at 11:13
@GuM That could be another idea. I wanted to do minimal changes.
– egreg
Nov 24 at 11:14
@GuM The original definition hasmathpunct{}nonscript-thinmuskip
, which addsthinmuskip
in scriptstyle/scriptscriptstyle. Usingmathpunct:
would need more computations.
– egreg
Nov 24 at 11:22
Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, usingmathpunct:nonscriptmskip-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 whatmathopen:
does! (:-)
– GuM
Nov 24 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 at 12:23
|
show 3 more comments
Exactly what I meant! (+1) But why not replace:
withmathpunct:
and compensate for the excess space in the finalmskip
?
– GuM
Nov 24 at 11:13
@GuM That could be another idea. I wanted to do minimal changes.
– egreg
Nov 24 at 11:14
@GuM The original definition hasmathpunct{}nonscript-thinmuskip
, which addsthinmuskip
in scriptstyle/scriptscriptstyle. Usingmathpunct:
would need more computations.
– egreg
Nov 24 at 11:22
Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, usingmathpunct:nonscriptmskip-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 whatmathopen:
does! (:-)
– GuM
Nov 24 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 at 12:23
Exactly what I meant! (+1) But why not replace
:
with mathpunct:
and compensate for the excess space in the final mskip
?– GuM
Nov 24 at 11:13
Exactly what I meant! (+1) But why not replace
:
with mathpunct:
and compensate for the excess space in the final mskip
?– GuM
Nov 24 at 11:13
@GuM That could be another idea. I wanted to do minimal changes.
– egreg
Nov 24 at 11:14
@GuM That could be another idea. I wanted to do minimal changes.
– egreg
Nov 24 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 at 11:22
@GuM The original definition has
mathpunct{}nonscript-thinmuskip
, which adds thinmuskip
in scriptstyle/scriptscriptstyle. Using mathpunct:
would need more computations.– egreg
Nov 24 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:nonscriptmskip-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 at 11:37
Forget about my comment: looking at the table on p. 170, a Punct atom is always followed by “(1)” glue; so, using
mathpunct:nonscriptmskip-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 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 at 12:23
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 at 12:23
|
show 3 more comments
Thanks for contributing an answer to TeX - LaTeX Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2ftex.stackexchange.com%2fquestions%2f461537%2ffurther-questions-about-mathrm-and-operatorname-spacing-after-colon%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
IMHO, this looks like a bug in the (re)definition of
colon
made by theamsmath
package. Edit: Oh, by the way, welcome to TeX.SX! (:-)– GuM
Nov 24 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 at 10:57
2
See github.com/latex3/latex2e/issues/91 for discussion of the bug.
– egreg
Nov 24 at 13:44