Equations
Ron Graham
with Fred Klingener, Bob Kluck, and Tim Wescott
There are several considerations involved in presenting equations:
  1. document format
    • Word or other word processor
    • HTML or other browser-friendly
    • other document formats (e.g. TeX or PostScript)
    • generated by other programs (e.g. MathCAD, Mathematica)
  2. special characters and math symbols
    • as ASCII text
    • as images
  3. subscripts and superscripts
  4. significant digits
But the primary issue in presenting equations is one of accessibility: will your audience be able to see what you present in the same way that you see it? If you choose a special document format (e.g. TeX or PostScript), you'll have a rich set of capabilities regarding the formatting of equations -- and you may also find that your audience can't read the format you've chosen! Then you may find yourself with requests for reprints.

Likewise, if you present equations at your Web site, you may find that special characters, math symbols, and subscripts and superscripts offer accessibility problems for those in your audience who (for whatever reason) aren't using the latest versions of Netscape or Internet Explorer.

In either case, if you have to use a certain methodology that works well for you, at least have a summary available in the most commonly-used format you can, so that your audience can at least decide whether to contact you for more information.

Most of your favorite alternative document formats (TeX, PostScript, etc.) and your favorite math software (MathCAD, Mathematica, etc.) can produce image files not only of plots, but of equations as well. If you do this, you should keep in mind that GIF is an image format that nearly everyone in your audience can handle -- it can be interpreted by word processors and Web browsers alike, and there is plenty of software out there to convert other formats if necessary.

simple controls transfer function

You should also be aware that some FTP clients still demand individual entry of each file (and thus every GIF), but those clients are becoming fewer and fewer.

ASCII (plain text) formatting examples

one line: 


d (hi/ho) = (ho d (hi) - hi d (ho)) / (ho ho)
multi-line: 

   hi    ho d (hi) - hi d (ho)
d (--) = ---------------------
   ho            ho ho
one line: 

a^2 + b^2 = c^2
multi-line: 

 2    2    2
a  + b  = c
These work well if
  • you don't mind using full lines for subscripts and superscripts
  • you use a fixed-width font (e.g. Courier) or, better yet, a plain text editor (e.g. Notepad)
  • your audience doesn't mind such an informal presentation
  • you want to show equations inline, without special blocks of inserted symbols
  • you want to show generic procedural representations, a la programming "pseudocode."
This is, of course, best for informal transmission of equations (e.g. via Usenet or e-mail).

Remember that superscripts in math literature have multiple meanings: they may literally *be* superscripts; they may also be identifiers like footnote/reference numbers. The superscript only tells us what the number *looks like*, not what it *is*.

HTML formatting examples

Keep in mind that use of HTML subscripts and superscripts will bollix up the format of your Web page -- unless you use style sheets to control the placement of the subscript/superscript. Even if you do, style sheet manipulation of font sizes may have unpredictable effects.

Pk = Kp (ek + ek-1)
Ik = Ki T ek
Dk = (Kd/T) (ek + 2 ek-1 + ek-2)
CVk = CVk-1 + Pk + Ik + Dk

Some readers simply distrust HTML for rendering of equations correctly. It's up to you, if you're using that medium, to get around that distrust. It's also up to you to ensure that symbols are used correctly - sometimes pairs of symbols *look* almost alike but have different *meanings* - and the use of the wrong symbols in this medium lends to that distrust. And again, both superscripts and subscripts in HTML and CSS may represent multiple meanings: markups only describe what they look like.

Greek letters can be an issue for many engineers. The characters are readily available in popular word processing programs, however, though they must generally be inserted on a character-by-character basis. Since this can be a tedious process, you should be sure to check what you write perhaps more carefully than usual. Greek letters can also be rendered by some later versions of Web browsers -- but not by all browsers. You should as an example look at the following table and see if the letters all appear properly:

small caps small caps
a
b
c
d
e
f
g
h
i
j
k
l
m
 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 		N
O
P
Q
R
S
T
U
V
W
X
Y
Z

You may find that you don't have to provide the "basics" yourself - someone else out there will have done already, probably at some university as a classroom tool. You would only need to link to it, instead of actually developing it, and maybe send a note to its author(s).

