Author Archive for Josh Hieronymus

Pitfalls in the A.I. Debate

Many times, when two people disagree about something, I’m inclined to side with one of them. In the AI debate between Searle and Brooks, however, I don’t like either side. I agree with Searle that a computer would not be thinking by virtue of passing the Turing test, and I agree with Brooks that Searle does not provide a satisfactory account of what thinking is or of what it requires. Still, I think that they both miss the point on key issues. Brooks thinks that Searle’s Chinese Room example breaks is flawed in part because the system (i.e., Searle and his book of rules) would run too slowly to mirror the actual computing power necessary to mirror certain computational processes. This objection doesn’t get him anywhere, though, because Searle’s claim is that it would not matter how fast he moves, as he would still not understand Chinese even if he could carry out the computation quickly. Searle, for his part, fails to explain why simulations of neural activity could not suffice for creating semantic content.

After the discussion in class, I’ve become more convinced that questions such as “Is AI possible?” are too vague to without determining what these terms mean. The problem with trying to define these terms, though, is that people’s views about what certain words should mean conflict much, particularly because there is a lot riding on how we use terms. For example, suppose that a computer program were able to pass the Turing test. If we admit that the computer running the program is thinking, then perhaps it follows that it is alive (think Descartes’ cogito ergo sum). Does that mean that turning off the computer is the same thing as killing it? Our intuitions about the answer to these questions that invariably arise prejudice us concerning how we want to use these terms.

So, I have three answers to the question “Is AI possible?” that depend on what AI means. If AI is simply the ability to solve complex problems or perform complex tasks such as playing chess, then AI is certainly possible. If AI is the ability to fool humans that the subject is a computer program, then perhaps AI is possible. If AI has as a necessary component that the subject is alive and has the same moral standing as a person, then AI is not possible.

When You Come to a PLOrk in the Road, Take It (with Apologies to Yogi Berra)

I attended the Princeton Laptop Orchestra concert this past Tuesday, not exactly knowing what to expect. I had researched a little bit about Pauline Oliveros and Zakir Hussain beforehand, but I didn’t get a chance to sample any of their work. The program didn’t help me that much either, as some of the song descriptions were vague, while others used terms that I didn’t understand.

When the lights went down and the performance began, I was surprised by the sounds that I heard. To be more accurate, perhaps, it might be better to say that I was not surprised by the sounds that I heard. I had been expecting to hear a variety of unfamiliar tones, but it mostly sounded like experimental electronic music that I had already heard before. Perhaps if you hear one sine wave, you’ve heard ‘em all. The rhythms were a bit more intriguing, particularly during the last piece when Zakir Hussain was working the tabla, but nothing seemed particularly new to me.

What did capture my interest, though, was the diverse assortment of ingenious interfaces that the musicians used. In the first piece, the conductor and several of the players wore gloves that contained accelerometers, which would allow them to manipulate the music by moving their hands. Another piece had the musicians playing a slot-machine-type game, in which each musician had a number of virtual tokens, and the sound changed as they ran out of tokens. The most fascinating interface was the “Printer Controlled Conductor” in another piece, in which the conductor would hold up directions to the orchestra as a computer program printed them out, which left me with a number of questions as to how one might construct a fully-automated conductor.

From a Deductive System of Reasoning to Computing

Suppose that you wanted to know what I will be having for lunch, and that you know that I always have either a turkey sandwich or pizza, that I have run out of bread, and that I’m unable to buy any more. Given this information, you can probably deduce that I must be having pizza. This sort of problem, which has well-defined, unambiguous premises and solutions, can be solved rather easily by using Boolean logic. Not all problems fit this bill, however. A number of people have tried to use Boolean logic to make controversial claims, such as to prove that God does (or doesn’t) exist, but the premises that they use are often unclear or just as controversial as the claims themselves. Other difficulties arise when trying to use Boolean logic to handle self-referential statements. For instance, the statement “This sentence is false,” cannot be determined to be either true or false by using Boolean logic (not straightforwardly, at least).

