The most expensive function in the simulation has four integer arguments. Each time the function is called, one of the arguments is incremented by 1. A random process determines which argument is incremented each time. This function has a set of recurrence relations that make it faster to calculate a new value if you have a previously computed value for adjacent arguments.

The recurrence relation approach is about 100x faster than the memoization approach for small runs. However, the time per run with memoization decreases with each run. The longer it runs, the more values it caches, and so the greater the chances that a value has already been computed. In the end, the recurrence relation is about 2x faster than the memoization approach. With an even larger run, I suspect the time for the two approaches would be roughly equal.

The new approach is faster, but it was more work to implement, and it depends critically on the assumption that consecutive arguments differ only by one increment of one argument.

Related post:

20 weeks down to 20 minutes

The most expensive part of the simulation is a function that takes in four integer parameters and does a numerical integration. Each parameter could be any value from 0 to 120. So in principle there are 121^4 = 214,358,881 possible parameter combinations. I knew that some of these combinations were extremely unlikely or impossible, so I thought I could reduce the execution time by caching the most commonly called parameters. Maybe a few thousand arguments would account for most of the function calls.

I saved the function arguments and computed values in map, a.k.a. dictionary, associative array, etc. (The buzz word for this is memoization.) I set a maximum size on the map because I thought it could grow very large. Even if, say, a thousand arguments accounted for most of the function calls, maybe there were many more that only appeared once.

It turned out that the function was only called with 408 distinct parameter combinations. That means the same integrals were being evaluated millions of times. Caching these values reduced the execution time by a factor of about 800. In other words, the software could retrieve a previously computed value 800x faster than compute it from scratch.

The simulation that would have taken 300 hours took only 22 minutes, and so there was no need to make it run in parallel.

Update: I found a bug in my hashing algorithm. After fixing the bug, the time to run my simulations increased to 38 minutes. So my speed-up was a about a factor of 420 rather than 800, but still enough to run on one thread over lunch. The number of distinct arguments to the numerical integration was much more than 408 in the corrected program, but still small enough to cache.

Many man pages are hard to read, but I think that the grand prize for difficulty has to go to the man page for bash. As I was doing my research for this book, I gave it a careful review to ensure that I was covering most of its topics. When printed, it’s over 80 pages long and extremely dense, and its structure makes absolutely no sense to a new user.

On the other hand, it is very accurate and concise, as well as being extremely complete. So check it out if you dare, and look forward to the day when you can read it and it all makes sense.

* If you’re not familiar with Unix lingo, “man” stands for “manual”. Man pages are online documentation.

Related post:

Review of The Linux Command Line

True to its name, the book is about using Linux from command line. It’s not an encyclopedia of Linux. It doesn’t explain how to install Linux, doesn’t go into system APIs, and says little about how to administer Linux. At the same time, the book is broader than just a book on bash. It’s about how to “live” at the command line.

The introduction explains the intended audience.

This book is for Linux users who have migrated from other platforms. Most likely you are a “power user” of some version of Microsoft Windows.

The book has a conversational style, explaining the motivation behind ways of working as well as providing technical detail. It includes small but very useful suggestions along the way, the kinds of tips you’d pick up from a friend but might not find in a book.

The book has four parts

1. Learning the shell
2. Configuration and the environment
3. Common tasks and essential tools
4. Writing shell scripts

The book could have just included the first three sections; the forth part is a bit more specialized than the others. If you’d prefer, think of the book has having three parts, plus a lengthy appendix on shell scripting.

The Linux Command Line is pleasant to read. It has a light tone, while also getting down to business.

Related post:

Perverse hipster desire for retro-computing

Beginning algebra students rush to enter numbers into a calculator. They find it comforting to reduce expressions to floating point numbers as frequently as possible. This is understandable, but it’s a habit they need to break for numerous reasons: it’s more work, harder for a grader to follow, less accurate, etc. Better to do as much calculation as possible with symbols, then stick in numbers at the end.

A similar phenomena happens in scientific programming. We’re anxious to see numbers, so we print out numbers as soon as we produce them. There’s a tendency to sprinkle code with printf statements, then write scripts to scrape text output to gather results.

It’s better to keep numbers in data structures as long as possible, then dump the data to text as the last step. Why? For one thing, the output format might change: instead of a text dump, maybe you’ll want to put the data in a database or format it as an HTML table. More importantly, the “last step” will often change. What was the last step now becomes the next-to-last step because you think of something else to do. So you do more with the data in memory before producing output, rather than scraping the text output.