Other considerations

  1. Running commentary between equations. This is commonly found when engineers present a derivation, or some other solution involving distinct steps. You should be careful to ensure that any running commentary actually adds value to the equations presented. "...which leads to...," by itself, doesn't. On the other hand, skipping steps to "eliminate" clauses like "which leads to" won't do much to help your audience, either.
  2. Ratio of equations to text. When this ratio gets high, it becomes difficult for even the most math-savvy reader to keep up with your presentation; it's absolutely impossible for most readers to detect fine details (such as typos) altogether. Some professional journals require lengthy derivations, and in that case there's not much you can do about it - but consider the possibility of an appendix with the full derivation, and a text summary of the steps involved in the main body of the report.
  3. Added value. If an equation is likely to be well-known by your audience, leave it out! Say in the text that you've used it and that should do the job! We run into this often with such expressions as f=ma and V=IR, but there are other families of equations that will immediately appear in the reader's mind when they're mentioned. Most of those are simple (e.g. second-order system response, one-dimensional heat transfer, etc.), but depending in the specialization of your audience, you may find more complex relationships to be redundant. You may also find those relationships have been recorded elsewhere, in some text likely to be popular with your audience, and in that case you can reference them.

    NOTE: some audiences won't let you get away from this even when they know the equations.

    NOTE: some publishers feel that every equation printed in a book reduces the number of sales by half. Be careful with using equations, especially on Web sites, because they may discourage some readers from reading on.

It all depends, as usual, on what your audience is going to need, and how good you are at predicting it.

Rederiving Equations

Engineers are concerned about the need to rederive sets of equations in lectures, reports and papers in the first place. This summary results from the following question, posed by Mithaiwala:

Why do professors put so much emphasis on explaining concepts by rederiving equations? It seems that so much time is wasted on things that have been proven. If [they] would spend time in lectures working examples we would get more out of lectures.

In general, rederiving provides the following benefits to young students and new hires:

  • develops discipline
  • lends confidence (in what the young person thinks is an understanding of the basics)
On the other hand, rederiving has the following drawbacks:
  • equations may not apply to problems experienced in the field
  • derivations are easy to forget after the class is over
  • derivations can go by too quickly to make an impression
  • derivations can develop the wrong kind of logic and discipline
Most of those who responded felt that simply rederiving equations during a lecture, particularly those that are sufficiently derived in the textbook, is a poor way to prepare students for engineering field work. Derivation is not shown to be the only/simplest/most exhaustive way to build critical thinking. Nevertheless, a case can be made for the act of derivation: there is a progression of thought that it's desirable to have the young student develop.

What's needed is a context for the examples, an opportunity for the student to imagine other solutions, and an opportunity for the instructor to explain what goes into the assumptions. Assumptions are what shapes reality into equations.

So here's a model for enhancement of the "traditional" development of equations during lecture:

  1. Perturb the example. Set different boundary conditions; give a different parameter and take another one away; add the dimensions of schedule, budget, and human factors to the problem for an entirely new set of constraints. Let the students help with this.
  2. Eliminate the phrase "it can be shown that" from your lecture altogether. You are only using it to skip steps in the procedure anyway. Skip too many steps and you have lost the purpose of the derivation. If you can't afford to skip fewer steps, then you are doing too many derivations.
  3. Call upon your students to provide critical thinking. Ask them whether an assumption is reasonable. Ask them if they have ever seen such a system in action, and what they observed. Ask them if the example is helping with their understanding of the material. If it doesn't, you have to take action: provide a context for the example yourself, based on your own field experience. (If you don't have field experience, that's another problem, addressed elsewhere in the FAQ.)

References

Jukka Korpela's Math in HTML and CSS

Contributors

Tom Coradeschi, Julian M. Cortella, John Fisher, Tushar Mithaiwala, Ed Moore, "mbushore," Peter O'Leary, Carlos Murillo-Sanchez, Vinh D. Nguyen, Jim Papadopoulos, Dan Stephenson, Michael W. Wong

What You Can Do

  1. Decide the level of math you want to present first. Generally, the less sophisticated the audience, the less math; but even with highly technical audiences there's a limit that only you can find.
  2. Remember that its making sense to YOU is not enough. You can't usually say "trust me, I'm an engineer," but you can't usually offer an embedded math lesson either.
[Table of Contents] [Previous] [Next]