# IEEE Computer Society Style Guide

**A B C** **D E F** **G H I** **J K L** **M N O** **P Q R** **S T U** **V W X Y Z**

** Special Sections, Style Guide home**

Download the IEEE Computer Society 2013 Style Guide |

## Mathematical Expressions

Most style manuals do not cover mathematical style well. *CMS* has some good suggestions in Chapter 12, but is insufficient. Another reference source is N.J. Higham, *The Handbook of Writing for the Mathematical Sciences*, Society for Industrial and Applied Mathematics, 1998. Although this book is largely about how to *write* mathematics clearly, it also has some suggestions about math typography and other stylistic matters.

**Miscellaneous math style issues**

If authors use punctuation after mathematical expressions, including displayed equations, leave it in (or revise as necessary).

- Include a space on either side of multiplication signs, equals signs, and other operators when they are at full size, for example, 100 x 100 matrix, and
*a + b = c*. MathType automatically inserts thin spaces around these symbols. In subscripts and superscripts, omit these thin spaces unless the formula becomes confusing without them. Also, when < or > precedes a number in text (that isn't a formula), there should be no space after the symbol. - If line breaks are needed in equations that appear in a paragraph, they should come after a plus sign, equals sign, or similar character.
- Characters with overbars must be set in MathType. If an article has many symbols with overbars or other symbols that make typesetting difficult, consider asking the author if there is an easier alternative.
- Equation numbers are put in parentheses to the right of displayed formulas. They should not be boldface. Generally speaking, only formulas called out in the text need to be numbered.
- Use italic type for lowercase Greek variables; do not use italic type for uppercase Greek variables.
- Variables that denote vectors are set boldface, not italic. Do not use the small arrows above the variable to denote vectors.
- Set the label that denotes a matrix in italic, for example,
*A*. - If the vectors are simply mathematical and do not represent physical quantities and direction (that is, they do not need to be clearly differentiated from scalars), boldfacing is less important, and you can use lightface italic type if the author has styled them that way.

If the author consistently uses another scheme, consider going along with it.

**Equation formatting guidelines**

Display equations can be broken down a number of ways to fit within a column. First, note that each line of an equation must be aligned to either a relation symbol or a binary operator in the first line of the equation (if one exists). These symbols work in a hierarchy: Relation symbols are aligned with other relation symbols, binary operators are aligned with other binary operators, and binary operators are indented from relation symbols. For example:

If there is only one relation symbol or binary operator in an equation, break the equation after the relation symbol or binary operator and indent the second line slightly:

If there is room, align the equation like this:

If a display equation can't be centered, the first line can be made flush left to the column to allow more room for the following lines of the equation to fit. If an equation number won't fit to the right of an equation, it is acceptable to have the equation number fall one line below the equation and to keep it right-justified to the column.

## Math guidelines

When should you italicize, when should you use bold, and when should you do neither? If you edit Computer Society articles, you need to have a good handle on the answers to these questions. The detailed answers below are meant to help you see the logic behind these answers, so that you will be able to consistently make the right decisions when confronted with a math-heavy article.

### Constants

A *constant* is a letter that represents one distinct value that never changes, no matter what. Don't italicize constants. For example, the letter k is often used to represent Boltzmann's constant, which is always equal to 1.380622 ´ 10^{–23} Joules/Kelvin. We use the letter k to avoid having to write out this long number in our equations, but it's not a variable, because its value can never change; it remains constant. In most cases, the author will identify the letter as a constant. If he or she doesn't, you can probably assume it's not a constant. The only exception I can think of is the speed of light (2.997925 ´ 10^{8} m/s), a constant typically represented by the letter c. Authors probably wouldn't explicitly refer to it as "a constant," but it is, and you should not italicize it. By the way, this is the same c that appears in Einstein's most famous equation, *E* = *m*c^{2}. Written properly, the *E* (energy) and *m* (mass) should be italicized (because they're variables), but the c (the speed of light) should not be italicized.

### Variables

A *variable*, unlike a constant, is a letter that can represent more than one possible value. Italicize all such letters (except uppercase Greek). For example, we could represent time by the letter *t*, a variable. Time can be 3, 4, 5, … seconds. Time is a variable. Even when we are referring to one instance (for example, *t* = 4), or even if the author says something like "we are keeping the time constant," we should still italicize *t* because it is *possible* in another situation that *t* would not be kept constant at 4 ms or whatever. Time is not a constant that is universally always equal to 4. The speed of light, on the other hand, never changes, no matter what. Boltzmann's constant never changes either. That is, it is *impossible* for a constant to be anything except the value it equals. If you can't make this statement, then you're not looking at a constant.

### Matrices

