From the monthly archives:

September 2008

Four uncommon but handy math notations

by John on September 22, 2008

Here are some of my favorite notations that are not commonly used.

The first is Richard Stanley’s notation for counting the number of ways to select k objects from a set of n objects with replacement. This is similar to the problem solved by binomial coefficients, but not the same since binomial coefficients count the number of possible selections without replacement. Stanley’s symbol is

\left( {n \choose k} \right)

I like this symbol for two reasons. First, it’s good to have a notation, any notiation, for a concept that comes up fairly often. Second, it’s appropriate for this symbol to resemble the binary coefficient symbol. See selecting with replacement for more on Stanley’s symbol, how to think about it and how to compute it.

Next is Iverson’s notation for indicator functions. Iverson’s idea was to put a Boolean condition in square brackets to indicate the function that is 1 when that condition is true and 0 otherwise. For example, [x > y] is the function f(x, y) such that f equals 1 when x is greater than y and equals 0 for all other arguments. This notation saves ink and makes it easier to concentrate on the substance of an expression. For more on Iverson’s notation, see Concrete Mathematics.

Another notation from Concrete Mathematics is the use of a perpendicular symbol to note that two integers are relatively prime. For example, m ⊥ n would indicate that that m and n are relatively prime. The more common way to denote this would be to say gcd(m, n) = 1. The perpendicular symbol is nice because perpendicular lines have no component of direction in common, just as relative prime numbers have no prime factors in common.

Finally, multi-index notation is a handy way to make multivariable theorems easier to remember. For example, with this notation, Taylor series in several variables look similar to Taylor series in one variable.

Related link:

Stanley’s twelvefold way

{ 2 comments }

Robert’s rules of order and Galveston flooding

by John on September 21, 2008

I found out recently that Henry Martyn Robert of Robert’s Rules of Order fame was also a civil engineer. After the devastating hurricane of 1900, Robert was part of the effort to raise the level of Galveston Island and build a seawall. As much damage as Hurricane Ike did to Galveston, it would have been far worse without the efforts of Robert and others over a century ago.

For more information, see Engines of Our Ingenuity Episode 1099.

Galveston Seawall

Galveston Seawall

{ 0 comments }

Writes large correct programs

by John on September 19, 2008

I had a conversation yesterday with someone who said he needed to hire a computer scientist.  I replied that actually he needed to hire someone who could program, and that not all computer scientists could program. He disagreed, but I stood by my statement.  I’ve known too many people with computer science degrees, even advanced degrees, who were ineffective software developers.  Of course I’ve also known people with computer science degrees, especially advanced degrees, that were terrific software developers.  The most I’ll say is that programming ability is positively correlated with computer science achievement.

The conversation turned to what it means to say someone can program.  My proposed definition was someone who could write large programs that have a high probability of being correct.  Joel Spolsky wrote a good book last year called Smart and Gets Things Done about recruiting great programmers.  I agree with looking for someone who is “smart and gets things done,” but “writes large correct programs” may be easier to explain. The two ideas overlap a great deal.

People who are not professional programmers often don’t realize how the difficulty of writing software increases with size.  Many people who wrote 100-line programs in college imagine that they could write 1,000-line programs if they worked at it 10 times longer.  Or even worse, they imagine they could write 10,000-line programs if they worked 100 times longer. It doesn’t work that way.  Most people who can write a 100-line program could never finish a 10,000-line program no matter how long they worked on it.  They would simply drown in complexity.  One of the marks of a professional programmer is knowing how to organize software so that the complexity remains manageable as the size increases.  Even among professionals there are large differences in ability.  The programmers who can effectively manage 100,000-line projects are in a different league than those who can manage 10,000-line projects.

(When I talk about a program that is so many lines long, I mean a program that needs to be about that long. It’s no achievement to write 1,000 lines of code for a problem that would be reasonable to solve in 10.)

Writing large buggy programs is hard.  To say a program is buggy is to imply that it is at least of sufficient quality to approximate what it’s supposed to do much of the time.  For example, you wouldn’t say that Notepad is a buggy web browser.  A program has got to display web pages at least occassionally to be called a buggy browser.

Writing large correct programs is much harder.  It’s even impossible, depending on what you mean by “large” and “correct.”  No large program is completely bug-free, but some large programs have a very small probability of failure.  The best programmers can think of a dozen ways to solve any problem, and they choose the way they believe has the best chance of being implemented corrrectly.  Or they choose the way that is most likely to make an error obvious if it does occur.  They know that software needs to be tested and they design their software to make it easier to test.

