<p>I agree with the arguments for shorter variable names on the math.se question, but I disagree that "the pros of shorter names seem to apply more to TCS than those of longer names".</p>

<p>In particular, I don't think the best argument there (which follows) applies here.</p>

<blockquote>
  <p>I think one reason is that often one does not want to remember what the variable names really represent.</p>
</blockquote>

<p>This argument works when the definition is generic, like "n is a number", but not when the definition is quite specific, like "BPP is the class of languages for which there exists a probabilistic Turing machine that runs in polynomial time and outputs 1 with probability greater than 2/3 for all inputs in the language and outputs 1 with probability less than 1/3 for all inputs not in the language".</p>

<p>Sure, if I am dealing with a situation where I DO want to forget the complexity class, then I will use a single letter variable name, like using $\mathcal{C}^L$ to define the relativization of $\mathcal{C}$ with oracle language $L$.  But as long as you are working with BPP specifically, I think that it is helpful that the name reminds you that you are working with Polynomial-time Probabilistic (Turing) machines with Bounded error (as opposed to the class of languages that without Bounded error, PP, and the class of languages that is also not based on Probabilistic Turing machines, P).</p>

<p>When we use BPP, we really do want to remember what the variable represents. If this were not the case, then I would not expect <em>everyone</em> to use BPP to denote the above class of languages.</p>

CC BY-SA 3.0
2013-10-12T14:07:55.630Z
2013-10-12T14:07:55.630Z
Tyson Williams
<p>Because we're computer scientists as well as mathematicians, and from the computer science side of the world we've learned the same thing the software engineers have learned about why not to use single-letter names for things other than the most local of variables: longer and more semantically meaningful names are easier to remember and keep straight, easier for others to read and understand, and using them helps avoid certain common errors such as using $k$ to mean three different things in overlapping parts of a paper.</p>

<p>(Actually, I suspect that for the specific case you had in mind, names of complexity classes, this reason is historically inaccurate. But I still believe it's a good reason for using longer names.)</p>

CC BY-SA 3.0
2013-10-13T08:28:40.290Z
"We learned it from programming" is just the answer that I was going to give!  But I further agree that complexity classes are a different case than "ordinary" variable names.  Indeed I'd add that, when facing somewhat analogous tasks as naming complexity classes -- such as naming Lie groups (SU, SO, PSL...) or categories (Int, Set...) -- even the pure mathematicians resort to multiple-letter names as well.
Scott Aaronson
CC BY-SA 3.0
2013-10-13T12:20:22.903Z
My original idea was that while long and descriptive names help software engineers that write large, complex programs, they might not be as useful for theoreticians, whose target is somewhat different from that of engineers.
Pteromys
CC BY-SA 3.0
2013-10-13T06:20:02.123Z
2013-10-13T06:20:02.123Z
David Eppstein
<p>I'm not sure I agree with your premise. I think in most papers, you will find short variable names: some of my personal favorites are $n$, $m$, $i$, $k$, $\epsilon$, and $\alpha$, each quite concise! Now when writing a typeset textbook, one has the luxury to use variable names that make their meaning more apparent to a first-time reader. This is especially true when writing pseudo-code: here, you can borrow from the programming convention of making variable names readable and meaningful, rather than concise. </p>

CC BY-SA 3.0
2013-10-12T13:55:50.597Z
Aaron, I see you like $\epsilon$ but not $\delta$ :)
Sasho Nikolov
CC BY-SA 3.0
2013-10-12T13:59:30.630Z
$\delta$ sucks!
Aaron Roth
CC BY-SA 3.0
2013-10-12T14:09:04.620Z
I much prefer $\varepsilon$ to $\epsilon$.
Tyson Williams
CC BY-SA 3.0
2013-10-12T15:32:14.823Z
By looking at the prevalence of `\eps` in text abstracts, I conclude that `\newcommand{\eps}{\varepsilon}` is quite common.
András Salamon
CC BY-SA 3.0
2013-10-12T13:15:55.540Z
2013-10-12T13:15:55.540Z
Aaron Roth
<p>This is a "dual" question of <a href="https://math.stackexchange.com/questions/24241/why-do-mathematicians-use-single-letter-variables">a popular post on math.se</a>.</p>

<p>Some mathematical objects in computational complexity theory have multiple-letter names.   Complexity classes such as $\mathbf{BPP}$ have an established multiple-letter name.  So do some computational problems, although the naming convension seems to vary.</p>

<p>I am happy with names such as $\mathbf{BPP}$; however, when I write $\mathbf{PromiseBPP}$ on paper or blackboard over and over, I wish its name were more concise (in fact, some authors prefer to write it as $\mathbf{prBPP}$).<br>
In a popular textbook in complexity, a polynomial that appears in the chapter on algebraic complexity of the book is named as $\mathtt{EXACTLY-ONCE}$, which I do not think is a suitable name to write by hand.</p>