*Matrices *represent an array of numbers (columns and rows), like the desks in a classroom. Make them italic. In addition, the individual elements should be italic (not bold), because they are actually variables. For example, imagine you are in classroom *A*, a matrix. The person in the 1st row, 1st column is element *a*_{11}. Second row, first column is element *a*_{21}. *If you sit in the 2nd row from the front, 3rd column from the left*, you are element *a*_{23}. Note that rows go across the classroom (side to side), while columns go from front to back (even though, for some reason, in school people call "rows" what are actually columns). Now, the person behind you (3rd row, 3rd column) is element *a*_{33}. The person to your right (second row, fourth column) is element *a*_{24}, and so on.

### Vectors

*Vectors* are, in a way, special variables that also have a direction associated with them. However, do not italicize vectors. Instead, make vectors bold—for example, the vector **v**. We typically represent vectors by lowercase letters, whereas we represent matrices by uppercase letters. However, we often represent the elements in a matrix by lowercase letters (but I think I've seen capital letters used for matrix elements as well).

### Units

*Units* are letters that actually stand for words, not numbers. Do not italicize them. For example, when s means second, we should not italicize it. The same goes for Greek letters. We italicize lowercase Greek variables, but we do not italicize lowercase Greek units, such as the m in ms (meaning microseconds).

### Acronyms disguised as variables

Beware of *acronyms disguised as variables*! Don't italicize them. Innocent editors can fall prey to mistakenly italicizing a subscript or superscript that looks like a variable but actually isn't. For example, in *V*_{DD}, the letter *V* is a variable and should be italicized, but DD are neither variables nor constants. They are more akin to acronyms. They don't stand for numbers; they stand for words. That's the test. ** If you can't put a number in for a letter, then don't italicize it, because it's not a variable.** In this case, the DD tells us that this is the drain voltage in a transistor. Now, let's consider

*V*

_{T}. This T probably refers to "temperature," and so is not a variable. You'll have to look at the context surrounding it. However, usually these subscripts are not variables. A common exception is

*n*or

*i*(or even

*t*), when indicating a series of numbers such as

*V*

_{1},

*V*

_{2}, …,

*V*. In this case, a number can indeed be inserted in place of

_{n}*n*, so we should italicize it. Another example of an acronym in disguise, but one that is not a subscript, is in the following sentence from an article I edited by Sachdev: "The NMOS transistor's source (n+), bulk (p–), and drain (n+) terminals form an npn bipolar transistor." In this case, the n and p are neither variables nor constants. They are, once again, more akin to acronyms but typically appear in lowercase. You cannot substitute a number for either of these.

### Control-flow diagrams

Letters in *control-flow diagrams* represent steps, not numbers. Don't italicize them. Once again, a variable is a letter that represents a number. If you can't substitute a number for a letter, then that letter is not a variable and thus should not be italicized. For an example of a control-flow diagram, see Figures 1 and 2 in "Intra-Task Voltage Scheduling for Low-Energy, Hard, Real-Time Applications" (Dongkun Shin, Jihong Kim, and Seongsoo Lee, *IEEE Design & Test*, Mar.-Apr. 2001, pp. 20-21).

### Coding math

Always code math from your keyboard or the insert/symbol/Symbol font menu rather than from other menus (such as normal type, Euclid Math, and so on). Hard-coding the symbols using the numeric keypad is also acceptable (for example, you can use Alt 0150 to insert a minus sign); but don't forget to turn NumLock on.

### When to use or not use MathType

The general rule of thumb is to resist using MathType. MathType is difficult to set when it is inline—embedded in the text—because the artist must make a small picture box sit inline with the text. Stand-alone display—when a MathType equation sits on a line of its own—also takes more processing by the production artist.

### Unavoidable MathType

A few situations always require the use of MathType. If you really think you need to use Math Type but the situation isn't listed here, you might consider getting a second opinion from someone familiar with math.

**Stacked equations.** In these equations, one string of mathematical operations sits above another:

Always consider whether these can be converted to a single line (using a slash to represent the fraction bar instead of a horizontal line).

**Equations that use the square root symbol.** An example is . Try instead (if the author doesn't object) raising the number to the 1/2 power (*T*_{be} = *T _{x}*

^{1/2}), which is the same as taking the square root.

**Characters with overbars.** If possible, consider whether the author can make some substitution. Some production artists actually throws out our carefully coded Math Type overbar characters and draw a bar over the letter in Quark. But you still may need to code MathType for SGML.

**An exponent of an exponent.** An example of this would be . Unfortunately, there's not much we can do to change this one.

**A superscript of a superscript** **or a subscript of a subscript:** For the latter case, consider asking the author to use, for example, *a _{t}*

_{4}, which can be coded without MathType. For the former (a super of a sub), use MathType.

## Common ways to avoid MathType

A character that has both a superscript and a subscript—for example, *G*_{P}* ^{A}*—does not require MathType. Simply code the

*p*as a subscript and code the

*A*as a superscript.

Change a stacked equation, such as

into a single-line equation: *T*_{be} = *T*_{o}/(*P*_{w} – *P*_{s}). Note the necessary use of parentheses in this case.