I quickly learned to delay plugging numbers into algebraic expressions. It took me longer to learn not to output numeric results until the last moment.

C#’s double.Epsilon is the closest floating point number to 0. C’s DBL_EPSILON is the distance between 1 and the closest floating point number greater than 1. Said another way, DBL_EPSILON is the smallest positive floating point number x such that 1 + x != 1, often called “machine epsilon.”

Typically double.Epsilon is on the order of 10^-324 and DBL_EPSILON is on the order of 10^-16. (These values could potentially change depending on the platform, but they hardly ever do.)

C# has no constant corresponding to DBL_EPSILON. This is unfortunate, since this constant appears frequently in numerical software. Why? Because it tells you, for example, when to stop adding series.

If DBL_EPSILON is on the order of 10^-16, that means that if you add two numbers that differ by more than 16 orders of magnitude, the sum doesn’t change. If you’re summing a decreasing series of numbers, say in order to evaluate a Taylor approximation, you might as well stop once the next term is 16 orders of magnitude smaller than the sum. If you keep going past that point, you’ll burn CPU cycles but you won’t change your answer.

DBL_EPSILON is almost always about 10^-16. But by giving it a name, you avoid having 10^-16 as a mysterious constant throughout code. And if your code should ever move to an environment with different floating point resolution, your code will correctly adjust to the new platform.

Related links:

An introduction to numerical programming in C#
Anatomy of a floating point number

Someone might object that Rob Pike’s observation is irrelevant. Everything is fast when the problem size n is small, so design your code to be efficient for large n and don’t worry about small n. But it’s not that simple.

Suppose you have two sorting algorithms, Simple Sort and Fancy Sort. Simple Sort is more efficient for lists with less than 50 element and Fancy Sort is more efficient for lists with more than 50 elements.

You could say that Fancy Sort scales better. What if n is a billion? Fancy Sort could be a lot faster.

But there’s another way a problem could scale. Instead of sorting longer lists, you could sort more lists. What if you have a billion lists of size 40 to sort?

People toss around the term “scaling,” assuming everyone has the same notion of scaling. But projects could scale along different dimensions. Whether Simple Sort or Fancy Sort scales better depends on how the problem scales.

The sorting example just has two dimensions: the length of each list and the number of lists. Software trade-offs are often much more complex. The more dimensions a problem has, the more opportunities there are for competing solutions to each claim that it scales better.

Related posts:

• Appropriate scale
• Scaling the number of projects
• Stupidity scales

Three orders of magnitude in machine speed and three orders of magnitude in algorithmic speed add up to six orders of magnitude in solving power. A model that might have taken a year to solve 10 years ago can now solve in less than 30 seconds.

Source: In Pursuit of the Traveling Salesman

Related post:

A brief note on Moore’s law

In Emacs, text is just text, no matter where you see it. This means that Emacs is less visually interesting because there is less variety. But this also has several advantages that may not be immediately obvious. I’ll give a couple examples.

The Emacs directory editor dired lists files in a text buffer. The output is essentially the output of ls. (On Windows, Emacs emulates ls.) That means you can do anything to the output you could do to text: copy, paste, search, etc. No text is off-limits. And in editable mode, you can rename files just by editing their names. You could, for example, rename many files at once using regular expressions.

Dired also lets you navigate the file system with the same commands you use to edit files. In particular, you can keep your hands on the keyboard. (It’s possible to use the Windows file explorer without a mouse, but it’s limited and awkward.)

Another advantage of everything simply being text is that you can run a shell inside Emacs. Why not? A shell is just text output. In an ordinary shell, editing commands are mostly limited to the current line. Not all text is created equal. But when you’re running a shell inside an editor, all text is equal: current line, previous lines, and text on either side of the command prompt. And if you want a transcript of a shell session, just save the buffer displaying the session.

If you’re shopping for a text editor and spend an hour trying each one out, Emacs may not look very promising. It has odd terminology, weird key strokes, etc. But if you try Emacs long enough, and particularly if you have someone to help you get started, you start to appreciate the advantages of subtle features such as everything simply being a text buffer.

Related posts:

The importance of being textual
Mental context switches are evil
Personal organization software

