Alignment of implication arrows with text on top
My proofs often look like this:
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&stackrel{text{Explanation}}{implies}text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies} text{Fourth Statement}
end{align}
end{document}
And the issue is that the alignment takes into account the entire stackrel, while I want it to algin with the implication arrow.
I tried stackrel{Explanation}{&implies}
but that throws an error.
mathclap works, if the explanation is not too long and doesn't touch the statement after the implication arrow.
Do you have any suggestions how to solve this problem?
formatting align
add a comment |
My proofs often look like this:
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&stackrel{text{Explanation}}{implies}text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies} text{Fourth Statement}
end{align}
end{document}
And the issue is that the alignment takes into account the entire stackrel, while I want it to algin with the implication arrow.
I tried stackrel{Explanation}{&implies}
but that throws an error.
mathclap works, if the explanation is not too long and doesn't touch the statement after the implication arrow.
Do you have any suggestions how to solve this problem?
formatting align
Can you add a full compilable code, please? For example I have not understood your question.
– Sebastiano
Dec 29 '18 at 13:22
@Sebastiano like this?
– Felix B.
Dec 29 '18 at 13:27
Ok :-)Thank you very much.
– Sebastiano
Dec 29 '18 at 13:28
1
i see no reason that using aphantom
won't work. for the first statement, use thephantom
with the whole content of thestackrel
with the longest text. for the second, use thephantom
for just the top element of thestackrel
. some adjustment will be necessary if two "printed" explanations" have different widths. i can't test this now since i don't have tex installed on my laptop.
– barbara beeton
Dec 30 '18 at 0:25
add a comment |
My proofs often look like this:
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&stackrel{text{Explanation}}{implies}text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies} text{Fourth Statement}
end{align}
end{document}
And the issue is that the alignment takes into account the entire stackrel, while I want it to algin with the implication arrow.
I tried stackrel{Explanation}{&implies}
but that throws an error.
mathclap works, if the explanation is not too long and doesn't touch the statement after the implication arrow.
Do you have any suggestions how to solve this problem?
formatting align
My proofs often look like this:
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&stackrel{text{Explanation}}{implies}text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies} text{Fourth Statement}
end{align}
end{document}
And the issue is that the alignment takes into account the entire stackrel, while I want it to algin with the implication arrow.
I tried stackrel{Explanation}{&implies}
but that throws an error.
mathclap works, if the explanation is not too long and doesn't touch the statement after the implication arrow.
Do you have any suggestions how to solve this problem?
formatting align
formatting align
edited Dec 30 '18 at 13:10
asked Dec 29 '18 at 13:17
Felix B.
1458
1458
Can you add a full compilable code, please? For example I have not understood your question.
– Sebastiano
Dec 29 '18 at 13:22
@Sebastiano like this?
– Felix B.
Dec 29 '18 at 13:27
Ok :-)Thank you very much.
– Sebastiano
Dec 29 '18 at 13:28
1
i see no reason that using aphantom
won't work. for the first statement, use thephantom
with the whole content of thestackrel
with the longest text. for the second, use thephantom
for just the top element of thestackrel
. some adjustment will be necessary if two "printed" explanations" have different widths. i can't test this now since i don't have tex installed on my laptop.
– barbara beeton
Dec 30 '18 at 0:25
add a comment |
Can you add a full compilable code, please? For example I have not understood your question.
– Sebastiano
Dec 29 '18 at 13:22
@Sebastiano like this?
– Felix B.
Dec 29 '18 at 13:27
Ok :-)Thank you very much.
– Sebastiano
Dec 29 '18 at 13:28
1
i see no reason that using aphantom
won't work. for the first statement, use thephantom
with the whole content of thestackrel
with the longest text. for the second, use thephantom
for just the top element of thestackrel
. some adjustment will be necessary if two "printed" explanations" have different widths. i can't test this now since i don't have tex installed on my laptop.
– barbara beeton
Dec 30 '18 at 0:25
Can you add a full compilable code, please? For example I have not understood your question.
– Sebastiano
Dec 29 '18 at 13:22
Can you add a full compilable code, please? For example I have not understood your question.
– Sebastiano
Dec 29 '18 at 13:22
@Sebastiano like this?
– Felix B.
Dec 29 '18 at 13:27
@Sebastiano like this?
– Felix B.
Dec 29 '18 at 13:27
Ok :-)Thank you very much.
– Sebastiano
Dec 29 '18 at 13:28
Ok :-)Thank you very much.
– Sebastiano
Dec 29 '18 at 13:28
1
1
i see no reason that using a
phantom
won't work. for the first statement, use the phantom
with the whole content of the stackrel
with the longest text. for the second, use the phantom
for just the top element of the stackrel
. some adjustment will be necessary if two "printed" explanations" have different widths. i can't test this now since i don't have tex installed on my laptop.– barbara beeton
Dec 30 '18 at 0:25
i see no reason that using a
phantom
won't work. for the first statement, use the phantom
with the whole content of the stackrel
with the longest text. for the second, use the phantom
for just the top element of the stackrel
. some adjustment will be necessary if two "printed" explanations" have different widths. i can't test this now since i don't have tex installed on my laptop.– barbara beeton
Dec 30 '18 at 0:25
add a comment |
3 Answers
3
active
oldest
votes
The stackrel
command is defined as
#1#2 → mathrel{mathop{#2}limits^{#1}}
so you could use smashoperator
from the mathtools
package to get rid of the space introduced by the left half of the superscript.
I'm defining smashstackrel
below, a version of stackrel
that incorporates smashoperator
. I think smashstackrel[l]
does precisely what you want.
I also defined feliximplies{<text>}
to make life simpler.
documentclass{article}
usepackage{mathtools}
newcommand*smashstackrel[3][lr]{%
mathrel{smashoperator[#1]{mathop{#3}^{#2}}}
}
newcommand*feliximplies[1]{smashstackrel[l]{textnormal{#1}}{implies}}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&smashstackrel[l]{text{Explanation}}{implies}text{Third Statement}\
&feliximplies{Explanation} text{Fourth Statement}
end{align}
end{document}
Notes:
The optional argument of
smashstackrel
can be either[l]
,[r]
or[lr]
depending on whether you want to ignore the left side or the right side or both sides of the superscript for spacing purposes.
implies
is defined asDOTSB;Longrightarrow;
and;
produces a space that can be stretched (but not shrunk, by default).
This space will no longer be stretchable ifstackrel
(orsmashstackrel
) is used, so doing so feels slightly dubious.
I think something like
;mkern-thickmuskipstackrel{<text>}{implies};mkern-thickmuskip
might be more appropriate than just
stackrel{<text>}{implies}
. This reinserts precisely the amount of stretchability that was lost. (The same remark applies tosmashstackrel
andnoLstackrel
, which is defined below.)
In this case it doesn't matter though, since here the space won't be stretched anyway. It would matter if this command were used inline rather than in a display environment.
Brief explanation:
;
is defined asmskipthickmuskip
and inserts a horizontal space of lengththickmuskip
, which by default is5mu
but can be stretched to10mu
if necessary.mkern
is similar tomskip
, but it doesn't allow for stretching. Somkern-thickmuskip
removes a horizontal space of5mu
in this case so that we end up with a horizontal space of0mu
that can be stretched to up to5mu
. See this answer for more information on spacing commands.
A possible disadvantage of
smashstackrel
compared tostackrel
is that it always typesets things indisplaystyle
.
I've included a version ofsmashstackrel[l]
that doesn't do this below because I had already written it before I suddenly remembered the existence ofsmashoperator
.
makeatletter %% <- make @ usable in command names
newcommand*noLstackrel[2]{mathpalettenoLstackrel@{{#1}{#2}}}
newcommand*noLstackrel@[2]{noLstackrel@@{#1}#2}
newcommand*noLstackrel@@[3]{% #1 = displaystyle etc., #2 = top, #3 = bottom
begingroup %% <- limit scope of boxes
sbox0{$m@th#1stackrel{#2}{#3}$}% %% <- put stackrel construction in box 0
sbox2{$m@th#1#3$}% %% <- put base symbol in box 2
hskip.5wd2 hskip-.5wd0 %% <- remove excess width on the left
mathrel{usebox0}% %% <- print box 0
endgroup
}
makeatother %% <- revert @
Usage:
noLstackrel{<stuff on top>}{implies}
.
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefineimplies
in a way that it allowsimplies^{Explanation}
?
– Felix B.
Dec 30 '18 at 11:23
1
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you wantimplies
to still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Becausemathop{Longrightarrow}
does neither of these things, you would have to use something like@ifnextchar
to look ahead for an explicit^
.
– Circumscribe
Dec 30 '18 at 11:55
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in()
than[]
but I don't understand the solution) Wouldn't usinglimits
like in the originalstackrel
solve this problem?
– Felix B.
Dec 30 '18 at 11:58
1
I've added a brief explanation to second remark. It only really matters for inline ($…$
) equations though, since I don't think spaces in display environments are really ever stretched.
– Circumscribe
Dec 30 '18 at 12:18
|
show 2 more comments
You could try eqnarray
begin{eqnarray}
&& text{First Statement}\
&implies& text{Second Statement}\
&stackrel{text{Explanation}}{implies}&text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies}& text{Fourth Statement}
end{eqnarray}
2
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
add a comment |
Reading the documentation on mathtools after learning about smashoperators
from Circumscribes answer, I found another possible solution: xRightarrow
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{Statement}\
&implies text{implies arrow}\
&xRightarrow{text{Explanation}}text{xRightarrow}\
&xRightarrow{(*)} text{xRightarrow}\
&;xRightarrow{(*)}; text{xRightarrow with ;}\
&implies text{implies arrow}\
&;xRightarrow{}; text{xRightarrow with ;}\
&;Rightarrow; text{Rightarrow with ;}
end{align}
end{document}
Resulting in:
The advantage of this solution is, that it utilizes a command from a known package, which probably has less errors than a home cooked solution. And it allows for underscript too.
The disadvantage is probably clear from the picture. implies
inserts a space before the arrow, which xRightarrow
does not do.
(EDIT: this can be fixed with ;
at the sides as Circumscribes points out but it is still noticeable that xRightarrow is based on Rightarrow, as you can see from the default length when there is no input)
So instead of implies
you would probably have to use Rightarrow
instead. Secondly I am not sure if I visually prefer different length arrows over explanations which overflow the width of the usual implies
arrow.
Seems like a good solution. To make the spacing match that ofimplies
you should use;xRightarrow{…};
, sinceimplies
is effectively the same thing as;Longrightarrow;
.
– Circumscribe
Dec 30 '18 at 14:15
add a comment |
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%2f467779%2falignment-of-implication-arrows-with-text-on-top%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
The stackrel
command is defined as
#1#2 → mathrel{mathop{#2}limits^{#1}}
so you could use smashoperator
from the mathtools
package to get rid of the space introduced by the left half of the superscript.
I'm defining smashstackrel
below, a version of stackrel
that incorporates smashoperator
. I think smashstackrel[l]
does precisely what you want.
I also defined feliximplies{<text>}
to make life simpler.
documentclass{article}
usepackage{mathtools}
newcommand*smashstackrel[3][lr]{%
mathrel{smashoperator[#1]{mathop{#3}^{#2}}}
}
newcommand*feliximplies[1]{smashstackrel[l]{textnormal{#1}}{implies}}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&smashstackrel[l]{text{Explanation}}{implies}text{Third Statement}\
&feliximplies{Explanation} text{Fourth Statement}
end{align}
end{document}
Notes:
The optional argument of
smashstackrel
can be either[l]
,[r]
or[lr]
depending on whether you want to ignore the left side or the right side or both sides of the superscript for spacing purposes.
implies
is defined asDOTSB;Longrightarrow;
and;
produces a space that can be stretched (but not shrunk, by default).
This space will no longer be stretchable ifstackrel
(orsmashstackrel
) is used, so doing so feels slightly dubious.
I think something like
;mkern-thickmuskipstackrel{<text>}{implies};mkern-thickmuskip
might be more appropriate than just
stackrel{<text>}{implies}
. This reinserts precisely the amount of stretchability that was lost. (The same remark applies tosmashstackrel
andnoLstackrel
, which is defined below.)
In this case it doesn't matter though, since here the space won't be stretched anyway. It would matter if this command were used inline rather than in a display environment.
Brief explanation:
;
is defined asmskipthickmuskip
and inserts a horizontal space of lengththickmuskip
, which by default is5mu
but can be stretched to10mu
if necessary.mkern
is similar tomskip
, but it doesn't allow for stretching. Somkern-thickmuskip
removes a horizontal space of5mu
in this case so that we end up with a horizontal space of0mu
that can be stretched to up to5mu
. See this answer for more information on spacing commands.
A possible disadvantage of
smashstackrel
compared tostackrel
is that it always typesets things indisplaystyle
.
I've included a version ofsmashstackrel[l]
that doesn't do this below because I had already written it before I suddenly remembered the existence ofsmashoperator
.
makeatletter %% <- make @ usable in command names
newcommand*noLstackrel[2]{mathpalettenoLstackrel@{{#1}{#2}}}
newcommand*noLstackrel@[2]{noLstackrel@@{#1}#2}
newcommand*noLstackrel@@[3]{% #1 = displaystyle etc., #2 = top, #3 = bottom
begingroup %% <- limit scope of boxes
sbox0{$m@th#1stackrel{#2}{#3}$}% %% <- put stackrel construction in box 0
sbox2{$m@th#1#3$}% %% <- put base symbol in box 2
hskip.5wd2 hskip-.5wd0 %% <- remove excess width on the left
mathrel{usebox0}% %% <- print box 0
endgroup
}
makeatother %% <- revert @
Usage:
noLstackrel{<stuff on top>}{implies}
.
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefineimplies
in a way that it allowsimplies^{Explanation}
?
– Felix B.
Dec 30 '18 at 11:23
1
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you wantimplies
to still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Becausemathop{Longrightarrow}
does neither of these things, you would have to use something like@ifnextchar
to look ahead for an explicit^
.
– Circumscribe
Dec 30 '18 at 11:55
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in()
than[]
but I don't understand the solution) Wouldn't usinglimits
like in the originalstackrel
solve this problem?
– Felix B.
Dec 30 '18 at 11:58
1
I've added a brief explanation to second remark. It only really matters for inline ($…$
) equations though, since I don't think spaces in display environments are really ever stretched.
– Circumscribe
Dec 30 '18 at 12:18
|
show 2 more comments
The stackrel
command is defined as
#1#2 → mathrel{mathop{#2}limits^{#1}}
so you could use smashoperator
from the mathtools
package to get rid of the space introduced by the left half of the superscript.
I'm defining smashstackrel
below, a version of stackrel
that incorporates smashoperator
. I think smashstackrel[l]
does precisely what you want.
I also defined feliximplies{<text>}
to make life simpler.
documentclass{article}
usepackage{mathtools}
newcommand*smashstackrel[3][lr]{%
mathrel{smashoperator[#1]{mathop{#3}^{#2}}}
}
newcommand*feliximplies[1]{smashstackrel[l]{textnormal{#1}}{implies}}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&smashstackrel[l]{text{Explanation}}{implies}text{Third Statement}\
&feliximplies{Explanation} text{Fourth Statement}
end{align}
end{document}
Notes:
The optional argument of
smashstackrel
can be either[l]
,[r]
or[lr]
depending on whether you want to ignore the left side or the right side or both sides of the superscript for spacing purposes.
implies
is defined asDOTSB;Longrightarrow;
and;
produces a space that can be stretched (but not shrunk, by default).
This space will no longer be stretchable ifstackrel
(orsmashstackrel
) is used, so doing so feels slightly dubious.
I think something like
;mkern-thickmuskipstackrel{<text>}{implies};mkern-thickmuskip
might be more appropriate than just
stackrel{<text>}{implies}
. This reinserts precisely the amount of stretchability that was lost. (The same remark applies tosmashstackrel
andnoLstackrel
, which is defined below.)
In this case it doesn't matter though, since here the space won't be stretched anyway. It would matter if this command were used inline rather than in a display environment.
Brief explanation:
;
is defined asmskipthickmuskip
and inserts a horizontal space of lengththickmuskip
, which by default is5mu
but can be stretched to10mu
if necessary.mkern
is similar tomskip
, but it doesn't allow for stretching. Somkern-thickmuskip
removes a horizontal space of5mu
in this case so that we end up with a horizontal space of0mu
that can be stretched to up to5mu
. See this answer for more information on spacing commands.
A possible disadvantage of
smashstackrel
compared tostackrel
is that it always typesets things indisplaystyle
.
I've included a version ofsmashstackrel[l]
that doesn't do this below because I had already written it before I suddenly remembered the existence ofsmashoperator
.
makeatletter %% <- make @ usable in command names
newcommand*noLstackrel[2]{mathpalettenoLstackrel@{{#1}{#2}}}
newcommand*noLstackrel@[2]{noLstackrel@@{#1}#2}
newcommand*noLstackrel@@[3]{% #1 = displaystyle etc., #2 = top, #3 = bottom
begingroup %% <- limit scope of boxes
sbox0{$m@th#1stackrel{#2}{#3}$}% %% <- put stackrel construction in box 0
sbox2{$m@th#1#3$}% %% <- put base symbol in box 2
hskip.5wd2 hskip-.5wd0 %% <- remove excess width on the left
mathrel{usebox0}% %% <- print box 0
endgroup
}
makeatother %% <- revert @
Usage:
noLstackrel{<stuff on top>}{implies}
.
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefineimplies
in a way that it allowsimplies^{Explanation}
?
– Felix B.
Dec 30 '18 at 11:23
1
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you wantimplies
to still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Becausemathop{Longrightarrow}
does neither of these things, you would have to use something like@ifnextchar
to look ahead for an explicit^
.
– Circumscribe
Dec 30 '18 at 11:55
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in()
than[]
but I don't understand the solution) Wouldn't usinglimits
like in the originalstackrel
solve this problem?
– Felix B.
Dec 30 '18 at 11:58
1
I've added a brief explanation to second remark. It only really matters for inline ($…$
) equations though, since I don't think spaces in display environments are really ever stretched.
– Circumscribe
Dec 30 '18 at 12:18
|
show 2 more comments
The stackrel
command is defined as
#1#2 → mathrel{mathop{#2}limits^{#1}}
so you could use smashoperator
from the mathtools
package to get rid of the space introduced by the left half of the superscript.
I'm defining smashstackrel
below, a version of stackrel
that incorporates smashoperator
. I think smashstackrel[l]
does precisely what you want.
I also defined feliximplies{<text>}
to make life simpler.
documentclass{article}
usepackage{mathtools}
newcommand*smashstackrel[3][lr]{%
mathrel{smashoperator[#1]{mathop{#3}^{#2}}}
}
newcommand*feliximplies[1]{smashstackrel[l]{textnormal{#1}}{implies}}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&smashstackrel[l]{text{Explanation}}{implies}text{Third Statement}\
&feliximplies{Explanation} text{Fourth Statement}
end{align}
end{document}
Notes:
The optional argument of
smashstackrel
can be either[l]
,[r]
or[lr]
depending on whether you want to ignore the left side or the right side or both sides of the superscript for spacing purposes.
implies
is defined asDOTSB;Longrightarrow;
and;
produces a space that can be stretched (but not shrunk, by default).
This space will no longer be stretchable ifstackrel
(orsmashstackrel
) is used, so doing so feels slightly dubious.
I think something like
;mkern-thickmuskipstackrel{<text>}{implies};mkern-thickmuskip
might be more appropriate than just
stackrel{<text>}{implies}
. This reinserts precisely the amount of stretchability that was lost. (The same remark applies tosmashstackrel
andnoLstackrel
, which is defined below.)
In this case it doesn't matter though, since here the space won't be stretched anyway. It would matter if this command were used inline rather than in a display environment.
Brief explanation:
;
is defined asmskipthickmuskip
and inserts a horizontal space of lengththickmuskip
, which by default is5mu
but can be stretched to10mu
if necessary.mkern
is similar tomskip
, but it doesn't allow for stretching. Somkern-thickmuskip
removes a horizontal space of5mu
in this case so that we end up with a horizontal space of0mu
that can be stretched to up to5mu
. See this answer for more information on spacing commands.
A possible disadvantage of
smashstackrel
compared tostackrel
is that it always typesets things indisplaystyle
.
I've included a version ofsmashstackrel[l]
that doesn't do this below because I had already written it before I suddenly remembered the existence ofsmashoperator
.
makeatletter %% <- make @ usable in command names
newcommand*noLstackrel[2]{mathpalettenoLstackrel@{{#1}{#2}}}
newcommand*noLstackrel@[2]{noLstackrel@@{#1}#2}
newcommand*noLstackrel@@[3]{% #1 = displaystyle etc., #2 = top, #3 = bottom
begingroup %% <- limit scope of boxes
sbox0{$m@th#1stackrel{#2}{#3}$}% %% <- put stackrel construction in box 0
sbox2{$m@th#1#3$}% %% <- put base symbol in box 2
hskip.5wd2 hskip-.5wd0 %% <- remove excess width on the left
mathrel{usebox0}% %% <- print box 0
endgroup
}
makeatother %% <- revert @
Usage:
noLstackrel{<stuff on top>}{implies}
.
The stackrel
command is defined as
#1#2 → mathrel{mathop{#2}limits^{#1}}
so you could use smashoperator
from the mathtools
package to get rid of the space introduced by the left half of the superscript.
I'm defining smashstackrel
below, a version of stackrel
that incorporates smashoperator
. I think smashstackrel[l]
does precisely what you want.
I also defined feliximplies{<text>}
to make life simpler.
documentclass{article}
usepackage{mathtools}
newcommand*smashstackrel[3][lr]{%
mathrel{smashoperator[#1]{mathop{#3}^{#2}}}
}
newcommand*feliximplies[1]{smashstackrel[l]{textnormal{#1}}{implies}}
begin{document}
begin{align}
&text{First Statement}\
&implies text{Second Statement}\
&smashstackrel[l]{text{Explanation}}{implies}text{Third Statement}\
&feliximplies{Explanation} text{Fourth Statement}
end{align}
end{document}
Notes:
The optional argument of
smashstackrel
can be either[l]
,[r]
or[lr]
depending on whether you want to ignore the left side or the right side or both sides of the superscript for spacing purposes.
implies
is defined asDOTSB;Longrightarrow;
and;
produces a space that can be stretched (but not shrunk, by default).
This space will no longer be stretchable ifstackrel
(orsmashstackrel
) is used, so doing so feels slightly dubious.
I think something like
;mkern-thickmuskipstackrel{<text>}{implies};mkern-thickmuskip
might be more appropriate than just
stackrel{<text>}{implies}
. This reinserts precisely the amount of stretchability that was lost. (The same remark applies tosmashstackrel
andnoLstackrel
, which is defined below.)
In this case it doesn't matter though, since here the space won't be stretched anyway. It would matter if this command were used inline rather than in a display environment.
Brief explanation:
;
is defined asmskipthickmuskip
and inserts a horizontal space of lengththickmuskip
, which by default is5mu
but can be stretched to10mu
if necessary.mkern
is similar tomskip
, but it doesn't allow for stretching. Somkern-thickmuskip
removes a horizontal space of5mu
in this case so that we end up with a horizontal space of0mu
that can be stretched to up to5mu
. See this answer for more information on spacing commands.
A possible disadvantage of
smashstackrel
compared tostackrel
is that it always typesets things indisplaystyle
.
I've included a version ofsmashstackrel[l]
that doesn't do this below because I had already written it before I suddenly remembered the existence ofsmashoperator
.
makeatletter %% <- make @ usable in command names
newcommand*noLstackrel[2]{mathpalettenoLstackrel@{{#1}{#2}}}
newcommand*noLstackrel@[2]{noLstackrel@@{#1}#2}
newcommand*noLstackrel@@[3]{% #1 = displaystyle etc., #2 = top, #3 = bottom
begingroup %% <- limit scope of boxes
sbox0{$m@th#1stackrel{#2}{#3}$}% %% <- put stackrel construction in box 0
sbox2{$m@th#1#3$}% %% <- put base symbol in box 2
hskip.5wd2 hskip-.5wd0 %% <- remove excess width on the left
mathrel{usebox0}% %% <- print box 0
endgroup
}
makeatother %% <- revert @
Usage:
noLstackrel{<stuff on top>}{implies}
.
edited Dec 30 '18 at 12:34
answered Dec 30 '18 at 1:23
Circumscribe
4,8011533
4,8011533
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefineimplies
in a way that it allowsimplies^{Explanation}
?
– Felix B.
Dec 30 '18 at 11:23
1
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you wantimplies
to still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Becausemathop{Longrightarrow}
does neither of these things, you would have to use something like@ifnextchar
to look ahead for an explicit^
.
– Circumscribe
Dec 30 '18 at 11:55
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in()
than[]
but I don't understand the solution) Wouldn't usinglimits
like in the originalstackrel
solve this problem?
– Felix B.
Dec 30 '18 at 11:58
1
I've added a brief explanation to second remark. It only really matters for inline ($…$
) equations though, since I don't think spaces in display environments are really ever stretched.
– Circumscribe
Dec 30 '18 at 12:18
|
show 2 more comments
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefineimplies
in a way that it allowsimplies^{Explanation}
?
– Felix B.
Dec 30 '18 at 11:23
1
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you wantimplies
to still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Becausemathop{Longrightarrow}
does neither of these things, you would have to use something like@ifnextchar
to look ahead for an explicit^
.
– Circumscribe
Dec 30 '18 at 11:55
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in()
than[]
but I don't understand the solution) Wouldn't usinglimits
like in the originalstackrel
solve this problem?
– Felix B.
Dec 30 '18 at 11:58
1
I've added a brief explanation to second remark. It only really matters for inline ($…$
) equations though, since I don't think spaces in display environments are really ever stretched.
– Circumscribe
Dec 30 '18 at 12:18
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
Excellent your work and the same of @caverac.
– Sebastiano
Dec 30 '18 at 10:16
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefine
implies
in a way that it allows implies^{Explanation}
?– Felix B.
Dec 30 '18 at 11:23
The second note is a bit hard to read because you only define the command you refer to, in the third note. Probably because you have rewritten the answer? Otherwise excellent answer. Do you think it would be a good idea to redefine
implies
in a way that it allows implies^{Explanation}
?– Felix B.
Dec 30 '18 at 11:23
1
1
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you want
implies
to still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Because mathop{Longrightarrow}
does neither of these things, you would have to use something like @ifnextchar
to look ahead for an explicit ^
.– Circumscribe
Dec 30 '18 at 11:55
@FelixB. Oops, that is indeed what happened. What you suggest sounds like a neat idea, but it seems like it'd be a bit finicky to implement if you want
implies
to still be treated as a relation (rather than an operator) for spacing purposes and even more so if you want the left side to be "smashed" as above. Because mathop{Longrightarrow}
does neither of these things, you would have to use something like @ifnextchar
to look ahead for an explicit ^
.– Circumscribe
Dec 30 '18 at 11:55
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in
()
than []
but I don't understand the solution) Wouldn't using limits
like in the original stackrel
solve this problem?– Felix B.
Dec 30 '18 at 11:58
If you say it might be finicky I probably better leave my hands off of it. Still trying to wrap my head around what all the commands in the second note do. And I haven't really understood the third comment (I think I know that the problem is that it treats sums limits different in
()
than []
but I don't understand the solution) Wouldn't using limits
like in the original stackrel
solve this problem?– Felix B.
Dec 30 '18 at 11:58
1
1
I've added a brief explanation to second remark. It only really matters for inline (
$…$
) equations though, since I don't think spaces in display environments are really ever stretched.– Circumscribe
Dec 30 '18 at 12:18
I've added a brief explanation to second remark. It only really matters for inline (
$…$
) equations though, since I don't think spaces in display environments are really ever stretched.– Circumscribe
Dec 30 '18 at 12:18
|
show 2 more comments
You could try eqnarray
begin{eqnarray}
&& text{First Statement}\
&implies& text{Second Statement}\
&stackrel{text{Explanation}}{implies}&text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies}& text{Fourth Statement}
end{eqnarray}
2
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
add a comment |
You could try eqnarray
begin{eqnarray}
&& text{First Statement}\
&implies& text{Second Statement}\
&stackrel{text{Explanation}}{implies}&text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies}& text{Fourth Statement}
end{eqnarray}
2
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
add a comment |
You could try eqnarray
begin{eqnarray}
&& text{First Statement}\
&implies& text{Second Statement}\
&stackrel{text{Explanation}}{implies}&text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies}& text{Fourth Statement}
end{eqnarray}
You could try eqnarray
begin{eqnarray}
&& text{First Statement}\
&implies& text{Second Statement}\
&stackrel{text{Explanation}}{implies}&text{Third Statement}\
&stackrel{mathclap{text{Explanation}}}{implies}& text{Fourth Statement}
end{eqnarray}
answered Dec 29 '18 at 13:41
caverac
5,9281624
5,9281624
2
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
add a comment |
2
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
2
2
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
tex.stackexchange.com/questions/196/eqnarray-vs-align judging from the most popular answer that might not be the best idea?
– Felix B.
Dec 29 '18 at 13:46
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
@FelixB. You are absolutely right! I will leave it here until someone else gives you a better solution
– caverac
Dec 29 '18 at 14:03
add a comment |
Reading the documentation on mathtools after learning about smashoperators
from Circumscribes answer, I found another possible solution: xRightarrow
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{Statement}\
&implies text{implies arrow}\
&xRightarrow{text{Explanation}}text{xRightarrow}\
&xRightarrow{(*)} text{xRightarrow}\
&;xRightarrow{(*)}; text{xRightarrow with ;}\
&implies text{implies arrow}\
&;xRightarrow{}; text{xRightarrow with ;}\
&;Rightarrow; text{Rightarrow with ;}
end{align}
end{document}
Resulting in:
The advantage of this solution is, that it utilizes a command from a known package, which probably has less errors than a home cooked solution. And it allows for underscript too.
The disadvantage is probably clear from the picture. implies
inserts a space before the arrow, which xRightarrow
does not do.
(EDIT: this can be fixed with ;
at the sides as Circumscribes points out but it is still noticeable that xRightarrow is based on Rightarrow, as you can see from the default length when there is no input)
So instead of implies
you would probably have to use Rightarrow
instead. Secondly I am not sure if I visually prefer different length arrows over explanations which overflow the width of the usual implies
arrow.
Seems like a good solution. To make the spacing match that ofimplies
you should use;xRightarrow{…};
, sinceimplies
is effectively the same thing as;Longrightarrow;
.
– Circumscribe
Dec 30 '18 at 14:15
add a comment |
Reading the documentation on mathtools after learning about smashoperators
from Circumscribes answer, I found another possible solution: xRightarrow
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{Statement}\
&implies text{implies arrow}\
&xRightarrow{text{Explanation}}text{xRightarrow}\
&xRightarrow{(*)} text{xRightarrow}\
&;xRightarrow{(*)}; text{xRightarrow with ;}\
&implies text{implies arrow}\
&;xRightarrow{}; text{xRightarrow with ;}\
&;Rightarrow; text{Rightarrow with ;}
end{align}
end{document}
Resulting in:
The advantage of this solution is, that it utilizes a command from a known package, which probably has less errors than a home cooked solution. And it allows for underscript too.
The disadvantage is probably clear from the picture. implies
inserts a space before the arrow, which xRightarrow
does not do.
(EDIT: this can be fixed with ;
at the sides as Circumscribes points out but it is still noticeable that xRightarrow is based on Rightarrow, as you can see from the default length when there is no input)
So instead of implies
you would probably have to use Rightarrow
instead. Secondly I am not sure if I visually prefer different length arrows over explanations which overflow the width of the usual implies
arrow.
Seems like a good solution. To make the spacing match that ofimplies
you should use;xRightarrow{…};
, sinceimplies
is effectively the same thing as;Longrightarrow;
.
– Circumscribe
Dec 30 '18 at 14:15
add a comment |
Reading the documentation on mathtools after learning about smashoperators
from Circumscribes answer, I found another possible solution: xRightarrow
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{Statement}\
&implies text{implies arrow}\
&xRightarrow{text{Explanation}}text{xRightarrow}\
&xRightarrow{(*)} text{xRightarrow}\
&;xRightarrow{(*)}; text{xRightarrow with ;}\
&implies text{implies arrow}\
&;xRightarrow{}; text{xRightarrow with ;}\
&;Rightarrow; text{Rightarrow with ;}
end{align}
end{document}
Resulting in:
The advantage of this solution is, that it utilizes a command from a known package, which probably has less errors than a home cooked solution. And it allows for underscript too.
The disadvantage is probably clear from the picture. implies
inserts a space before the arrow, which xRightarrow
does not do.
(EDIT: this can be fixed with ;
at the sides as Circumscribes points out but it is still noticeable that xRightarrow is based on Rightarrow, as you can see from the default length when there is no input)
So instead of implies
you would probably have to use Rightarrow
instead. Secondly I am not sure if I visually prefer different length arrows over explanations which overflow the width of the usual implies
arrow.
Reading the documentation on mathtools after learning about smashoperators
from Circumscribes answer, I found another possible solution: xRightarrow
documentclass{article}
usepackage{mathtools}
begin{document}
begin{align}
&text{Statement}\
&implies text{implies arrow}\
&xRightarrow{text{Explanation}}text{xRightarrow}\
&xRightarrow{(*)} text{xRightarrow}\
&;xRightarrow{(*)}; text{xRightarrow with ;}\
&implies text{implies arrow}\
&;xRightarrow{}; text{xRightarrow with ;}\
&;Rightarrow; text{Rightarrow with ;}
end{align}
end{document}
Resulting in:
The advantage of this solution is, that it utilizes a command from a known package, which probably has less errors than a home cooked solution. And it allows for underscript too.
The disadvantage is probably clear from the picture. implies
inserts a space before the arrow, which xRightarrow
does not do.
(EDIT: this can be fixed with ;
at the sides as Circumscribes points out but it is still noticeable that xRightarrow is based on Rightarrow, as you can see from the default length when there is no input)
So instead of implies
you would probably have to use Rightarrow
instead. Secondly I am not sure if I visually prefer different length arrows over explanations which overflow the width of the usual implies
arrow.
edited Dec 30 '18 at 14:30
answered Dec 30 '18 at 14:07
Felix B.
1458
1458
Seems like a good solution. To make the spacing match that ofimplies
you should use;xRightarrow{…};
, sinceimplies
is effectively the same thing as;Longrightarrow;
.
– Circumscribe
Dec 30 '18 at 14:15
add a comment |
Seems like a good solution. To make the spacing match that ofimplies
you should use;xRightarrow{…};
, sinceimplies
is effectively the same thing as;Longrightarrow;
.
– Circumscribe
Dec 30 '18 at 14:15
Seems like a good solution. To make the spacing match that of
implies
you should use ;xRightarrow{…};
, since implies
is effectively the same thing as ;Longrightarrow;
.– Circumscribe
Dec 30 '18 at 14:15
Seems like a good solution. To make the spacing match that of
implies
you should use ;xRightarrow{…};
, since implies
is effectively the same thing as ;Longrightarrow;
.– Circumscribe
Dec 30 '18 at 14:15
add a comment |
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%2f467779%2falignment-of-implication-arrows-with-text-on-top%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
Can you add a full compilable code, please? For example I have not understood your question.
– Sebastiano
Dec 29 '18 at 13:22
@Sebastiano like this?
– Felix B.
Dec 29 '18 at 13:27
Ok :-)Thank you very much.
– Sebastiano
Dec 29 '18 at 13:28
1
i see no reason that using a
phantom
won't work. for the first statement, use thephantom
with the whole content of thestackrel
with the longest text. for the second, use thephantom
for just the top element of thestackrel
. some adjustment will be necessary if two "printed" explanations" have different widths. i can't test this now since i don't have tex installed on my laptop.– barbara beeton
Dec 30 '18 at 0:25