I once had a friend who fretted mightily about an upcoming party. She had that deer-in-the-headlights look to her — simultaneously distracted yet fixated. Upon some inquiry, I found out that the issue in question was the food: how much of it to order. She bounced around about being worried that there wouldn’t be enough food, but such and such people haven’t RSVPed, plus these other people have a tendency to bring a bunch of other folk along, plus if there were too much, what would she do with it, does that mean she’ll need to get some boxes so people can take the excess home, but then she might order too little food…
This has happened to all of us at one time or other: we are faced with a situation that has a lot of unknowns, a variety of factors to consider (sometimes contradictory), and no apparent resolution. Fortunately, we frequently don’t need to face these situations alone, and in this case, it was my turn to keep someone company.
Having (mostly) understood the problem at hand, I tried to get a few things straight. First, I asked my friend how much food would be viewed as “enough” food for the guests. She had a ready answer — for the kids at the party, she would want them to eat a certain amount; for the adults, a little bit more. Memory of precise values and items escapes me, but the answer was definite and clear, something like “1 piece of pizza for the kids, and 2 pieces of pizza plus 3 buffalo wings for the adults.”
Little did my friend know that she had almost solved half of her problem for me. I then asked how many people she expected. A little bit of the fluster bluster came back, but, once focused on just a head count and not all of the implications of such a head count, she also had a fairly ready answer — “Well, I invited 30 people, but only 20 have RSVPed, and some guests might bring others along.”
Some uncertainties there, for sure, but before I pursued the head count further, I asked my friend, “What’s more important to you — that there’s too much food left over, or that there’s too little?”
Confusion city started looming again, but once more, I found my friend actually continuing to solve more of the problem on her own. “Well,” she said, “I really want to have the right amount of food...but in the end, I wouldn’t know what to do with too many leftovers, and if the food looks like it’s getting low, I can always run out and get some easy ready-made stuff. But if I can avoid that, that would be great.”
Which returned me to head count — I asked around how many “surprise” guests might show up, and she listed the invitees who have, in the past, brought in some freeloaders — uh, crashers — uh, no, um, extra mouths to feed. For each invitee, she found that she had some idea of, at worst case, how many unsolicited additions might pop up. In the end, we had a number — by no means a surefire one, of course, but still a guesstimate that sounded reasonable.
“Now,” I concluded, “with that fair guess of how many kids and adults might show, let's just multiply that by how much food you’d like them to eat, and that’s how much you should order. If that amount goes over, then it probably won’t be way over; if it goes under, then either it won’t be too bad of a shortage, and like you said, if you were really in a bind, you can always get some more food.”
That seemed to settle things. My friend calmed down, settled on a quantity of food, and finally started to actually look forward to this party which had been causing her so much grief. There was a final, lingering doubt — “So you think that will really be enough?” — but she seemed to replay our backups and contingencies and priorities in her mind, and squashed that question once and for all.
Of course, at this point, you may be wondering, “Now where is the computer science in all of this?” Looking back, I would say that the entire food-amount-determination episode comprised the computer science. Assessing a situation, looking at its positives and negatives, specifying priorities, and finally coming up with a plan that maximized the positives while handling or accepting possible negatives, is, in some respects, precisely what computer scientists do for a living. This cycle happens all the time, particularly with algorithms: there is almost always more than one way to approach a particular computation. Each alternative has its own set of advantages and disadvantages; for many problems, there is no clear winner. When deciding how to allocate files on a disk, one may favor the simplicity of contiguous allocation but realize that frequent changes to files on disk may eventually lead to external fragmentation. Thus, other approaches that are more amenable to change (linked lists, indices) should be considered.
And yet, we must realize that the very notion of “frequent changes” is an assumption in this scenario — and sometimes, this assumption will not hold, such as with DVDs or other non-writable media. In this case, perhaps contiguous allocation’s benefits then outweigh its detriments, precisely because our needs or priorities have changed.
In another area of computer science, computer graphics, lies the search for hidden surface removal algorithms. A variety of approaches were devised and tested, each having different pluses and minuses when compared against each other. The approach that proved to be the most general, with the best performance over a wide variety of situations, was the depth- or z-buffer algorithm. It had one caveat, however: it used a lot of memory, possibly more memory than the visible graphics display itself. Depth-buffer effectively “trades off” space in exchange for time — something that happens in many algorithms.
As you may have guessed, depth-buffer may have been prohibitive at first, but as memory became cheaper and more available in larger and larger amounts, depth-buffer’s “disadvantage” was finally rendered moot. Today, kids bring around devices that use the depth-buffer.
Thus, like my friend and her food-at-a-party conundrum, computer scientists are frequently faced with unknowns and no clear-cut choices; unlike my friend, we are actually trained to tackle these situations in toto, so that we can determine not necessarily the absolute best solution, but the best solution under the current circumstances. We are trained to be explicitly aware of these circumstances, as well, because one day, those circumstances may change, and all of a sudden another alternative may become preferable.
In the end, I’m left asking, if everyone knew a little more computer science, how many “deer-in-the-headlight” situations might actually be avoided? How many people, mired in apparently insurmountable problems, might actually find a way through? While there will certainly be challenges of genuine difficulty, one wonders how things might change if more of us could “swim” with the computer scientists, and thus not drown in every problem that isn’t blatantly cut and dried.
