Month: March 2009

Functional in the small, OO in the large

Posted on by John

The most recent episode of Software Engineering Radio is an interview with Luke Hoban, program manager for F#. The interview mentioned the idea of using functional programming in the small and object oriented programming in the large. In other words, individual methods might be implemented using a functional programming paradigm, say in F#, but the code would be bundled into an object for other parts of an application to use. The grand structure would be object oriented, but the small structure would be functional.

I suppose “functional in the small, OO in the large” makes sense, but I could imagine someone arguing for a different way to combine the two approaches to programming. Any thoughts?

Means and inequalities

Posted on by John

The arithmetic mean of two numbers a and b is (a + b)/2.

The geometric mean of a and b is √(ab).

The harmonic mean of a and b is 2/(1/a + 1/b).

This post will generalize these definitions of means and state a general inequality relating the generalized means.

Let x be a vector of non-negative real numbers, x = (x1, x2, x3…, xn). Define Mr( x ) to be

M_r(x) = \left( \frac{1}{n} \sum_{i = 1}^n x_i^r \right)^{1/r}

unless r = 0 or  r is negative and one of the xi is zero. If r = 0, define Mr( x ) to be the limit of Mr( x ) as r decreases to 0 . And if r is negative and one of the xi is zero, define Mr( x ) to be zero. The arithmetic, geometric, and harmonic means correspond to M1, M0, and M-1 respectively.

Define M∞( x ) to be the limit of Mr( x ) as r goes to ∞. Similarly, define M-∞( x ) to be the limit of Mr( x ) as r goes to –∞. Then M∞( x ) equals max(x1, x2, x3…, xn) and M-∞( x ) equals min(x1, x2, x3…, xn).

In summary, the minimum, harmonic mean, geometric mean, arithmetic mean and maximum are all special cases of Mr( x ) corresponding to r = –∞, –1, 0, 1, and ∞ respectively. Of course other values of r are possible; these five are just the most familiar. Another common example is the root-mean-square (RMS) corresponding to r = 2.

A famous theorem says that the geometric mean is never greater than the arithmetic mean. This is a very special case of the following theorem.

If r ≤ s then Mr( x ) ≤ Ms( x ).

In fact we can say a little more. If r < s then Mr( x ) < Ms( x ) unless x1 = x2 = x3 = …. = xn or s ≤ 0 and one of the xi is zero.

We could generalize the means Mr a bit more by introducing positive weights pi such that p1 + p2 + p3 + … + pn = 1. We could then define Mr( x ) as

M_r(x) = \left( \sum_{i = 1}^n p_i x_i^r \right)^{1/r}

with the same fine print as in the previous definition. The earlier definition reduces to this new definition with pi = 1/n. The above statements about the means Mr( x ) continue to hold under this more general definition.

For more on means and inequalities, see Inequalities by Hardy, Littlewood, and Pólya.

Update: Analogous results for means of functions, replacing sums with integrals. Also, physical examples of harmonic mean with springs and resistors.

Related post: Old math books

Unicode function names

Posted on by John

Keith Hill has a fun blog post on using Unicode characters in PowerShell function names. Here’s an example from his article using the square root symbol for the square root function.

PS> function √($num) { [Math]::Sqrt($num) }
PS> √ 81
9

As Keith points out, these symbols are not practical since they’re difficult to enter, but they’re fun to play around with.

Here’s another example using the symbol for pounds sterling

for the function to convert British pounds to US dollars.

PS> function £($num) { 1.44*$num }
PS> £ 300.00
432

(As I write this, a British pound is worth $1.44 USD. If you wanted to get fancy, you could call a web service in your function to get the current exchange rate.)

I read once that someone (Larry Wall?) had semi-seriously suggested using the Japanese Yen currency symbol

for the “zip” function in Perl 6 since the symbol looks like a zipper.

Mathematica lets you use Greek letters as variable and function names, and it provides convenient ways to enter these characters, either graphically or via their TeX representations. I think this is a great idea. It could make mathematical source code much more readable. But I don’t use it because I’ve never got into the habit of doing so.

There are some dangers to allowing Unicode characters in programming languages. Because Unicode characters are semantic rather than visual, two characters may have the same graphical representation. Here are a couple examples. The Roman letter A (U+0041) and the capital Greek letter Α (U+0391) look the same but correspond to different characters. Also, the Greek letter Ω (U+03A9) and the symbol Ω (U+2126) for Ohms (unit of electrical resistance) have the same visual representation but are different characters. (Or at least they may have the same visual representation. A font designer may choose, for example, to distinguish Omega and Ohm, but that’s not a concern to the Unicode Consortium.)

The buck stops with the programmer

Posted on by John

The programmer is the last link in the chain of a software project. Everyone higher up the organization chart can leave out details, but the programmer cannot. Anything left unspecified will be decided by the programmer. He cannot pass the buck because he has to make something work. Programmers make good decisions, bad decisions, and many arbitrary but neutral decisions.