Boolean logic forms the basis of modern computing. Computer chips employ numerous tiny structures known as logic gates, which take high and low voltages as inputs and return high and low voltages as outputs. They mimic the functions of Boolean logic, and the various gates are given names such as “AND,” “OR,” and “NOT.” An “AND” gate, for instance, outputs a high voltage if both of its inputs are high voltages, and outputs a low voltage otherwise. The ability to use these gates billions of times per second is what makes computers able to make swift calculations.

Pseudocode, the C-3PO of Algorithm Languages, Only Not As Whiny

C-3PO was clunky, tried to run away at the smallest hint of danger, and complained all of the time. He did, however, serve well as a translator, since he was “fluent in over six million forms of communication.”

Likewise, pseudocode enables the user to write out an algorithm without requiring him to know any specific programming language. After writing out the program in pseudocode, the programmer can proceed to implement it into a variety of different programming languages, such as C++, Java, Perl, BASIC, or Ruby. This is usually easier than writing a program in one of these languages and trying to directly transform it into another.

The reason that pseudocode is so easy to use and so versatile is that it is just describing the algorithm in non-language-specific, high-level terms. Commands in one language are not the same as commands in another, and syntax greatly varies from language to language as well. Plus, pseudocode can be as specific or as unspecific as the programmer wants. Say, for example, the programmer wants to write a program in which a list of names will be alphabetized as one of the steps. He can write alphabetize list of names to indicate that the algorithm will include alphabetizing the list of names. Suppose that he finishes planning out the rest of the program and he wants to work on the algorithm for sorting this list of n names. He can change his pseudocode to reflect this change, with lines such as Do for i = 1 to n - 1 to show that he needs to run a loop and store names[j+1] to names[j] to show that he wants to switch the place of two names in a list.

There are some problems associated with pseudocode, though. First, it may take longer to write a particular program in pseudocode before writing it in the language in which it is ultimately to be programmed. Second, pseudocode is not standard, which means that one person’s pseudocode may not be understood by another person. Third, sometimes the need for writing pseudocode can be removed by adding non-executable comments to a program that aid in reminding the programmer what a particular block of code is supposed to do.

Back Home, “Corn Rows” Are Something Entirely Different

Hi everyone,

I’m Josh Hieronymus, a junior in the Philosophy Department. I used to live in Forbes, and now I’m in Spelman as an independent. My hometown is Atlanta, IL, which has a population of about 1500, and yes, I did grow up on a farm. I got into computers at a young age, starting on my parents’ old Apple IIe. Computer science and programming remain two of my hobbies, and I also enjoy reading, singing, theologizing, Hacky Sack (or, more properly, footbagging), playing Scrabble, losing at chess, and philosophizing. I’m starting to get into cooking, but I can’t really make anything too fancy yet, all I have are some rudimentary skills like boiling water and following recipe directions; my creative cooking enterprises come out more-or-less edible, but I haven’t really figured out how different ingredients will react with the others yet. I’m in the process of learning Attic Greek, and I hope to become fairly proficient in it by the end of the summer.

I’m taking this class both because it looked fun and because it fulfills my last Science and Technology requirement. I’m always interested in the way things work, and the course description indicated that the labs would probably be enjoyable. After receiving the handout in class that talks more about the labs, I was really glad that I signed up for the class, and I’m particularly looking forward to working with the robots. I hope to gain a greater knowledge of the technology that I use everyday, both how it was developed conceptually and how it is currently implemented. I am particularly interested in learning about how networks work and in getting hands-on work with logic circuits.

That’s pretty much all I have on my mind right now.

- Josh

Edit at 7:38 P.M. 02/08/2006: I own a ASUS Z70VA 15.4″ Widescreen with a 1.73 Pentium M, 1 GB RAM, 60 GB HD, and a CD/DVD R/RW drive. It’s a PC. I loathe Macs.