The movie I, Robot shows how robots, controlled by positronic brains, try to take control in a futuristic society. The movie, as compelling as the Isaac Asimov short stories upon which it is based, drew its inspiration from technology that dates back to 1940. This was fortunate for Asimov, whose intelligent robots make much more sense being driven by a vague positronic brain than by a real-world computer.
The intelligent computer became a hot topic in the 1960s and 1970s. Yet, once the most optimistic prophets had lived to see their “in twenty-five years” predictions of an intelligent computer fail to materialize, its few remaining advocates pushed their forecasts several hundred years into the future.
These prophets also changed their predictions regarding computer intelligence, moderating their statements to fit parameters such as “applications that would have needed intelligence if humans were doing the job.” But that is something quite different. The Vikings, for example, navigated by using the sun, moon, stars, and wind direction. Even bird flight and floating seaweed could aid an intelligent or creative navigator.
Today, we also use stars for navigating, but they are artificial stars, satellites , that send a radio beacon any GPS system can use to pinpoint its position on the surface of the earth with an accuracy of a few meters. Such devices do a better job navigating—just by computing a simple function—than the Vikings did, and with no intelligence required.
Some intelligent functions have, nevertheless, been embedded in the standard software we use today. For example,
MS Word can detect typos and replace these automatically with the right word. Excel offers an autocomplete function that will automatically suggest the rest of the data from what has already been typed. Mail systems can alert users immediately when messages arrive, popping them up onscreen. MS Windows will tell users when their desktop has become cluttered with unused icons and help get rid of them. Software can update itself automatically as well, an important function in these virus-ridden times.
Early prophets of intelligent computing would be disappointed by these mundane implementations of their dreams, but even these relatively simple smart functions do not work unfailingly. For example, the autocorrect function in Word causes problems, especially outside the US. In Norway the preposition “i” (meaning in) is often erroneously capitalized to an “I.” Newer versions of the software have a language-dependent autocorrect function and will only perform the latter in English text. Still, the menu in my favorite Chinese restaurant has all instances of the letter I capitalized, probably because the system perceived the text as English.
Recently, while typing in student grades in Excel, I assigned a C+ to one student and a C to three others. Looking up from my notes, I noticed that all had received a C+: The autocomplete function had suggested the C+ text after each C and used the enter key as a confirmation, not as a jump to the next line as I had intended.
When I use my laptop during presentations and have the desktop up on the big screen, Windows might send silly messages to the audience, such as the note inviting me to rid the desktop of unused icons. These annoyances are minor compared to what could happen. Recently, while attending a conference with several hundred others, a mail message

