767

I've heard that you should use \[ ... \] for displayed equations instead of $$ ... $$, but why is that?

I'd assumed that it's so that you can more easily tell which are starting and which are ending delimiters, but if I always use a syntax-highlighting text editor, I can see that easily based on the color of the symbols.

Is there any reason for this suggestion?

12

8 Answers 8

480

$$ is TeX primitive syntax, which, as others have commented is hard to redefine (in classic TeX there is no command name which triggers entering or leaving display math).

LaTeX doesn't officially support $$. The most noticeable failure if you use the syntax is that the fleqn option will no longer affect the display of the mathematics, it will remain centered rather than being set flush left.

However if you are using \[ it is best to use the amsmath package (it is best to load this package if doing any serious mathematical layout with LaTeX).

\[ is a short form of \begin{displaymath} which one might expect to act like an un-numbered form of \begin{equation}. The amsmath package redefines \[ to be \begin{equation*} which is exactly an un-numbered form of the equation environment as defined by that package. In the core LaTeX definition \[ has the definition

  \ifvmode
     \nointerlineskip
     \makebox[.6\linewidth]{}%
  \fi
  $$

which means that the spacing if used between paragraphs is better that a primitive $$ (which causes a blank paragraph just consisting of the indentation and parfillskip glue to be inserted before the display) but it is inconsistent with equation and always uses \abovedisplayskip rather than \abovedisplayshortskip. In the AMS versions the spacing is more consistent,

8
  • 6
    Out of curiosity, what is the effect of the \makebox?
    – zwol
    Commented Feb 12, 2013 at 23:46
  • 15
    well as indicated it's an attempt to improve the behaviour if the equation starts a paragraph, $$ would force a blank line aligned on baselineskip but with just with just an indentation box and parfillskip glue then have the display skip, that forces the paragraph tp start with a zero height line which reduces the vertical space. Commented Feb 13, 2013 at 9:06
  • 4
    @GennaroArguzzi no they are not equivalent and unlike single $ , the syntax $$ is not supported in latex at all. Commented Aug 16, 2018 at 11:32
  • 5
    is there a way to summarize your answer into a concise clear reason? Is it just "$ $ is not latex"? If it's not then why have I been able to compile latex just fine for 10 years on any editor on my computer to overleaf etc.? I can't extract the main point from your answer, can you help me? thanks for your time! Commented Jan 24, 2021 at 19:45
  • 3
    @CharlieParker tex is a macro expansion language so there is no compilation or code hiding, all lower level constructs are necessarily available and so can be used. But the fact that they do not give errors does not mean that they should be used. If you use documented latex math constructs they will be centred or flush left depending on whether you use the fleqn option. $$ is always centred: the official latex documentation does not need to mention that fleqn does not work with $$ because $$ is not mentioned at all. Commented Jan 24, 2021 at 21:06
202

Spacing is wrong.

It is a "deadly sin" according to l2tabu, section 1.6 on page 6: http://www.ctan.org/tex-archive/info/l2tabu/english/

12
  • 29
    should be "required reading" Commented Jul 29, 2010 at 0:24
  • 190
    Although the link is good, I find the answer a bit disappointing: What is wrong with the spacing? This explanation is also missing in l2tabu. Commented Nov 2, 2010 at 15:24
  • 16
    @Jasper: Well, you quoted everything l2tabu has to offer on the subject. And yes, it does say that something is wrong with the spacing of $$, but it doesn't say what is wrong. That's what I actually meant in my comment above. Anyway, thanks for clarifying this! Commented Apr 24, 2011 at 12:32
  • 12
    @Jasper: My question above was not a rethorical one; I honestly don't know and really would like to know the answer, too. Commented Apr 27, 2011 at 11:02
  • 60
    Amusingly, l2tabuen.pdf suggests to use $\uppi$ rather than \(\uppi\) on page 14. So $$...$$ is “please don't do this” and a “deadly sin”, because of spacing in some cases (I have not seen a single one to date) and its TeX nature, while $...$ is perfectly correct? Oh, please. Yes, the use of fleqn and some other arguments are understandable and I do use LaTeX commands, but the issue has gone too far without a good argumentation which the one in l2tabuen.pdf is certainly not. Commented Aug 11, 2011 at 18:35
177

Here is one more reason (this is what converted me). If you use the \begin{proof}...\end{proof} environment, you occasionally end a proof with an equation. The automatic QED box then ends up on a line by itself, which is ugly. You can fix this by writing \qedhere at the end of the equation, but this doesn't work properly with $$...$$ – you have to use \[...\] (or an environment, like equation/gather/align). To exemplify:

Don't:

\begin{proof}
  This follows from
  $$e^{x+y}=e^xe^y. \qedhere$$
\end{proof}

Do:

\begin{proof}
  This follows from
  \[e^{x+y}=e^xe^y. \qedhere\]
\end{proof}
4
  • But when you use \begin{proof}, you dont need to put \quedhere, it is automatic and is displayed at the end of the line like your second example. Anyway, i'm going to start using \[ \] Commented May 16, 2015 at 14:55
  • 19
    @LuisFelipe Have you tried it? Without \qedhere, the box ends up on the line after the equation. It's more noticeable with a longer equation, but it happens in this case as well.
    – Teepeemm
    Commented Aug 25, 2016 at 22:10
  • The ''problem'' with $$ can be easily solved adding \hspace{} to both sides of the equation. I am still not converted.
    – luchonacho
    Commented Oct 15, 2020 at 19:09
  • 7
    @luchonacho --- But why go to the trouble? Why not just use the supported syntax? Commented Jul 3, 2021 at 10:35
51

$$ is plain TeX and could have some side effects, also fleqn will not work anymore. Please have a look at l2tabu. In my opinion the best environment for equations is gather or align. If you use equation you sometimes get some strange spacings.

2
  • 7
    eqnarray gives strange spacing and is deprecated in favour of alignequation, on the other hand, should be fine … Commented Jul 28, 2010 at 19:08
  • 7
    The reason fleqn doesn't work with $$...$$ is because it redefines \] to run some code at the end. Commented Jul 28, 2010 at 21:37
40

It is not always preferable to use \[..\]!

The source2e.pdf file contains the documented source of LaTeX2e. Therein, one sees that \[..\] is essentially a wrapper for $$ .. $$ checking if the construct is used when already in math mode (which is then an error).

Produces $$...$$ with checks that \[ isn’t used in math mode, and that \] is only used in math mode begun with \].

There seems to be a typo there \[ was meant. Besides, the sentence should not be taken to mean that

\[ a^n + b^n= c^n $$
$$ a^n + b^n= c^n \]

create errors, they don't, only things like \( a^n + b^n= c^n \] or $a^n + b^n= c^n \] do.

However the detailed source code shows that it contains something which will interfere in some cases with correct vertical spacing:

170 \def\[{%
171 \relax\ifmmode
172 \@badmath
173 \else
174 \ifvmode
175 \nointerlineskip
176 \makebox[.6\linewidth]{}%
177 \fi
178 $$%%$$ BRACE MATCH HACK
179 \fi
180 }
181 \def\]{%
182 \relax\ifmmode
183 \ifinner
184 \@badmath
185 \else
186 $$%%$$ BRACE MATCH HACK
187 \fi
188 \else
189 \@badmath
190 \fi
191 \ignorespaces
192 }

The \makebox[.6\linewidth]{} which is executed when the display is opened in vertical mode has the effect of disabling the TeX use of \abovedisplayshortskip (hence of \belowdisplayshortskip). The problem is that immediately after \[..\] TeX is in horizontal mode (not vertical) hence if two or more equations are typeset using \[..\] without anything in-between, the second and next ones will use the short skips. This leads to incoherent vertical spacing:

\documentclass{article}
\begin{document}

The rules are smashed so take no vertical space, and are only there to
illustrate the issue (extra vertical space only between the first and the second
equation and not between the next ones).

Using \verb|\[..\]|: 

\[
\vartheta=2\pi\smash{\rule{.4pt}{4ex}}  
\]
\[
\vartheta=2\pi\smash{\rule{.4pt}{4ex}}  
\]
\[
\vartheta=2\pi\smash{\rule{.4pt}{4ex}}  
\]

Using \verb|$$..$$|:

$$
  \vartheta=2\pi\smash{\rule{.4pt}{4ex}}
$$
$$
  \vartheta=2\pi\smash{\rule{.4pt}{4ex}}  
$$
$$
  \vartheta=2\pi\smash{\rule{.4pt}{4ex}}  
$$

There is no issue if we use \verb|\[..\]| but start within a paragraph:\newline
\[
\vartheta=2\pi\smash{\rule{.4pt}{4ex}}  
\]
\[
\vartheta=2\pi\smash{\rule{.4pt}{4ex}}  
\]
\[
\vartheta=2\pi\smash{\rule{.4pt}{4ex}}  
\]
The issue arises only if the chain of \verb|\[..\]| is initiated in vertical
mode. The issue never arises when using the original \verb|$$..$$| input syntax.

\end{document}

bad vertical spacing with displaymath

6
  • 15
    amsmath \[ doesn't suffer from this bug.
    – giordano
    Commented Mar 2, 2014 at 11:19
  • 25
    It's wrong using two \[...\] constructions in a row to begin with. So this answer doesn't add anything, I'm afraid.
    – egreg
    Commented Mar 2, 2014 at 11:21
  • 25
    @egreg you mean that being better informed adds nothing? your comment is opinionated, so let me explicitely write for the record that I definitely do not share this opinion of yours.
    – user4686
    Commented Mar 2, 2014 at 13:36
  • 6
    @jfbu Sorry to hear that. My opinion stems from 20+ years of experience with LaTeX and I have no problem in stating it again and again. Fixing a bug introducing worse bugs is surely not a recommendable remedy.
    – egreg
    Commented Mar 2, 2014 at 13:47
  • 13
    @egreg to clear up potential misunderstanding I meant to say I was in disagreement with your opinion about my answer not adding anything, not with your strong recommendation not to use multiple \[..\] in a row. Most of the time I am with align of amsmath. But this has its own problems too.
    – user4686
    Commented Mar 2, 2014 at 14:13
29

[Edit: I should add the disclaimer that the following is based on just "I read it somewhere sometime ago", so I have no references to backup my claims.]

As far as I know $$ ... $$ is a TeX, amsTeX thing. LaTeX still supports it for one reason or another, but the "proper" one to use, as defined in the specifications, is \[ ... \]. All this just means that they are not promising that $$ will always work. So it is technically possible (though unlikely in the near future), that compatibility with $$ is removed from LaTeX and lots of your documents break.

As to why one is in the specifications and not the other? I have no idea.

4
  • 10
    Given that TeX goes into display math mode by the occurrence of two identical characters with catcode 3, LaTeX would have to go through some contortions to prevent $$ ... $$ from working, especially if $ ... $ was still to work. I guess you could give some other character catcode 3, make $ active, define it using \@ifnextchar to look for another $ and give an error message, otherwise use the new math shift character to go into or out of math mode and of course after the definition of $, make the other character have its original catcode...but that doesn't seem worth it.
    – TH.
    Commented Aug 28, 2010 at 12:21
  • 2
    LuaTeX have primitives for entering/exiting inline and display math modes (as well as sub/superscript), so making it possible to assign $ a normal catcode. Commented Aug 28, 2010 at 23:24
  • 2
    @TH: So that's why $$ still sorta works in LaTeX. I've been wondering why they couldn't disable it, and I seem to have misplaced my TeXbook.
    – SamB
    Commented Oct 4, 2010 at 18:40
  • 4
    A workaround could be setting the default math typeface (appearing with $$) to a big red blinking all-caps font saying "you shouldn't use this", and then setting \[...\] to change this mess back to something normal. Would this work? I am no TeX guru, so I do not know for sure. Commented Sep 2, 2012 at 21:12
24
  1. While my memory prevents me from naming the guilty software, I have seen LaTeX syntax highlighting become confused by the $$ ... $$ construct when it parsed the \[ ... \] construct correctly.

  2. Agreed, worry about some partially broken editor isn't a high priority. But, I have found that I am more than partially broken. If I've made a mess of a file, the left-hand and right-hand information in the \[ way has, on occasion, helped me figure out just what I was on about more easily than the symmetric $$ would have.

1
  • 6
    While this is certainly true enough, it's not the real reason. The real reason is that \[ ... \], which are macros, do some extra things (sometimes) that $$ ... $$, which are baked in to TeX, cannot be made to do.
    – SamB
    Commented Oct 4, 2010 at 18:50
17

I suppose it could be useful if you share your files with someone else who doesn't have a syntax-highlighting text editor. Other than that, it probably doesn't matter much. Certainly if nobody else ever sees your LaTeX source files, I'd say write them however you want.

This is neither here nor there, but personally I find neither of those as clear as \begin{equation}...\end{equation}.

5
  • 7
    You meant equation*, didn't you? =p Commented Jul 28, 2010 at 18:36
  • 3
    Sure, whatever variant it takes to get the effect I want.
    – David Z
    Commented Jul 28, 2010 at 18:37
  • I understand why (so they can post a bunch of LaTeX code without it rendering), but it seems ironic they don't implement MathJax. Also MathJax doesn't recognize [ ]. And neither does any other Markdown style edit box, eg. Moodle or Canvas learning management systems.
    – Bill N
    Commented Mar 21, 2020 at 13:29
  • Also, your answer prompted me to try using \begin{align} \end{align} in Mathjax. It works, but you have to use \newline instead of \\ for the next equation.
    – Bill N
    Commented Mar 21, 2020 at 13:54
  • If you bring up MathJax, KaTeX, markdown etc.: (1) MathJax delimiters are easy to customize (2) NONE of the arguments here about TeX builtin $$ vs. LaTeX redefining \[ apply! Those are independently written parsers, and when they recognize both syntaxes, they treat them exactly the same. Math-in-MarkDown syntaxes vary by tool, and may have other limitations (e.g. pandoc has heuristics to no treat prices like $10 in normal prose as math). Commented Jul 18 at 14:20

You must log in to answer this question.

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