I find it interesting that Justice Souter would have such independence of mind that he chooses not to use much of the technology that our world takes for granted. He made it to the top of his profession and had a job for life, so he could afford to be eccentric. But he wasn’t born on the Supreme Court. I would like to know whether his low-tech work habits developed before or after his legal success.

I imagine most readers of this blog could more easily relate to Donald Knuth than David Souter. Knuth obviously doesn’t reject technology, but he is selective in how he uses it.

I had the opportunity to see Knuth speak while I was in college. Much to my surprise, his slides were handwritten. The author of TeX didn’t see the need to use TeX for his slides. While he cares about the fine details of how math looks in print, he apparently didn’t feel it was worth the effort to typeset his notes for an informal presentation.

In 1990 Knuth decided to stop using email.

I’d used email since about 1975, and it seems to me that 15 years of email is plenty for one lifetime. Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things.

I believe I’ve read that Knuth does most of his work on a Linux box with no network connection. He also has a Mac for creating graphics and using the Internet. He has a secretary to handle his correspondence, including email.

If you’re reading legal briefs by sunlight, your thoughts will not be exactly the same as they would be if you were reading by fluorescent light. If you’re writing a presentation by hand, you’re not going to think the same way you would if you were pecking on a computer keyboard. And if you do use a computer, your thinking is subtlety different depending on what program you use. Technology affects the way you think. The effect is not uniformly better or worse, but it is certainly real.

Related posts:

Create offline, analyze online
Tim Bray’s high-tech monastic cell
Living within chosen limits

I have about a week’s worth of sed and awk tips scheduled. Then I’ll start adding in tips on grep, find, uniq, etc. And I’ll come back to sed and awk now and then.

These tools came from the Unix world, but they’re also available on Windows.

For now I’m keeping the original icon. I’m open to suggestions if someone has an idea for a better icon.

Related posts:

Thermonuclear word processor
Retro computing

I’ll probably change the name of the account to reflect the new content. I’ll cycle back to sed and awk tips now and then.

Update: I’ve renamed SedAwkTip to UnixToolTip.

The applications I plan to go into ship as part of Linux and OS X, and they’re available for Windows here.

Other daily tip Twitter accounts:

Computing:

• CompSciFact
• SciPyTip
• SansMouse
• TeXtip
• RegexTip

Math:

• AlgebraFact
• ProbFact
• AnalysisFact
• TopologyFact
• StatFact

A pro-Microsoft explanation would say that Microsoft is more progressive, always improving their APIs and tools, and that Unix is stagnant.

A pro-Unix explanation would say that Unix got a lot of things right the first time, that it is more stable, and that Microsoft’s technology turn-over is more churn than progress.

Pick your explanation. But for better or worse, change comes slower on the Unix side. And when it comes, it’s less disruptive.

At least that’s how it seems to me. Although I’ve used Windows and Unix, I’ve done different kinds of work on the two platforms. Maybe the pace of change relates more to the task than the operating system. Also, I have more experience with Windows and so perhaps I’m more aware of the changes there. But most of the things I knew about Unix 20 years ago are still useful, and most the things I knew about Windows 10 years ago are not.

Related posts:

Programmers without computers
Where the Unix philosophy breaks down
Software development and the myth of progress

Exponential growth doesn’t mesh well with human intuition. Scott Berkun said “Technological progress is overestimated in the short term, underestimated in the long term.” This is probably not limited to technology but true of exponential growth in general.

(Why are the two statements of Moore’s law equivalent? The first says performance grows like exp( log(2) t / 1.5 ) and the second says it grows like exp( log(100) t / 10 ). And log(2) / 1.5 = 0.462 and log(100)/10 = 0.461.)

Related post:

Moore’s law and software bloat

Traveling to areas most in need of relief is arduous. You may, for example, have two or three days of travel by land or water after your airplane lands. So naturally you want to do as much system administration remotely as you can.

In general you can’t expect broadband in the poorest areas, though there are some surprises. You often have to rely on satellite connections, though these are slow, unreliable, and expensive. Dial-up is preferable, if you can get it. Bandwidth may be adequate for command line access, though even then the latency is annoying. Video conferencing (e.g. for showing someone how to do something) is out of the question. So remote locations need to be mostly self-sufficient.

To read more about Food for the Hungry and their computing environment, see Why Food for the Hungry runs Ubuntu.

I also don’t do this [work from the command line] out of some perverse hipster desire for retro-computing. I have work to do. If my system didn’t work, I’d abandon it tomorrow.