If you ask an amateur whether their program is correct, they are likely to be offended.  They’ll tell you that of course it’s correct because they were careful when they wrote it.  If you ask a professional the same question, they may tell you that their program probably has bugs, but then go on to tell you how they’ve tested it and what logging facilities are in place to help debug errors when they show up later.

{ 3 comments }

Amazon and cloud computing

by John on September 18, 2008

Continuing the theme of cloud computing from my previous post, here’s a post from Werner Vogels, CTO of Amazon, on his company’s cloud computing services: Expanding the cloud.

{ 0 comments }

There’s been much debate about the relative merits of desktop applications versus internet-based applications. Both styles have their advantages, but the hybrid of both is less reliable than either separately.

Hurricane Ike knocked out our electricity for a couple days. Once the power came back on, I could use any software installed on my PC. We don’t have an internet connection yet, but I’ve been able to check email etc. from other computers. I can use my PC, I can access the internet, but I can’t do both at the same time. That means, for example, I can’t add podcasts to my iPod. Also, my back-up software cannot run. Applications that require local software and an internet connection are the least reliable. I can work locally and move files around with a flash drive, or I can work “in the cloud,” but I cannot work in mid-air.

The trend lately has been toward cloud computing, entrusting your data and applications to anonymous servers somewhere out on the internet. This can be a smart move. Companies like Amazon and Google have more sophisticated contingency plans than most consumers: redundant power and network connections, data centers in multiple geographic locations, etc. But there are always trade-offs. Think about an analogous situation with utility lines.

There has also been a trend toward underground utility lines. And recent experience shows what a good move that can be. Essentially the only places in Houston that had power immediately after the hurricane passed through were Downtown and the Galleria, two areas with underground utilities. Everyone with above-ground utilities was in the dark. But there’s more to consider. When Tropical Storm Allison came through Houston a few years ago, the underground utilities flooded and Downtown was without electricity while areas with old-fashioned powerlines were OK.

Above-ground and underground power lines both have their advantages, and overall it seems the latter is better. The most vulnerable position would be to depend on both above-ground and underground utilities, analogous to depending on both a particular PC and an internet connection.

{ 0 comments }

Four ways to convert Excel tables to LaTeX

by John on September 16, 2008

Gregor Gorjanc has a post on Excel and LaTeX that lists four ways to convert and Excel table into LaTeX. I’ve used two of the methods he lists: brute force and excel2latex. I recommend excel2latex. I used it frequently until I upgraded to Office 2007 and the plug-in quit working. The only bug I remember with it was that sometimes it would give you a warning saying it didn’t work, but it did; the LaTeX code you wanted was waiting for you on the Windows clipboard.

I plan to try out Gregor’s other two suggestions. Creating tables in Excel is far easier than doing so in LaTeX and I miss the functionality that excel2latex provided. Maybe there’s a way to use excel2latex with Excel 2007. If you know of a way, please leave a comment.

{ 11 comments }

Recovering from Hurricane Ike

by John on September 14, 2008

Hurricane Ike did relatively little damage in our neighborhood. Lots of tree limbs down, but no damage to the houses around us. Many people in Houston were harder hit. Our electricity is still out, but it looks like we’ll have power again soon.

{ 0 comments }

Finding distances using latitude and longitude

by John on September 11, 2008

I posted a page this evening that lets you calculate the distance between two locations using their latitudes and longitudes. I’ve had to do this calculation once in a while and thought I’d make it available online for anyone else who needed to do the same. There is one page providing an online calculator and another page giving the formula used to calculate the distances and its derivation.

This project was prompted by a friend asking me how far my home is from Galveston where the hurricane is supposed to make landfall this weekend. Since we live northwest of Houston, we’re pretty far inland.

Related posts:

What is the shape of the earth?
Spherical trigonometry

{ 1 comment }

Simple interpolation

by John on September 11, 2008

CodeProject just posted my article Filling in the gaps: simple interpolation.

{ 0 comments }

Xylophones and zebras part III: English grammar

by John on September 10, 2008

A friend of mine who is a linguist told me one time that most native English speakers have never had a course in English grammar. They’ve had courses in the pet peeves of English teachers, but have never seen a systematic description of the structure of the English language.

See also xylophones and zebras, learning Spanish.

