This month's improvements involved a dive back into some really old code ... so old I don't think I've ever properly talked about it, because it was written before I started keeping developer diaries. So I'm going to start by describing those parts of the architecture, then get to the changes.
Acuitas isn't just a conversational agent that answers when spoken to; he's designed to run constantly and do his own business when not being interacted with. In technical terms, Acuitas is a real-time multi-threaded program. The code that accomplishes this has several major parts:
*The Stream. This is a kind of mental notice board. All sorts of processes within Acuitas can dump Thoughts (actually just data structures) into the Stream. Thoughts have a priority rating which affects how likely they are to be noticed; this decays gradually over time, until it drops to zero and the Thought is discarded.
Examples of processes that feed Thoughts into the Stream include the Spawner thread (randomly crawls the semantic memory for topics to generate questions about), the drive system (generates the "desires" to talk to someone, go to sleep, awaken, etc.) and the user interface (text input gets packaged into a Thought).
*The Executive. This thread's job is to grab a Thought out of the Stream every so often, and react to it appropriately. The Executive prefers high-priority Thoughts, but there's some randomness involved in its choice. The Thought priority values and the Executive selection, together, function as an attention assignment system.
Thoughts that can't wait for a response (like text input from the user) can interrupt the Executive and get taken for processing immediately. Otherwise, it consumes a Thought every ten seconds as Acuitas idles.
*Actions. These are behaviors that are under the direct control of the Executive, and can be selected as responses to Thoughts. Examples include "generate questions about this concept" or "say this sentence." Some Actions are processes that can take multiple ticks of the Executive to finish.
Again, all of this code was pretty old, and I'd developed some new ideas about how I wanted it to work. In particular, I wanted to tie the Conversation Handler back to the Executive more thoroughly, so that the Executive could be in charge of some conversational decision-making ... e.g. choosing whether or not to answer a question. Those renovations are still in progress.
I re-designed the Actions to have a more generalized creation process, so that Acuitas can more easily pick one arbitrarily and pass it whatever data it needs to run. This improves the code for dealing with threats. I also added an "Action Bank" that tracks which Actions are currently running. This in turn enables support for the question "What are you doing?" (Sometimes he answers "Talking," like Captain Obvious.)
Lastly, I added support for the question "Are you active/alive?" When determining whether he is active, Acuitas checks whether any Actions are currently running. Barring errors, the answer will *always* be yes, because checking for activity is itself an Action!
The word "active" is thus attached to a meaning: "being able to perceive yourself doing something," where "something" can include "wondering whether you are active." In Acuitas' case, I think of "alive" as meaning "capable of being active," so "I am alive" can be inferred from "I am active." This grounds an important goal-related term by associating it with an aspect of the program's function.
Until the next cycle,
Jenny