That’s refreshing. Some of the more ardent command line advocates give the impression that they use the command line out of pride rather than out of a desire to get work done. Ramsay is recommending his way of working, not bragging about what he’s able to do. He has some interesting ideas, especially in his follow-up article The Mythical Man-Finger.

By the way, I’m no command line wizard; I’m a fairly typical computer user. On the other hand, my use of the command line and Emacs has been increasing.

Related posts:

Confusing familiar with simple
Superficial convenience

I mentioned on Twitter this evening that it would be nice if Windows had this feature. Apparently many newer Windows laptops come with this capability.  Todd Brooks replied that my laptop might be able to the two-finger scroll if I upgraded my touchpad driver. He was right. I went to the Microsoft Update site and saw that one of the optional updates was exactly what Todd suggested I install.

So far it seems that the two-finger scrolling on my ThinkPad isn’t as smooth as it is on a MacBook Pro, but it’s still nice to have.

Computer manufacturers of the 1960’s estimated that more than 25 percent of the running time of their computers was spent on sorting, when all their customers were taken into account. In fact, there were many installations in which the task of sorting was responsible for more than half of the computing time. From these statistics we may conclude that either

1. there are many important applications of sorting, or
2. many people sort when they shouldn’t, or
3. inefficient sorting algorithms have been in common use.

Computing has changed since the 1960’s, but not so much that sorting has gone from being extraordinarily important to unimportant.

… starting from clearly abstract structures and building something real from the abstract rather than abstracting something from the real. … You have models that you can then apply to the world rather than models you took from the world.

Stephen Wolfram has an analogous idea about computer programs. Until now we have written programs to solve specific problems. Wolfram suggests we reverse this and explore the space of all possible computer programs. As he demonstrates in his magnum opus, simple programs can have surprisingly complex behavior. We may be able to find some relatively small but useful programs that way.

As Edmund Harriss alludes, people have successfully applied very abstract mathematics, mathematics developed with no physical application in mind, to physical problems. I’m more skeptical of Stephen Wolfram’s proposal.

Suppose you find a program that appears to solve some problem, such as optimally controlling a nuclear reactor. How do you really know what it does? You didn’t write it; you found it. It wasn’t designed to solve the problem; you discovered that it (apparently) solves the problem. Wolfram is optimistic that we could discover programs that we might never be able to write. But a program that powerful would likely also be impossible to thoroughly understand.When Wolfram says “Look what interesting behavior tiny programs can have!” I think “Look how hard it can be to understand arbitrary programs even when they’re small!”

Computer science might not be that helpful in determining what a found program does. It is theoretically impossible to write a program that can always determine whether another program stops. We would have to study the program empirically. This process would be more like squeezing an extract from some plant root and testing its medicinal properties than designing drugs.

Related post:

What does this code do?

We talk about proprietary vendor lock-in, but in many cases the reality is that anyone who uses any platform, even an open source one, ends up being locked-in to some extent. Switching is something you just can’t contemplate after a while.

I love software, but software always under-represents reality. Reality has this depth to it and potential for surprise and subtlety that you just can’t get from software.

Related posts:

The bipolar Internet
Underwhelmed with progress
Make something and sell it

Microsoft added the ribbon toolbar to Office 2007 to make it easier to discover new features. Before that release, 90% of the feature requests the Office team received were for features that Office already supported. The functionality was there, but users couldn’t discover it.

According to this report, the ribbon has been remarkably successful.

Data is showing that the redesign of Office really did reach this goal — Word 2007 and Excel 2007 users are now using four times as many features as they used in previous versions, and for PowerPoint, the increase in feature use is a factor of five.

Power users often dislike the ribbon, but most of the estimated half billion people who use Microsoft Office are not power users.

(By the way, you can collapse the ribbon with Control-F1. The ribbon will reappear when you click on a menu. On a small screen, say on a netbook, this could greatly increase your vertical real estate.)

In some ways Emacs may be the exact opposite of Microsoft Word. It has an enormous number of features, and yet it doesn’t feel cluttered. The downside is that discoverability in Emacs is pretty bad. The best way to discover Emacs features is to read the documentation. There are ways to discover features while using Emacs, but you have to be fairly deep into Emacs before you learn how to learn more.