<p>Considering the arguments in the original post on math.se, the pros of shorter names seem to apply more to TCS than those of longer names.  After all, what theoreticians do is to work on paper and blackboards, not to write large and complex software with editors that do auto-completion.</p>

<p>Some early literature takes different approach to names.  In Cinderella Book, computational problems have concise names such as $L_{\mathrm h}$ (which stands for the Hamiltonian path problem).</p>

<p>Thus the question is: why do theoreticians in CS use multiple-letter variables?  Or do we have to give long names to objects we are working on?</p>

CC BY-SA 3.0
2013-10-12T15:32:17.703Z
You seem to be conflating *local variables* and *global names*, but I think these are very different. Maths and CS both have "long" *names* (e.g. "topology", , "Hamiltonian path problem", "Hausdorff space", "Borel sigma-algebra", "BPP", "solvable groups"). But I am not sure I agree that CS tends to use long *variables* (can you provide an example?). I think it's common in CS to say "Let $G$ be a graph", "Let $M$ be a polytime algorithm", "Let $X$ be the expected number of samples". So I think single-letter variables are common.
usul
CC BY-SA 3.0
2013-10-12T15:48:28.127Z
I agree with usul. Mathematicians also use long names for global variables, e.g. standard functions $\sin x$, $\cos x$, $\log x$, $\dim V$, $\mathrm{rank}\, M$, $\mathrm{Var}[X]$, $\mathrm{ord}(a)$ etc or standard categories $\mathrm{Set}$, $\mathrm{Top}$, $\mathrm{Met}$, $\mathrm{Grp}$ etc.
Yury
CC BY-SA 3.0
2013-10-13T02:56:03.180Z
I say "variables", because the original question on math.se is formulated as such. They are not necessarily meant to be local.  By "names", I mean symbols assigned to mathematical entities such as sets, numbers and functions.  I feel no problem with long technical terms such as "Hamiltonian path problem", or moderately long global names such as $\mathbf{BPP}$.  My question is about verbose global names such as $\mathbf{PromiseBPP}$ and long *local* names such as $\mathtt{EXACTLY-ONCE}$, which I think is local because it is referred in the text only once.
Pteromys
CC BY-SA 3.0
2013-10-13T19:43:46.890Z
the original question and most of its answers actually talk about variables though, things that *vary*. and your examples are names of fixed objects. as to this Exactly-Once polynomial, you answered your own question: when something is named once (the irony!) in the text, why not name it descriptively, it's not like you'd have to write it over and over as a part of complicated computations.
Sasho Nikolov
CC BY-SA 3.0
2013-10-14T11:02:39.823Z
My thought about $\mathtt{EXACTLY-ONCE}$ was that if it is so unimportant an object that it is referred only once, it doesn't have to have a descriptive name.  As you've said, it is not a cumbersome name, though.
Pteromys
CC BY-SA 3.0
2013-10-15T19:29:26.690Z
@Pteromys on the contrary, in industry, I often see my peers use extremely descriptive variable names such as c and i. Debugging their code, therefore, can lead to madness.
Jonathan E. Landrum
<cc.complexity-theory><soft-question><big-picture><notation>
Why do theoreticians in CS use multiple-letter variables?
Pteromys
# Why do theoreticians in CS use multiple-letter variables?

(Asked by: username_0 on 2013-10-12)

