Physicists vs Engineers
by Tom Temple
2 August 2005
Most engineering profs and most books with which I have come in contact are pretty lousy with notation. I am writing this entirely due to frustration with just such a book and just such a prof.
Physicists on the other hand, tend to be much cleaner. Why do you think? You might guess it has to do with the physicists have a much cleaner job. That isn’t it. If you see the same topic covered in a physics and engs textbook in the same depth, the notation in the engineering book is almost always less clear.
A decent theory is that the history of physics is so broad that differing conventions abound. That requires that each writer be clear about which convention he is using. Is phi the azimuth today or is theta?
It seems to me that in engineering there has been a lot more unification. This leads writers and lecturers to eroniously believe that I will recognize their notation or that I will remember what N_0 stood for from the lecture last friday.
Some of you who took certain classes with me might suggest a different theory. Engineers don’t understand that there is a concept behind that symbol. It is a variable to which a number is assigned when I plug it into the formula. While this was true of the students in those classes, it is not true in general of the people writing these books or teaching those classes.
Computer Science has a great concept here that makes this really simple: scope. Your local notation (as opposed to global like basic math operators) must be declared and goes out of scope when you start doing something else. Scope certainly doesn’t bridge chapters. It shouldn’t bridge from chapters into problems. If you go a few pages without using it, just refresh it.
Suppose that you want to refer to the speed of light,
You should look at the crap I trying to read. I’m going to the bibliography to find the books from which the author poached this notation.
Aug 2, 12:06 PM
Notation is definitely a knotty problem for all mathematical disciplines, and it’s not just engineers who suffer from it, even if they are worse than some of the others. Too often, people get the mistaken idea that the notation they learned in college is somehow “the standard notation,” which is hardly ever true beyond basic high-school algebra.
Okay, that’s a slight exaggeration, but the world would be a much happier place if authors would just spend a chapter defining their notational conventions, and then stick to them.
Apropos of that, here are a few notational things that irritate me a lot: The obsessive infatuation with single-character variable names. Abusive and inconsistent use of multiple alphabets and typefaces. Mixed subscripts and superscripts. Gratuitous use of obscure AMS LaTeX macros. Virtually all uses of the ellipsis.
What are some of your notational gripes?
Aug 2, 12:30 PM
I feel you on the single letter one. But sometimes you have to write long equations with a lot of them in it. All I ask is that on the top of the page, beginning of the chapter or inside the front cover they have a nice obvious box with the definitions.
Matlab really betrays people on that one. When you look at someone else’s matlab code, you can tell whether they think of it as a calculator or as a programming language. When you code it, you may as well use the english word for the thing; “drift_rate” rather than delta_rho_dot even if the book you got it from used \delta\dot{\rho}.
But then the names of some of my variables started to get out of hand (e.g.
data_gm13_1Cverr_vdop_LSn4_n_l7) so I attached an ID number to each which corresponds to a file that tells (in english) what the hell is going on.Aug 3, 07:04 AM
Okay, I will grant you that single-character variable names have their place. I’m not saying we should do away with them; rather, I’d like a notational scheme for mathematics in which they are not the only possible option.
Your variable-meanings file sounds like what I used to do in the bad old days of line-numbered BASIC, in which only the first two characters of a variable name were significant, and every variable was global. I’d keep a piece of graph paper with a 36×36 square marked out on it. At the bottom, I’d write a numbered list of contexts (e.g., subroutines or global meanings). For any given variable, say “A2”, I’d write the context numbers it participated in at the intersection of row “A” and column “2”. It was tedious, but in a long program with no labels, it was the only way to keep things straight.
Actually, another notation-related gripe I have in the context of programming languages is the limitation to US-ASCII. Why the hell cannot I write β and γ instead of “beta” and “gamma”? Well, in Java I can, but I don’t know of any other programming languages that allow it.
Aug 3, 07:04 AM
My pet peeves:
1.) Failure to use different sized parentheses/braces/brackets when nesting them.
2.) Abusive typefaces bother me most when I’m actually trying to take notes by hand. One shouldn’t write on the board using mathcal letters. Very irritating.
3.) Poor choices for representing the identity element in a space with multiple operations. This specifically came from a course on function algebras where you have two types of operations floating around: those involving functions, and those involving the base field (complex). Sadly, we had to use e for the (multiplicative) function identity. This was sad because our text frequently wanted to exponentiate elements of the algebra, and refused to use exp(). Argh.
4.) Using the variable of integration as a limit of integration. This is actually more than just bad notation, it’s technically wrong. I’ve been surprised at how many lecturers (and occasionally books!) make this mistake.
5.) I did an independent study recently using a book that decided to write all actions from the right! So f(x) is now (x)f, or more usually, because they didn’t really like the parentheses, xf. Lovely.
Aug 3, 07:57 AM
Michael, how did you do that? Can you make a $\delta\dot{\rho}$ ? Can you do eqns?
One of the common extended ascii schemes has lowercase beta at E1 and capital gamma at E2.
Joran, while I agree with you on #4, it is a pretty understandable mistake. The variable was time before you integrate and it is going to be time after you integrate. There needs to be a sentence, “Don’t flip out, tau is just a dumby variable; it’ll go away in a couple lines.” to preempt the reader’s, “Where the hell did this tau come from?”
What I was complaining about was sort of different (though I would love to hear more people’s notation peevs). I am looking at a page with 19 eqns on it with roughly 40 distinct symbols. Some are constants, some are variables. Some of the variables are functions, other variables are measurements. You can’t tell which are which.
Of these symbols about a third are defined on this page with two or three words (e.g. “mean anomaly”, not helpful). Half are defined with similar platitudes on the preceding page. Several are defined using helpful and complete sentences within 2 pages, and a couple go completely undefined in the whole book as far as I can tell.
I like Michael’s idea of better variable names. Michael, describe your current variable naming convention? Is it as meticulous as your use of the 936 available to you in BASIC?
I think well-commented code is a good medium for this sort of communication (free speech or not). But you’re right that ascii is terribly limiting. Really the keyboard is the problem. I should be able to draw an eqn, have some software recognize it, clean it up and then stuff it where I want it.
Aug 3, 07:35 PM
Tom asks: “Michael, describe your current variable naming convention?”
I have discovered a truly remarkable system of variable naming, but unfortunately, this comment is not big enough to contain it. ;-)
When I’m programming, it depends a lot upon the language I’m using. Broadly speaking, the length of a name is correlated with the maximum distance between its definition site and any reference to that name. So, I use things like i_ and _j only when definition and use are within a line or two of each other. For single-character names, I loosely follow the convention that i, j, k, m, n, and z_ are integers; _p, q, w, x, and y_ are general objects, _t is a working temporary, etc. Parameters are defined and used locally, but they get to be somewhat longer for documentation purposes.
Beyond that, the rules get fuzzier. Most of the code I write these days is a combination of C and Python, although I occasionally also write in Java, Haskell, and Scheme. C and Python restrict variable names to (English) letters, digits, and underscores, so I use a lot of variable names_like_this. When I program in Java, I follow the conventional mixedCaseNaming scheme there. Names with global binding get to be longer, unless (as in Python) there is a good module system to let me control my namespaces. Don’t even get me started on ML’s module system, though.
I’m not a big believer in Hungarian notation, although I do use prefixes in C to avoid namespace clutter.
Aug 3, 08:21 PM
Oh man, Hungarian notaion, that reminds me of CS23. At an entirely inappropriate time, I had a partner check the entire thing out of CVS so that he could rename all the variables. Let’s just say that I was skeptical that the time investment was worth it.
Aug 4, 05:54 AM
Ugh. When I worked for these characters, there was a guy who would occasionally check out the entire CVS repository, convert all the indenting tabs to spaces, and then commit everything. You’d do an update and every single file would have been modified, on the majority of lines. You can tell CVS to ignore diffs that only involve whitespace, but it was still annoying.
I realize this isn’t the same as variable renaming, but it’s a topic on which programmers are often just as mindlessly and infuriatingly picayune. Engineers and physicists may write abominable code, on average, but at least they don’t tend to get bogged down in idiotic formatting conventions. :-)
Aug 4, 06:29 PM
Though it’s off topic, I want to complain a little more about that CS23 project and that particular kid. I wrote the command parsing mechanism. There was an array of function pointers that went to the actual commands and then there was a parsing algorithm that did good job of pattern matching (as good as unix command line).
It was also the ugliest code I have ever written in my life. It was 800 or so lines, a lot of which was cut and paste from earlier problem sets. I used no external classes. No tokenizers, not strcmp, nothing. I wrote it all myself and it was all in there in the class. I did everything by marching back and forth through char*s. I am not proud of this code.
But then it worked. In fact, it was freaking bomb-proof (life is simple when you look at your input byte by byte). This kid at the eleveth hour takes it to clean it up. Sure other people needed to look at the command dispatch structure, but that part was very well documented (ended by the classic comment,
/*************************/// Here There be Dragons //// | | | | | | | | | | | //// V V V V V V V V V V V ///*************************/where you weren’t supposed to touch.) All you needed to do was something like,
command[ 24 ] = *newcommand;But then he rewrote the whole thing from scratch. He did a really clean job of it too. If we had another month, I would have definitely thanked him. Or if he hadn’t broken it I might have thanked him then too. In the end, I think we ended up reverting that one.
You’ve taught cs23 right? How did you like that? There seems to be a tough mix of tallent in that class.
Aug 5, 06:16 AM
Tom asks: “You’ve taught cs23 right? How did you like that? There seems to be a tough mix of ta[l]ent in that class.”
Yes, in fact I’ve taught it twice now. In 2003, we did a monolithic C++ application (a PowerPoint knockoff) with 4-5 person teams and a fairly traditional planning discipline (the kind that always turns into a waterfall at the end of the term). In 2004, we did a variety of projects that manipulated webcam data in Java and C with 2-3 person teams, using a weak XP-style planning discipline (the kind that always turns into a waterfall at the end of the term).
On a whole, I enjoyed teaching the course, although there are a number of things I’d like to improve if I teach a course like that at my next gig. You’re right about the mix of talents. That difficulty is improved somewhat by smaller teams, and the fact that every project is now different. I can crank down the vang on a team that’s out of control without having to change everybody’s spec out from under them, and there’s better communication within the groups.
Regarding ugly-but-effective code: In my view, the only real justification for throwing out code that works is if it has become a maintenance problem. Otherwise, it’s just aesthetics, and it’s not a priority. This is a bitter pill for a lot of folks to swallow (myself included—I like elegant code), but it’s the only rational approach to take if you are on a schedule.
Of course, if the code doesn’t work, there’s the eternal “patch vs. rewrite” debate, and there are no easy answers there. Joel Spolsky has some good rants on refactoring and rewriting here and here, which are basically on the right track, in my opinion.
Aug 5, 08:05 AM
“Crank down the vang”, I had to look that up. The vang is the rope from the bottom of the mast to the end of the boom and controls the tension in the sail. Cranking it down would “take air out of their sails”? Is that what you meant?
I can’t believe you [sic]’ed me. Noone would have noticed if you had discretely dropped an ‘l’ in your quote. I bet you were the kid who always pointed out the errors in a prof’s derivation even when they didn’t have any effect. “Did you mean minus dx/dt on line 12?”. Obviously he did because the minus sign magically appeared on line 13.
We do really well on google for a number of my mispellings.
Aug 5, 09:40 AM
* @Tom and Michael*
Hungarian Notation is awesome.
I’m working with a lot of data that is the same, but different. It starts out as current densities on an LFM grid in Solar Magnetic coordinates described by XYX vectors, and it ends up as current elements (not densities) on a regular geographic grid in geographic coordinates, described by R-latitude-longitude vectors.
There are at least as many steps involved as you are guessing. Hungarian notation is a clear winner.
j_ll_sm = ll_from_xy(j_xy_sm)
j_ll_geo = geo_from_sm(j_ll_sm)
Come on, how can you not love that? And Michael, how can you point out Joel’s opinion on rewriting, while ignoring his opinion on Hungarian notation (ie, it is awesome.)
* @Tom*
You didn’t get [sic]’ed. If he had given you a sic, then he would have left the mistake and pointed it out, by including the phrase [sic].
* @Everyone*
Every textbook should have a thorough namespace on the front cover. We all know this.
Not every variable needs to have a meaningful name. I’m not sure what I would call the relativistic gamma factor if I couldn’t just call it gamma. I’m not sure what I’d call the ratio of thermal pressure to magnetic pressure if I couldn’t just call it beta.
That said, some notations are brilliant (I’m thinking of Concrete Math’s invented floor and ceiling operators), and some suck (the paper that first derived light with a negative phase velocity used [AB] to mean the cross product of A and B.
Aug 5, 02:03 PM
Tom asked: The vang is the rope from the bottom of the mast to the end of the boom and controls the tension in the sail. Cranking it down would “take air out of their sails”? Is that what you meant?
Yes. More specifically, tightening the vang helps keep the boat from getting overpowered and turning a leeward heel into an outright capsize. This is an issue with a small boats, as they lack a weighted keel in favour of a movable centerboard or daggerboard. I think the analogy to small groups of inexperienced software developers ought to be pretty clear.
Jon: You’re right to cite Joel’s opinions on Hungarian notation, and we should probably also link to Simonyi’s original paper while you’re at it. My bad. But I think he’s only partly right, and I’m going to glibly turn Joel’s own arguments about exceptions against his case for Hungarian, paraphrasing Raymond Chen, editions mine: “It is extraordinarily difficult to see the difference between bad [uses of Hungarian notation] and not-bad [uses of Hungarian notation]”