Can you increase discoverability without adding clutter? Maybe if your design is not very good to begin with. But after some refinement it seems inevitable that you’ll have to decide whether you’re willing to increase clutter in order to increase discoverability.

One suggested compromise is to have interfaces adapt over time. Applications could start out with voluminous menus when discoverability is most important, then hide uncommonly used options over time, reducing clutter as users gain experience. Microsoft tried that approach in Office 2003 without much success. It sounded like a good idea, but changing menus scared novice users and annoyed advanced users.

A variation on this approach is to make controls visible based on context rather than based on frequency of use. People find this easier to understand.

The trade-off between discoverability and clutter may be a question of where you want your clutter, in the UI or in external documentation. I suppose I’d prefer the clutter in the UI for software I use rarely and in the documentation for software I use the most.

Related posts:

Is helpful software really helpful?
Good user interface design: EpiPen
Bad user interface design: hotel showers

Here’s the passage that brought the bumblebee story to mind.

Almost every software engineering principle that has become generally accepted as useful and valuable, Emacs flouts. The code is 24 years old, huge, and written by hundreds of different people. By rights, the whole thing should blow up. But it works — and works rather well.

This comes from Jim Blandy’s chapter in Beautiful Architecture. Blandy explains that Emacs’ architecture has allowed it to thrive despite some apparent disadvantages. Emacs is mostly written in its own programming language, Emacs Lisp.

Emacs Lisp has no object system, it’s module system is just a naming convention, all the fundamental text editing operations use implicit global arguments, and even local variables aren’t quite local.

In short, Emacs expects developers to be self-disciplined and does not enforce a great deal of external discipline. However, because the software is so light on bureaucracy, it is easy to customize and to contribute to.

TeX is another bumblebee project. Like Emacs, it has thrived for decades without following currently fashionable software techniques. Knuth implies in this presentation that TeX would have been a dismal failure if it had used technologies that are trendy now.

Related posts:

Serious lessons from Knuth’s joke
Giving Emacs another try

superficial convenience at the expense of real freedom

This comes from the conclusion of the 1998 essay The Elements of Style: UNIX as Literature by Thomas Scoville. The author sums up his preference for UNIX culture by saying he prefers the “freedom and responsibility that UNIX allows” to the “superficial convenience” of Windows NT.

I’m not interested in arguing here the relative merits of Unix and Windows. I’m more interested in broader ideas that spin off from the quote above. When is a convenience superficial? How well does convenience versus freedom explain technological controversies?

I could see substituting “short-term convenience” for “superficial convenience” and substituting “long-term efficiency” for “real freedom.” But that may lose something. Thomas Scoville’s terms may be more nuanced than my substitutions.

Related posts:

Is helpful software really helpful?
Ford-Chevy arguments
Would you rather have a chauffeur or a Ferrari?

Ethiopian farmer Ato Admasu. Photo credit Food for the Hungry.

John: Tell me a little about Food for the Hungry and what you do there.

Rick: Food for the Hungry is a Christian relief and development organization. We go in to relief situations — maybe there has been a natural disaster or war — and provide life-sustaining needs: food, shelter, whatever the need may be.  For example, the recent earthquake in Haiti. But the other part of what we do is the sustained, long-term development on the community level. The idea is to work with leaders and churches to better take care of themselves rather than relying on outside organizations for support.

I’m the CIO. I’m in charge of the information and technology for the organization. We’re in 25 countries. I have staff all over the world, about 25 people. There are about 12 who work directly for global IT, mostly in Phoenix, and the rest in various countries.  There are also people who work directly for local offices, for example in Kenya, that coordinate with global IT. We’re responsible for about 900 computers.

John: You and I were talking the other day about your organization’s project to move all its computers over to Ubuntu.

Rick: We started an informal process to convert to Ubuntu two and a half years ago. It started when my son went to Bangladesh. He spent the summer there and converted some of their computers to Ubuntu. At first we didn’t have full management support for the process. They don’t really understand it and it scares them.

There were individual country directors interested in the project and I talked it up. There’s some independence in the organization to make those kind of decisions. Now, for the first time, we have full support of management for the conversion on a wide scale. I’m going to Cambodia next week. Right now they’re all running Windows but before I leave they’ll be running Ubuntu. In Asia we probably have about 80% of our computers on Ubuntu. We don’t have big offices in Asia. Our bigger offices are in Africa and they’re a little slower to adopt. Until now, a lot of it depended on whether the local country director was ready to change.

