Communications of the ACM
On the Significance of Turing's Test
Credit: iStockPhoto.com
Contrary to what the first sentence of Alan Turing's 1950 paper "Computing Machinery and Intelligence" might suggest, the paper was not about the question "Can machines think?" Turing quickly rejected that question because its meaning is undefined, replacing it with a vaguely related alternative that is relatively unambiguous. He said he considered "Can machines think?" too meaningless to deserve discussion and did not claim his replacement question was, in any sense, equivalent to the original question.
Nobody interested in the so-called "Turing Test" should neglect the work of the late MIT professor Joseph Weizenbaum in the mid-1960s. Using a computer that was extremely limited in computing power by today's standards, he created a simple program called Eliza that could carry out an apparently interesting conversation with a user. Nobody who examined Eliza's code would consider the program to be "intelligent." It clearly had no information about the topic being discussed. Over the years I have met at least several people who viewed Eliza as a serious attempt to pass the so-called Turing test; some actually worked to improve it. Weizenbaum found this surprising and insisted they were wrong. He had written the program and related paper to show that passing the Turing test was trivial and that the test should not be used as a measure of intelligence.
Comments
Raju K
Box Toxen and Poul-Henning Kamp make certain viewpoints with regard to the role of funds in secure software. Can anyone generalise and formulate a theory using aberrations as examples ? I think the method deployed by Poul-Henning is wrong. While funds may contribute to secureness of software, proprietary-ness of software will effectively prevent anyone from knowing what's really going behind the scene. When patches could be effectively used to alter the functionality of a given proprietary software, how could anyone verify truthfulness of a software to a function based on mere claims? Access to software sources must be extended in order to conclusively verify absence of mischievous code. Another perspective stems from the fact that proprietary software can only be improved at the developer's place. The case with Free Software is different, as any student could pick up a sample project and go on to complete the project as part of academic work - an exercise which is normally impossible with proprietary software.
Displaying 1 comment