{ 1 comment }

How to compute binomial coefficients

by John on September 9, 2008

My previous post showed how to define binomial coefficients for general arguments.  I just posted an article that explains how to compute binomial coefficients. Here’s a chart from the article for computing the binomial coefficient (z, w) for arbitrary complex z and w.

See also How to calculate binomial probabilities.

{ 1 comment }

Binomial coefficients

by John on September 8, 2008

The simplest definition of binomial coefficients is given by

{n \choose k} = \frac{n!}{k! (n-k)!}

where n is a positive integer and 0 ≤ k ≤ n. There are two generalizations of this definition. The first is to let n be any real number. Then the binomial coefficient (r, k) can be defined as

more general definition

where

falling power definition

is the kth falling power of r. This definition is adequate for most applications.

The final generalization is to let z and w be any complex numbers and define the binomial coefficient (z, w) as

binomial coefficient as limit of gammas

This generalization is more complicated, but in some sense it is more natural. Essentially it uses the simplest definition and replaces n! with Γ(n+1). However, the business of the limits is subtle and important.

For motivation of these definitions and details regarding how they work, see the article Binomial coefficients.

{ 1 comment }

Drug looks promising, come back in 30 years

by John on September 7, 2008

The most recent 60-Second Science podcast summarizes a paper in Science magazine reporting that the average interval between a drug being deemed “promising” and the first paper appearing showing clinical effectiveness is 24 years.

Note that the publication of a paper saying a drug is clinically effective is a far cry from regulatory approval. Many new drugs that look like an improvement after a phase II trial turn out to be no better than existing treatments, and those really are better take years to achieve regulatory approval.

See also

False positives for medical papers
Most published research results are false

{ 0 comments }

How to treat a stingray wound

by John on September 6, 2008

This afternoon, my family and I were wading on the shores of the Gulf of Mexico off Galveston Island. A stingray cut one of my daughters on her foot. When I took her somewhere for help, the main thing they did was to put her foot in a pan of hot water. It only takes about 30 seconds for the heat from the water to bring relief by neutralizing the toxin from the stingray. You have to keep soaking a while longer or else the pain will come right back. The nurse said that a chemical hotpad makes a good treatment if you can’t get to hot water and that the same treatment is effective for other common stings in this area.

My daughter is fine now. The hot water and a topical antibiotic were all she needed.

{ 3 comments }

The previous posts in this series have looked at P(X > Y), the probability that a sample from a random variable X is greater than a sample from an independent random variable Y. In applications, X and Y have different distributions but come from the same distribution family.

Sometimes applications require computing P(X > max(Y, Z)). For example, an adaptively randomized trial of three treatments may be designed to assign a treatment with probability equal to the probability that that treatment has the best response. In a trial with a binary outcome, the variables X, Y, and Z may be beta random variables representing the probability of response. In a trial with a time-to-event outcome, the variables might be gamma random variables representing survival time.

Sometimes we’re interested in the opposite inequality, P(X < min(Y,Z)). This would be the case if we thought in terms of failures rather than responses, or wanted to minimize the time to a desirable event rather than maximizing the time to an undesirable event.

The maximum and minimum inequalities are related by the following equation:

P(X < min(Y,Z)) = P(X > max(Y, Z)) + 1 – P(X > Y) – P(X > Z).

These inequalities are used for safety monitoring rules as well as to determine randomization probabilities. In a trial seeking to maximize responses, a treatment arm X might be dropped if P(X > max(Y,Z)) becomes too small.

In principle one could design an adaptively randomized trial with n treatment arms for any n ≥ 2 based on P(X1 > max(X2, …, Xn)). In practice, the most common value of n by far is 2. Sometimes n is 3. I’m not familiar with an adaptively randomized trial with more than three arms. I’ve heard of an adaptively randomized trial that was designed with five arms, but I don’t believe the trial ran.

Computing P(X1 > max(X2, …, Xn)) by numerical integration becomes more difficult as n increases. For large n, simulation may be more efficient than integration. Computing P(X1 > max(X2, …, Xn)) for gamma random variables with n=3 was unacceptably slow in a previous version of our adaptive randomization software. The search for a faster algorithm lead to this paper: Numerical Evaluation of Gamma Inequalities.

Previous posts on random inequalities:

Introduction
Analytical results
Numerical results
Cauchy distributions
Beta distributions
Gamma distributions

{ 0 comments }