When you see software with a silly interface, odds are the interface details were not specified and the programmer chose the path of least effort. Why should I press # after entering my five-digit zip code on a phone? It’s logically possible to determine what my zip code is as soon as I enter the fifth digit, but it makes life easier for some phone system programmer if the pound sign is a universal end-of-input signal. Or why should I select an account at the ATM if I only have one account? Again, I’m sure this made life easier for some programmer.

The BUCK STOPS here!

Some programmers are lazy. But some are unsung heroes. They understand gritty details of their company that no one else knows about. They have to: they have to specify these details to dumb machines. Most people don’t want to solve problems down to the final detail and programmers — for better and for worse — are the ones who fill in the gaps.

Some of the details that programmers fill in regard what to do when things go wrong. A client says a program is supposed to collect the user’s Social Security number (SSN). Fine. But what if the user doesn’t have an SSN? What if they enter an invalid SSN? (Is there a way to know whether an SSN is valid?)  After a few questions like that, the client will throw up his hands and leave it up to the developer. But the developer cannot throw up his hands. He has to decide something, even if he passively decides to let the software crash in case of unexpected input.

Related posts

Where does the programming effort go?

Posted on by John

I stumbled across this quote from Mary Shaw.

Less than 10% of the code has to do with the ostensible purpose of the system; the rest deals with input-output, data validation, data structure maintenance, and other housekeeping.

I don’t know the context of her quote, but she could be talking about any software project.

When I began working as a professional programmer, I was surprised that I spent most of my time on work that wasn’t directly related to what I wanted to accomplish. Computer science classes and writing software for my own research had not prepared me for this. I kept thinking that as I got more experience, the proportion of my effort going directly toward what I wanted to accomplish would increase. It did, but very slowly, and never by very much. Only later did the reason occur to me: the vast majority of the work that needs to be done isn’t directly related to the purpose of the project.

People who know a little bit about programming can make difficult clients because they can imagine how they might write the core 10% (or maybe core 2%) of a large project.

Every once in a while someone will claim to have a solution that will change things. They’re selling a framework, a language,  etc. that will radically change things. The sales pitch is “You spend most of your time doing low-level stuff. Use my product and your programmers can focus on the value-added part and not do so much plumbing.” But plumbing is value-added work. (Call it “infrastructure” if you like; that sounds more important.) Sometimes plumbing work becomes repetitive and can be reduced by reusing code, but there’s always new plumbing to work on. Most of the work to be done is invisible and I don’t foresee this changing any time soon.

Update: See this list of non-functional requirements by Mike Griffiths. This list gives some specific examples of where development effort goes, things that must be done but are not obvious until you mention them.

How to preserve documents

Posted on by John

A conversation at work this morning inspired a post on the Reproducible Ideas blog about preserving documents. Physically preserving documents may be the easy part. Keeping alive the memory that the documents exist can be much harder.

photo of the Rosetta disk from the Rosetta Project

[The image above is a photograph of the Rosetta Disk, a disk preserving 13,000 pages of documentation about 1,500 human languages. The information is not encoded as bits; it is engraved. A thousand years from now, a scholar could read the disk using only a microscope. Click on the image for more information about the Rosetta Disk.]

Don’t forget the salt

Posted on by John

The following story comes from Alton Brown’s book I’m Just Here for More Food, page 76.

Years ago Alton Brown ruined 50 pounds of dough by forgetting to add salt. By the time he remembered, it was too late. He threw the dough in dumpster behind the restaurant he was working in.

By noon, the temperature in the parking lot was edging toward 101°F. By 2:00 P. M. the lid of the dumpster started to rise. By 3:00 P.M. , grandson of the Blob was oozing out over the top of the dumpster and onto the pavement. … In the end, that 50-pound batch of dough completely filled the dumpster, and when the metal got hot enough, it baked onto the inside, making a real chore for those who had to clean it (meaning me).

He goes on to explain that throwing the dough out because he’d forgotten the salt made things worse: salt would have slowed down the fermentation in the dumpster. He concludes “So don’t forget the salt.”

Two perspectives on the design of C++

Posted on by John

Here are two complementary (but not entirely complimentary!) blog posts about C++.

Roshan James has a scathing article about C++. When asked to recommend books on C++, he replied that he doesn’t recommend C++. He explains how the best C++ books may be Scott Meyer’s series Effective C++ but argues that they should be called “Defective C++. ” He isn’t criticizing Scott Meyers, only the aspects of the C++ language that made it necessary for Scott Meyers to write such books. Effective C++ explains how to get around problems that don’t exist in more recent languages.

Bruce Eckel’s article The Positive Legacy of C++ and Java focused more on what C++ did well. C++ was designed to be backwardly compatible with C. Bjarne Stroustrup, original author  of C++, realized that the decision to be compatible with C would cause major difficulties, but he also thought (correctly) that without such compatibility no one would move over to the new language. Given this severe constraint, C++ has been remarkably well designed.

Update: Check out the C++ FQA site Alessandro Gentilini mentions in the comments. “FQA” is not a typo. It stands for Frequently Questioned Answers.