popped up on the big screen. Luckily, it was an innocent message from the speaker’s wife. We all know it could have been much worse.
The problem is context . As humans, we usually have some sense of the semantics, the overall idea behind what is happening. We do not interrupt a speaker with casual remarks. We understand when someone is fully engaged and try not to interfere. When proofreading, we base our marks on an idea of what the writer seeks to express. But the automated spellcheckers, autocomplete functions, and automatic suggestions all work on a lexical level, without any idea of either the overall context or the semantics.
Different methods can add context to automatic systems. But these can be data-intensive, and not always practical.
The process of maintaining the correct temperature at home during winter provides a good example. An on/off button on the furnace is the simplest mechanism, but by adding a thermostat we can avoid letting the room get too hot. We can add a timer and operate with a lower night temperature to save energy. But this system might freeze a guest if, for example, that person stays too late on a Saturday night. We can work around this by adding a sensor that keeps the furnace on if it detects movement in the room, but we might then end up using a lot of energy to keep the room heated for the cat.
By adding more equipment, even systems that allow remote control of the temperature, we might get a good balance between comfortable temperature and acceptable energy bills, but even then we must provide data for both standard and exceptional situations.
Sometimes, we get context for free. Years ago, I had to go down the hallway to ask my US-born colleague if the correct phrase was “in the West coast,” “on the West coast,” or “at the West coast.” Today, I ask Google. It will give me 590,000 hits for the first, 10,200,000 for the second, and 188,000 for the last. An extremely useful function, especially while writing in a second language and striving to follow the norm. We can also use Google itself as an example. Their scheme for presenting search results offers a practical implementation of importance .
Letting a system use context has the drawback of making the outcome less deterministic for the average user. We might wonder why it is so cold in the house while forgetting that we came home earlier than expected. Perhaps we could send a message to the heating system telling it about our change of plans, but is that really how we want to shape our future? I see a situation in which the heating system warns us that if we get home that early, it will not be able to heat the house adequately, or our automatic refrigerator advises us not to go out for dinner because it has already planned a home meal for us.
I feel we are nearly at the point where Windows tries to restart after an update. Yes, it is smart to activate updates, but not when we are trying to get everything ready for an imminent deadline. So, we irritably hit the restart later button, only to have our dumb assistant popping up 10 minutes later with the same message. It reminds me of my kids asking for ice cream on a sunny day. However, with Windows (not with the kids) it is possible to set the repetition time, but it’s complicated, requiring knowledge few users have access to.
Can we view the restart later message as an indication the computer is staging a coup? Certainly—if we’ve succumbed to paranoia. Yet modern software and hardware try to take control in many cases, from requiring updates to suggesting actions. Although the idea is to aid the user, often the effect is just the opposite. Even systems to prevent errors can fail if they don’t handle context correctly.
Yes, it was nice to get a warning that the metro ticket machine did not give change, but utterly frustrating when it refused to sell me a ticket for my 10-euro bill. I was more than willing to waive the two euro change to get on the train so that I could catch my international flight. Modern printers have similar problems. Once it was possible to coach a sick printer along to get a needed hardcopy, but today a much “smarter” device refuses to go on if it detects an error.
Formalization relates strongly to context. We must formalize the application in a way that covers all circumstances.
Spam filters offer a good example. An oft-used method discriminates spam from genuine messages by looking at the words in the message—for example, by differentiating on a lexical level. This simple formalization works in most cases, but the difference between a semantic and lexical level causes the filters to let some spam through. On the other hand, these filters also remove some genuine messages. Developers have attempted to use similar methods when screening pornographic content, both in text and pictures, but here the formalization problems are even greater.
Those of us who have followed the Great Robot Race (www.pbs.org/wgbh/nova/darpa/) have been impressed by how computers can steer cars through the Mojave Desert using GPS, 3D mapping systems, laser guidance, and video cameras. The vehicles follow dirt roads, avoid obstacles, go through tunnels, navigate narrow corners, and pass other cars as if they were controlled by a human driver.

Does this imply that we will have automatic cars on the road in a few years? The central issue here is not how much intelligence we can build into the cars, but how we can formalize driving. Although driving can be relaxing at times— letting us listen to music, look at the countryside, and have a conversation—some situations demand we use all our sensory organs and brain capacity to make the right decisions. For example, we might unexpectedly see something on the road ahead. Must we brake and veer, or can we just continue going forward?
If a robot must make these decisions, the tasks must be formalized. For example, the decision program will need to distinguish between a rock (brake or veer), a small snowdrift (go ahead), or a cardboard box (empty: go ahead; full: brake or veer). It must be able to interpret the intentions of fellow drivers as well.
Clearly, the other alternative—to formalize the road to a higher level, seems more promising. This can be done by putting virtual rails in the road, physical cables that gadgets in the cars can follow. Alternatively, we could use detailed
GPS waypoints to determine the route, as in the Great Robot Race. The system can use laser-guided vision, sensors, and video cameras to control the distance to nearby cars. Such an automatic system could reduce the driver’s workload, but exceptions would still pose problems.
The examples we have today of computer-controlled trains illustrate the formalization issue. These trains run in an environment where exceptions are reduced to a minimum by, for example, building systems that make it impossible for people to gain access to the tracks. We should be able to find similar applications for robot trucks that can run on enclosed company roads.
In the end, we see that computer “intelligence” is really a matter of formalization: how we can formalize tasks and context. GPS navigation, the telephone, IP addressing, credit card payments, account numbers, and bar codes offer some success stories. Robots already perform many tasks in industry, and they now drive forklifts, trains, and experimental trucks.
Automatic vacuum cleaners and lawn movers have been on the market for several years, proving that robots have an application wherever physical output is needed. They might also be given the intelligence to perform choices within limited worlds, where the context is formalized and well-defined.
T he Turing test provides the ultimate challenge for intelligent systems: Is it possible to make a computer system that can answer questions as convincingly and spontaneously as a human would? This test is not about thinking and intelligence, it is about formalization. Type in some stories and let the machine and the human classify these as dull, sad, or humorous. We will have an intelligent machine the day the robot can laugh in the right places. n
Kai A. Olsen is a professor at Molde College and the University of Bergen, and an adjunct professor at the University of Pittsburgh. Contact him at Kai.Olsen@hiMolde.no.
Editor: Neville Holmes, School of Computing, University of Tasmania; neville.holmes@utas.edu.au. Links to further material are at www.comp.utas.edu.au/users/nholmes/prfsn.