Robot Soul

Since the issue came up on the ProgramD mailing list, I summarized the current state in popular AIML interpreters and their uses.

Task: Integrated AIML service as part of a larger network environment
Target user: professional web developer/integrator
Interpreter: ProgramD 4.5
Very standards-oriented AIML interpreter; uses XML Schema for validation and refuses to load any AIML file it has reason to find "invalid". If you know what that means, you'll learn everything else you'll need from the documentation at aitools.org; if you don't know (and don't feel like learning it atm), you'd better choose another AIML interpreter.

Task: small-to-medium scale AIML web service; AIML creation
Target user: PHP-savvy web developer/AIML content creator
Interpreter: ProgramE
If you're used to working with PHP/MySql/Apache (or if you want to get used to it), check out ProgramE. Storing everything in a database, it's slower/supports fewer concurrent clients than those interpreters that use a store-in-memory option can, but it's known to work fine in none-too-challenging professional web environments.

Task: creation of AIML code; local as well as chat/IM and web-based AIML testing
Target user: AIML content creator
Interpreter: charliebot 4.1.8/ProgramD 4.1.5
An interpreter with well-known bugs and features; check the ProgramD-FAQ at aiml.info. It makes you namespace non-AIML tags only if you want it to, and it directly supports ISO-8859-1 encoding, so you don't have to detour via XML entities to use, say, German umlauts, either. If all you need to do is to create and test AIML code, it lets you concentrate on that, even letting you use non-namespaced HTML tags; still, if your AIML runs on it, you can be sure that it will comply with the AIML 1.0.1 specification, and anybody who knows basic XML Schema integration can transform your files to meet whatever "standards" a more "professional" AIML interpreter might require. The built-in Jetty server lets you serve AIML on the web or chat/IM without worrying about systems integration; it's not what the pros would use this year, but if you only expect to have like 10 concurrent clients, it should work ok.

(Charliebot differs from the ProgramD 4.1 main branch only by some bug fixes. Some people believe that these patches add stability, but AFAIK, no comparison test was ever published, so we don't know for sure.)

Task: experimental AIML creation; automated generation of AIML code; interfacing of AIML with large and complex knowledge bases (Cyc, WordNet, ConceptNet)
Target user: AIML experimentalist
Interpreter: ProgramN
Gary Dubuque's ProgramN is the platform for a world of wildly non-standard experimentation with the AIML language. However, you should be comfortable with using at least one other AIML interpreter before trying your hands at it...

I believe that most of the bot creators who post to the Robitron, and probably most bot creators in general, base their work on the assumption that being able to handle more data results in a better bot. And I admire their work tremendously, and learn a lot when Loebner Prize winners like Juergen Pirner and Rollo Carpenter explain the thinking behind their systems to me.

However, I want to try something entirely different. Like, what if I use none but the most frequent inputs as the data to start with, create from that set a very small "core" story that has a meaning /for the bot/ - a meaning that he can actually explain and reason about, since the input "why" is always evaluated in the context as it was created by the conversation so far -, and from there, systematically work my way down the Zipf curve, expanding my story in an n^2 fashion as I go?

Doing so is a bit like reverse-applying the idea behind Self-Organizing Maps: I hand-craft all the elements of a two-dimensional map - a generalized Zipf curve for the most common bot inputs in the English language, which is headed by words like "yes", "no", "cool", "uncool", "what", "why", "I", "you", "sex", "fuck", "shit", &c. - to represent a multi-dimensional space, by calculating - for a finite story, of course - all the relations that all the elements have in all dimensions. In usage, then, it accepts an arbitrary initial input, relative to which the map expands into a four-dimensional - three space vectors and one time vector - "story space-time", which provides context for that input, and from there, all inputs that follow.

The system changes state with (almost) every output ("almost" because it may purposefully ignore inputs, in which case it must not necessarily change its state), and stores every change. Furthermore, it is fully (self-)recursive (grounded in a fixed point combinator), so in the absence of "content bugs" - bugs caused by content creators, e.g. by failing to provide all of the required elements, by incorrectly calculating the relations between elements of the map, or by otherwise causing the resulting story space-time to become distorted -, it can be proven to be logically sound. A "Self-Organizing Story Space-Time", if you will. SOSST ;-)

The technology needed for such a system is not too hard to design and build. What's difficult is the content creation; content bugs are frequent, because lots of (symbolic) calculations need to be done by hand. But all bugs are super-obvious in normal system tests, and easily correctable due to the underlying functional programming paradigm, so in the longer run, I see the possibility to build systems that automate most of the "sense-checking", and give useful feedback once they detect an error in the content, at least for the more common errors (like undefined relations between elements/events).

