Alignment of implication arrows with text on top












5














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}


Compiled



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?










share|improve this question
























  • 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 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
















5














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}


Compiled



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?










share|improve this question
























  • 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 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














5












5








5







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}


Compiled



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?










share|improve this question















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}


Compiled



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






share|improve this question















share|improve this question













share|improve this question




share|improve this question








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 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


















  • 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 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
















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










3 Answers
3






active

oldest

votes


















6














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}


output





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 as DOTSB;Longrightarrow; and ; produces a space that can be stretched (but not shrunk, by default).
    This space will no longer be stretchable if stackrel (or smashstackrel) 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 to smashstackrel and noLstackrel, 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 as mskipthickmuskip and inserts a horizontal space of length thickmuskip, which by default is 5mu but can be stretched to 10mu if necessary. mkern is similar to mskip, but it doesn't allow for stretching. So mkern-thickmuskip removes a horizontal space of 5mu in this case so that we end up with a horizontal space of 0mu that can be stretched to up to 5mu. See this answer for more information on spacing commands.




  • A possible disadvantage ofsmashstackrel compared to stackrel is that it always typesets things in displaystyle.
    I've included a version of smashstackrel[l] that doesn't do this below because I had already written it before I suddenly remembered the existence of smashoperator.



    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}.








share|improve this answer























  • 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








  • 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












  • 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




    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



















1














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}


enter image description here






share|improve this answer

















  • 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



















1














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:



Result



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.






share|improve this answer























  • 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













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
});


}
});














draft saved

draft discarded


















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









6














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}


output





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 as DOTSB;Longrightarrow; and ; produces a space that can be stretched (but not shrunk, by default).
    This space will no longer be stretchable if stackrel (or smashstackrel) 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 to smashstackrel and noLstackrel, 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 as mskipthickmuskip and inserts a horizontal space of length thickmuskip, which by default is 5mu but can be stretched to 10mu if necessary. mkern is similar to mskip, but it doesn't allow for stretching. So mkern-thickmuskip removes a horizontal space of 5mu in this case so that we end up with a horizontal space of 0mu that can be stretched to up to 5mu. See this answer for more information on spacing commands.




  • A possible disadvantage ofsmashstackrel compared to stackrel is that it always typesets things in displaystyle.
    I've included a version of smashstackrel[l] that doesn't do this below because I had already written it before I suddenly remembered the existence of smashoperator.



    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}.








share|improve this answer























  • 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








  • 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












  • 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




    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
















6














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}


output





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 as DOTSB;Longrightarrow; and ; produces a space that can be stretched (but not shrunk, by default).
    This space will no longer be stretchable if stackrel (or smashstackrel) 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 to smashstackrel and noLstackrel, 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 as mskipthickmuskip and inserts a horizontal space of length thickmuskip, which by default is 5mu but can be stretched to 10mu if necessary. mkern is similar to mskip, but it doesn't allow for stretching. So mkern-thickmuskip removes a horizontal space of 5mu in this case so that we end up with a horizontal space of 0mu that can be stretched to up to 5mu. See this answer for more information on spacing commands.




  • A possible disadvantage ofsmashstackrel compared to stackrel is that it always typesets things in displaystyle.
    I've included a version of smashstackrel[l] that doesn't do this below because I had already written it before I suddenly remembered the existence of smashoperator.



    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}.








share|improve this answer























  • 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








  • 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












  • 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




    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














6












6








6






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}


output





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 as DOTSB;Longrightarrow; and ; produces a space that can be stretched (but not shrunk, by default).
    This space will no longer be stretchable if stackrel (or smashstackrel) 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 to smashstackrel and noLstackrel, 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 as mskipthickmuskip and inserts a horizontal space of length thickmuskip, which by default is 5mu but can be stretched to 10mu if necessary. mkern is similar to mskip, but it doesn't allow for stretching. So mkern-thickmuskip removes a horizontal space of 5mu in this case so that we end up with a horizontal space of 0mu that can be stretched to up to 5mu. See this answer for more information on spacing commands.




  • A possible disadvantage ofsmashstackrel compared to stackrel is that it always typesets things in displaystyle.
    I've included a version of smashstackrel[l] that doesn't do this below because I had already written it before I suddenly remembered the existence of smashoperator.



    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}.








share|improve this answer














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}


output





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 as DOTSB;Longrightarrow; and ; produces a space that can be stretched (but not shrunk, by default).
    This space will no longer be stretchable if stackrel (or smashstackrel) 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 to smashstackrel and noLstackrel, 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 as mskipthickmuskip and inserts a horizontal space of length thickmuskip, which by default is 5mu but can be stretched to 10mu if necessary. mkern is similar to mskip, but it doesn't allow for stretching. So mkern-thickmuskip removes a horizontal space of 5mu in this case so that we end up with a horizontal space of 0mu that can be stretched to up to 5mu. See this answer for more information on spacing commands.




  • A possible disadvantage ofsmashstackrel compared to stackrel is that it always typesets things in displaystyle.
    I've included a version of smashstackrel[l] that doesn't do this below because I had already written it before I suddenly remembered the existence of smashoperator.



    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}.









share|improve this answer














share|improve this answer



share|improve this answer








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 redefine implies in a way that it allows implies^{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 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








  • 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












  • 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




    @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








  • 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











1














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}


enter image description here






share|improve this answer

















  • 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
















1














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}


enter image description here






share|improve this answer

















  • 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














1












1








1






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}


enter image description here






share|improve this answer












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}


enter image description here







share|improve this answer












share|improve this answer



share|improve this answer










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














  • 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











1














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:



Result



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.






share|improve this answer























  • 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


















1














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:



Result



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.






share|improve this answer























  • 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
















1












1








1






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:



Result



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.






share|improve this answer














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:



Result



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.







share|improve this answer














share|improve this answer



share|improve this answer








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 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


















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




















draft saved

draft discarded




















































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.




draft saved


draft discarded














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





















































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







Popular posts from this blog

How to change which sound is reproduced for terminal bell?

Title Spacing in Bjornstrup Chapter, Removing Chapter Number From Contents

Can I use Tabulator js library in my java Spring + Thymeleaf project?