This is a "dual" question of [a popular post on math.se](https://math.stackexchange.com/questions/24241/why-do-mathematicians-use-single-letter-variables).

Some mathematical objects in computational complexity theory have multiple-letter names. Complexity classes such as $\mathbf{BPP}$ have an established multiple-letter name. So do some computational problems, although the naming convension seems to vary.

I am happy with names such as $\mathbf{BPP}$; however, when I write $\mathbf{PromiseBPP}$ on paper or blackboard over and over, I wish its name were more concise (in fact, some authors prefer to write it as $\mathbf{prBPP}$).  
In a popular textbook in complexity, a polynomial that appears in the chapter on algebraic complexity of the book is named as $\mathtt{EXACTLY-ONCE}$, which I do not think is a suitable name to write by hand.

Considering the arguments in the original post on math.se, the pros of shorter names seem to apply more to TCS than those of longer names. After all, what theoreticians do is to work on paper and blackboards, not to write large and complex software with editors that do auto-completion.

Some early literature takes different approach to names. In Cinderella Book, computational problems have concise names such as $L\_{\mathrm h}$ (which stands for the Hamiltonian path problem).

Thus the question is: why do theoreticians in CS use multiple-letter variables? Or do we have to give long names to objects we are working on?

**Tags:** cc.complexity-theory, soft-question, big-picture, notation

> **Comments:**
> **username_1**: You seem to be conflating *local variables* and *global names*, but I think these are very different. Maths and CS both have "long" *names* (e.g. "topology", , "Hamiltonian path problem", "Hausdorff space", "Borel sigma-algebra", "BPP", "solvable groups"). But I am not sure I agree that CS tends to use long *variables* (can you provide an example?). I think it's common in CS to say "Let $G$ be a graph", "Let $M$ be a polytime algorithm", "Let $X$ be the expected number of samples". So I think single-letter variables are common.  
> **username_2**: I agree with username_1. Mathematicians also use long names for global variables, e.g. standard functions $\sin x$, $\cos x$, $\log x$, $\dim V$, $\mathrm{rank}\, M$, $\mathrm{Var}[X]$, $\mathrm{ord}(a)$ etc or standard categories $\mathrm{Set}$, $\mathrm{Top}$, $\mathrm{Met}$, $\mathrm{Grp}$ etc.  
> **username_0**: I say "variables", because the original question on math.se is formulated as such. They are not necessarily meant to be local.  By "names", I mean symbols assigned to mathematical entities such as sets, numbers and functions.  I feel no problem with long technical terms such as "Hamiltonian path problem", or moderately long global names such as $\mathbf{BPP}$.  My question is about verbose global names such as $\mathbf{PromiseBPP}$ and long *local* names such as $\mathtt{EXACTLY-ONCE}$, which I think is local because it is referred in the text only once.  
> **username_3**: the original question and most of its answers actually talk about variables though, things that *vary*. and your examples are names of fixed objects. as to this Exactly-Once polynomial, you answered your own question: when something is named once (the irony!) in the text, why not name it descriptively, it's not like you'd have to write it over and over as a part of complicated computations.  
> **username_0**: My thought about $\mathtt{EXACTLY-ONCE}$ was that if it is so unimportant an object that it is referred only once, it doesn't have to have a descriptive name.  As you've said, it is not a cumbersome name, though.  
> **username_4**: @username_0 on the contrary, in industry, I often see my peers use extremely descriptive variable names such as c and i. Debugging their code, therefore, can lead to madness.  

---

## 3 answers

### Answer by username_5 on 2013-10-12. Score: 5 | Accepted answer

I agree with the arguments for shorter variable names on the math.se question, but I disagree that "the pros of shorter names seem to apply more to TCS than those of longer names".

In particular, I don't think the best argument there (which follows) applies here.

> I think one reason is that often one does not want to remember what the variable names really represent.

This argument works when the definition is generic, like "n is a number", but not when the definition is quite specific, like "BPP is the class of languages for which there exists a probabilistic Turing machine that runs in polynomial time and outputs 1 with probability greater than 2/3 for all inputs in the language and outputs 1 with probability less than 1/3 for all inputs not in the language".

Sure, if I am dealing with a situation where I DO want to forget the complexity class, then I will use a single letter variable name, like using $\mathcal{C}^L$ to define the relativization of $\mathcal{C}$ with oracle language $L$. But as long as you are working with BPP specifically, I think that it is helpful that the name reminds you that you are working with Polynomial-time Probabilistic (Turing) machines with Bounded error (as opposed to the class of languages that without Bounded error, PP, and the class of languages that is also not based on Probabilistic Turing machines, P).

When we use BPP, we really do want to remember what the variable represents. If this were not the case, then I would not expect *everyone* to use BPP to denote the above class of languages.


---

### Answer by username_6 on 2013-10-13. Score: 7

Because we're computer scientists as well as mathematicians, and from the computer science side of the world we've learned the same thing the software engineers have learned about why not to use single-letter names for things other than the most local of variables: longer and more semantically meaningful names are easier to remember and keep straight, easier for others to read and understand, and using them helps avoid certain common errors such as using $k$ to mean three different things in overlapping parts of a paper.

(Actually, I suspect that for the specific case you had in mind, names of complexity classes, this reason is historically inaccurate. But I still believe it's a good reason for using longer names.)

> **Comments:**
> **username_7**: "We learned it from programming" is just the answer that I was going to give!  But I further agree that complexity classes are a different case than "ordinary" variable names.  Indeed I'd add that, when facing somewhat analogous tasks as naming complexity classes -- such as naming Lie groups (SU, SO, PSL...) or categories (Int, Set...) -- even the pure mathematicians resort to multiple-letter names as well.  
> **username_0**: My original idea was that while long and descriptive names help software engineers that write large, complex programs, they might not be as useful for theoreticians, whose target is somewhat different from that of engineers.  

---

### Answer by username_8 on 2013-10-12. Score: 3

I'm not sure I agree with your premise. I think in most papers, you will find short variable names: some of my personal favorites are $n$, $m$, $i$, $k$, $\epsilon$, and $\alpha$, each quite concise! Now when writing a typeset textbook, one has the luxury to use variable names that make their meaning more apparent to a first-time reader. This is especially true when writing pseudo-code: here, you can borrow from the programming convention of making variable names readable and meaningful, rather than concise.

> **Comments:**
> **username_3**: Aaron, I see you like $\epsilon$ but not $\delta$ :)  
> **username_8**: $\delta$ sucks!  
> **username_5**: I much prefer $\varepsilon$ to $\epsilon$.  
> **username_9**: By looking at the prevalence of `\eps` in text abstracts, I conclude that `\newcommand{\eps}{\varepsilon}` is quite common.  

---