Recent discussions in the Robitron group have prompted me to break down my personal view of the Turing Test problem into as few simple statements as possible. Here's what I came up with so far:

1. Turing's Original Imitation Game (OIG) imagines a computer program that can imitate a man that is imitating a woman - an activity that can be regarded as being a form of improvisational acting.

2. To imitate a woman, a man has to identify himself with a woman.

3. Therefore, to successfully play the Imitation Game, a computer program must be able to identify with, and thereby act as, another person - it has to be able to do what an improv actor does.

4. "Identification", the way actors understand it, means to simulate the inner states of a person from a first-person perspective (though this is most often expressed less formaly as "to step into somebody else's shoes").

5. To win, the OIG-playing computer program therefore has to succeed in simulating the inner states of a person from a first-person perspective.

6. To create a program that can simulate the inner states of a person from a first-person perspective, one would have to first come up with an exhaustive formalization of inner first-person states, represented in terms of Turing computation.

7. Despite an international research effort that now spans 55 years and involved thousands of the world's brightest minds and many billions of dollars, such a formalization is still unavailable.

8. This - to me - is evidence that such a formalization might be
impossible to create, and that the inner first-person states of
humans cannot be exhaustively formalized.

Any disagreement up to here?

I propose that, ultimately, teaching a human being is an impossibility: I can learn at will, but I cannot teach at will. More generally, x can learn a, but y cannot teach a to x.

This is because x can always be motivated to not learn. There are many plausible motivations to not learn; one of the most common is that y tries to force x to learn a. For quite a lot of people I know, having to read Shakespeare was a perfect motivation for not learning to read Shakespeare.

Don't get me wrong: I realize that teachers can help with learning, and that good teachers can help tremendously. But there are learners without teachers, and there are no teachers without learners.

Take programming: the best teacher cannot teach programming to somebody who is motivated to not learn it. On the other hand, somebody who wants to learn programming will learn it even if, like me, he's already 40 years old when he decides to be motivated to learn programming. Once I started writing my first program, I had started to learn programming, and after having written many programs in four years, I had learned quite a lot. The learning was in actually doing it, not in what anybody was trying to teach me during that time.

And so it is with storytelling, too: it can only be learned by somebody doing it. To learn to tell stories, you have to tell stories. You have to invest massive amounts of time into writing a load of crap to even learn to recogize what a load of crap you just wrote. And that's for starters.

I did a lot of work on understanding various flavors of formal logic over summer, and I need to capture some of the things I found. Quite probably the most important event was me finding out about Computability Logic (CL). I've yet to get in deep, but I have an excellent reason to be excited by just skimming some papers.

Computability Logic is a logic that's based on semantics. And that's a big, big deal to me. It's the first example of "officially approved" (meaning: laid out by a logician with a degree that people take seriously) semantics-based logics that I've encountred. I didn't even know that a semantics-based logic could be valid in the mathematic realm. Semantics-based logics are the bread-and-butter logics for writers, of course, but I've always assumed that no card-carrying mathematician would take such "writerly" logic as serious. This assumption was based on my observation of some card-carrying mathematicians not taking such "writerly" logic as serious. Inductive logic: fast but dirty.

Having a formal logic at my disposal that is based on semantics is likely to help me bridge the gap between the knowledge that is encoded in my application right now and the theoretical knowledge that is currently available on this application. My current problem is that I have a working program, a working semantics, and I always thought that I would need to find a syntax-based logic that resulted in just those particular semantics, in order for mathematicians to understand my program on the theory level. That is, this is what I assumed up to here: that, to build a formal logic, you have to have a syntax first, and then you use this syntax as the foundation for the semantics. And what I found is that finding a pre-existing syntax that "affords" the semantics of a particular story's logic is a pain in the ass. So there is this gap between what I have working, and what I can say to explain it, to generalize from the existing program to a class of possible programs.

News flash: Looks like it doesn't have to be that way! Semantics can come first! I'll be reading "In the beginning there was Game Semantics..." to find out more.

Back on track. The summer project I was lucky enough to be involved with wrapped up two days ago, on Sept.9, 00:20. Current lenght is 54 cm, current weight a whopping 4,300 g; we call him Wesley. Delphine is a big sister for the second time now, and Donald is a big brother for the first, and we all thank Sonja for doing the bulk of the work for us. Peace.