We found it was important for a number of reasons. One is security. Linux is not as vulnerable to viruses. We have so many places where entire computer systems have been totally crippled because of viruses. A lot of networks are very primitive, so the network is basically a thumb drive between offices in a country. A thumb drive is the best way to transmit viruses you can find.

We’ve also found in the last few years anti-virus software has become less and less effective. Three or four years ago, if you had up-to-date anti-virus software you wouldn’t get a virus. These days, you still get them. Some of our staff have other jobs within FH besides their IT responsibilities and may not have a lot of IT experience. As a result, staff often do not have the time to pro-actively manage IT.

Another issue is maintainability. Windows computers don’t run as well over time. With Ubuntu, when we come back to a computer two years later it’s in as good a shape as we left it.

Linux requires much less hardware to run than Windows. We have eight- or nine-year-old computers at a lot of our sites that will no longer run or barely run Windows.

John: So saving money on software licenses is a benefit, but not the main consideration.

Rick: Saving money on licenses is important, but it’s not the driving force. We’re a non-profit and we have a contract with Microsoft where we get pretty good prices.

Another reason for moving to Ubuntu is that in some countries it is very difficult to legally obtain licenses. Sometimes it’s next to impossible. You can’t buy legal Microsoft licenses in some places, or if you can, the price is outrageous. So many legalities and so many weird hoops you have to jump through.

As a Christian organization we need to set a good example and make sure all our licenses are legal. We want to be clear and up-front about our software. Ubuntu eliminates that problem.

John: What experience have you had retraining your IT people to support Linux?

Rick: We have IT professionals and we have people who are much less skilled. Most of the IT people who do the support have really bought into it. They’re excited about it and they’re pushing it. Those who do support in the field who have had less exposure, some of them have bought into it, some have not as much. It requires time. It requires dedication. It also required commitment from their management.

Related posts:

Robust, scalable, and the keyboard works
Free Ubuntu Linux book
Geek fatigue
New spin on The Cathedral and the Bazaar

Toward the end of the talk, around 55 minutes in, Raskin compares Mac and Windows.

The Mac has gotten harder to use over the years. In fact, Windows has gotten easier. Now I can move back and forth, I can hardly notice the difference. Mac is just epsilon easier to use.

Raskin complains that software bloat has outpaced Moore’s Law, a contention that was verified here.

Jef Raskin. Photo by his son Aza.

Related posts:

Moore’s Law and software bloat
Inside Steve Jobs’ Brain

The Internet …  was influenced in equal degrees by 1960s romanticism and cold war paranoia. It aligned the two poles of the bit to these two archetypal dramas.

Lanier argues that the Internet is polarizing. Just as bits are either on or off, the Internet encourages all-or-nothing options. With regard to privacy in particular, Lanier says that you can be totally anonymous or totally open, but it’s difficult to be anywhere in between.

Douglas Rushkoff makes a similar argument in Chapter 3 of his book Program or Be Programmed. Rushkoff argues that because computers ultimately work with 0’s and 1’s, the Internet inevitably forces people into yes-no decisions.

Lanier and Rushkoff have valid points, but I have a couple reservations.

First, I don’t see why the emergent properties of the Internet should be binary just because the underlying technology is binary. For example, I don’t imagine the Internet would be much different if computers were built on electronic components with three possible states rather than two. But I would concede that binary technology makes a good metaphor for discussing the binary choices one must often make on the Internet.

Second, I’d say that modern life forces us into discrete decisions, but this is much older than the Internet. Mass production requires limited options. If a cobbler is going to make a pair of shoes for me, he can measure my feet. But if I’m going to buy a pair of shoes from a store, I have to pick a size. Also, bureaucracies require information to fit into forms, though that was true of paper forms before the advent of electronic forms. Perhaps the Internet accentuates the need to make discrete decisions, though I’m not convinced.

Related posts:

The buck stops with the programmer
Underwhelmed with progress

In some ways I think that scientists have misled themselves into thinking that if you collect enormous amounts of data you are bound to get the right answer. You are not bound to get the right answer unless you are enormously smart. You can narrow down your questions; but enormous data sets often consist of enormous numbers of small sets of data, none of which by themselves are enough to solve the thing you are interested in, and they fit together in some complicated way.

Bradley Efron, quoted in Significance. Emphasis added.

Related posts:

Predicting height from genes
The data may not contain the answer