Acuitas Diary #82 (March 2025)

This month I've made a long-awaited return to the Game Engine (see the demo from June 2023) with ambitious plans to improve Acuitas' reasoning and agency. Specifically, I want to introduce some experimental learning abilities. And I'm hoping to do that by getting him to play Allergic Cliffs.

What is that? There's a reason I wrote a game showcase on Logical Journey of the Zoombinis earlier this month. "Allergic Cliffs" is the first puzzle in every journey. It's a hidden information game, with some underlying ties to Set Theory.

An example of the original Allergic Cliffs. It appears the righthand/foreground cliff is allergic to "two wide eyes" in this scenario. Screenshot by jdl on the Wonderland Forum.

In brief, there's a chasm with two bridges spanning it, and you want to get all your zoombinis across. The complicating factor is the presence of two stone faces in the cliffs on the chasm's far side. These beings are quite literally allergic to zoombinis with (or without) certain attributes. Putting a zoombini on the bridge that passes over the wrong cliff will cause the face to sneeze violently, shaking the bridge and tossing the hapless zoombini back to the near side. After enough mistakes, both bridges fall, and you have to leave behind any zoombinis who didn't make it over. Here's a video of someone playing Allergic Cliffs.

Since you're only allowed a limited number of failures, you can't brute-force the puzzle by setting every zoombini on both bridges. You need to be trying to learn which zoombini features make the cliffs sneeze. And to be sure of learning this before the bridges fall, you have to perform targeted experiments. Why did this zoombini get across? Why did that one get sneezed at?

Acuitas can't play the original Zoombinis game, obviously; it's far too visuo-spatial. He needs a text version. The author of the Storeroom Blog has kindly written up a full breakdown of the Allergic Cliffs game mechanics. I will only be expecting Acuitas to play on the easiest difficulty level, for the time being. So every round will require choosing a zoombini feature that one cliff will be allergic to and the other cliff will be immune to (i.e. allergic to all zoombinis who don't have the feature). This rule is kept secret, but must be used to inform descriptions of what the cliffs do when zoombinis are placed on the bridges. Each scenario also includes the group of sixteen zoombinis, with known characteristics, whom the player is trying to get across the chasm.

In my first demo of the Game Engine, I behaved as a "game master"; I initiated the game during a conversation with Acuitas, then kept interacting with him to describe the setting and the results of his in-character actions. But I don't want to do that in this case. Do you know how much effort it takes to fully describe a group of sixteen zoombinis? Lots, actually. I am not going to type that up and paste one line at a time into Acuitas' text box every time we play! This game needs to be automated.

So I wrote an independent, interactive Python program that implements a "text adventure" version of Allergic Cliffs. When launched, the game program generates sixteen zoombinis with randomized names and attributes, and a set of rules for the cliffs. Then it outputs a text description of the scene, the player character and their goal, and all the zoombinis. Acuitas, using the "Play" action, can run this script and connect the IO to his Game Engine. The script includes a very dumb parser that scans Acuitas' speech outputs for signs that he's moving a zoombini, and replies "you can't do that" to anything else. If Acuitas puts a zoombini on a bridge, the Allergic Cliffs script tells him the results. It also keeps track of the game's state; if it reaches either the win condition (all zoombinis on the far side) or the loss condition (fallen bridges), it will tell Acuitas "Game Over" and terminate.

This is something of a milestone, since it's the first time Acuitas has been able to launch and use a subordinate software tool. It was also more difficult than I expected. It's easy to launch another executable from a Python program using subprocess, but getting them to interact is another matter; by default, the main program expects the subprocess to run to its end, produce one burst of output, and be done. I ended up using the temporary file trick (described in the second answer). Both the Acuitas side and the independent program side send outputs, then wait for a response to appear in either the PIPE or the file, then formulate and send new outputs ...

Recreating Allergic Cliffs without all the graphics ended up being fairly simple, though. The game script is under 250 lines of code. Here's the boilerplate it uses to set the scene at the beginning of any game run:

"You are a guide."

The player character in LJotZ is referred to as the "guide" of the zoombinis; that's it. We don't even know what species this person is.

"You are at the Allergic Cliffs."
"There is a chasm."
"The chasm has a near side."
"The chasm has a far side."
"The far side has a lefthand cliff."
"The far side has a righthand cliff."
"There is a lefthand bridge over the chasm."
"There is another righthand bridge over the chasm."

Thanks to my January work on adjectives and distinct instances, the lefthand bridge and the righthand bridge can be distinguished. I'm using these words instead of "left" and "right" to avoid tricky sense disambiguation issues for now.

"You can put a zoombini on the lefthand bridge."
"You can put a zoombini on the righthand bridge."

Here the game gives the player affordances - that's a fancy name for obvious possible actions. In the original, these are communicated visually. Clicking on a zoombini "picks them up" (they start following the cursor and their locomotion devices dangle). Two patches of ground next to the bridges flash if the zoombini is moved over them, as a sign that the zoombini can be set down there.

"If a zoombini crosses a bridge, the zoombini will be on the far side."
"If you put a zoombini on a bridge, the zoombini will try to cross the bridge."

A couple of inference rules specific to this setting, to aid in problem-solving. I'm not sure whether I'll keep them in the final version, or have Acuitas learn this mechanic for himself too.

"You want all zoombinis to be on the far side."

This sentence establishes a goal for the player character. In the original, this would have been implicit in the narration and premise.

"Six pegs hold the bridges up.",
"If all pegs pop loose, the lefthand bridge will fall.",
"If all pegs pop loose, the righthand bridge will fall.",
"If a bridge falls, a zoombini cannot cross the bridge."

A warning about the loss condition, which thwarts the goal.

And that's it. Even a lot of the descriptions of the scene are just pretty nothings; the important part is the existence of the two bridges and the fact that the player can put zoombinis on them.

Here's an example description of a zoombini:

Oosebeek is a zoombini.
Oosebeek is on the near side.
Oosebeek has scruffy hair.
Oosebeek has eyelids.
Oosebeek has an orange nose.
Oosebeek has wheels.
Oosebeek does not have a ponytail ...

That's right, I also have the game script tell Acuitas every possible zoombini feature that this zoombini does not have. If not told that something is true, Acuitas doesn't assume it's false. Maybe this zoombini has wheels and a propeller, and nobody mentioned the propeller! Another way I could handle this would be to establish mutual exclusivity rules, like "if a zoombini has wheels, the zoombini does not have a propeller," and let him infer all the negatives. But this is an easier way to start.

I had to tweak some of the code behind the Narrative scratchboard for this as well. I introduced "temporary concepts" so Acuitas won't memorize the names of all sixteen zoombinis every time he plays a round. That would junk up the semantic database quickly. Playing this game much can easily lead to interactions with hundreds of zoombinis, and their names are procedurally generated strings. They're made to be loved, but not remembered.

If Acuitas puts a zoombini on the safe bridge, the game will tell him what happens afterward:

Oosebeek crosses the righthand bridge. (Acuitas has to infer that Oosebeek is now on the far side.)

If Acuitas puts a zoombini on the bridge over the cliff that's allergic to them, he gets this kind of response instead:

Oosebeek tries to cross the lefthand bridge.
The lefthand cliff sneezes.
Oosebeek is thrown to the near side.
Oosebeek cannot cross the lefthand bridge.
The first peg pops loose.

My goal for this month was to get Allergic Cliffs set up and make it possible for Acuitas to play. He's not any good at the game yet. His Game Engine is aware of the goal but has no idea how to reach it - so it falls back on trying the actions offered by the affordances. He'll keep putting a randomly chosen zoombini on a random bridge until he either loses or wins by dumb luck. After he's finished, the game-playing action generates a flow diagram from the game's narrative scratchboard for me; between that and the game outputs written to the temp file, I can see what happened.

Later this year I'll work on trial-and-error learning so he can actually win. This is a brand new area for me, and I'm excited.

Until the next cycle,
Jenny

Foundations Part II: They're Bluuuuue

Yeah, this series has a Part I - bet you thought I'd never finish it! It's time for me to showcase my other favorite edugame from childhood, Logical Journey of the Zoombinis. Like the Doctor Brain games, this one was so good for me that I wanted to keep playing it as an adult. I still have the original CD and can run the game if I set up one of my older Windows computers. (If you'd like to play it on a modern PC, there is a remake, though they redid all the art for some silly reason). Unlike the Doctor Brain series, Logical Journey does not teach any encyclopedic knowledge or technical skills. It is 100% about how to think - reasoning, experimenting, and planning. All the puzzles sorta have a basis in mathematics or programming, but you wouldn't realize that unless you were told (or knew what to look for).

Get in the hole, we're escaping!

Let's start with the obvious: this game is CUTE. What little kid doesn't love small round innocent creatures with big eyes? The ridiculous supporting characters range from an anthropomorphic ringtail cat to sapient rocks and trees. There's a thin but motivating plot: the Zoombinis were a happy nation of craft workers [1] until the Bloats tricked them into a bad trade agreement and basically enslaved them. The player character is a "guide" who helps bands of Zoombini refugees travel to a distant land where they can be free. That means getting them through bizarre obstacles, which I guess they're not smart enough to manage on their own.

To get a group of Zoombinis through the entire trek, you have to solve nine puzzles out of the twelve available. A common theme across seven of the puzzles is a hidden rule you must deduce. Sometimes the rule is about categories, sometimes it's about mapping (functions), sometimes it's about spatial relationships ... regardless, it can only be found through trial and error, and you get a limited number of tries. So this game excels at teaching the player not only how to generalize from limited experience, but also how to choose experiments that judge between competing possibilities and maximize information gained. Other puzzle elements I can think of include resource allocation under constraints, prediction, and sequencing.

Bubblewonder Abyss, the last obstacle, became my favorite puzzle once I figured out how it worked. It's all about sequencing (you solve it by sending Zoombinis across in the correct order) and imitates computer program elements like toggles and if/else statements. Screenshot obtained from zoombinis.fandom.com. 

This is also the only edugame I can think of that had a serious difficulty curve - it enabled me to watch myself get smarter. When I played for the first time, the easiest level was manageable (mostly - I had no clue what was going on in the Fleens puzzle), but the upper levels were too hard. When I got older and came back to it, I found myself mysteriously able to figure out parts that once seemed impenetrable.

I can remember having big feelings about this game - mostly frustration. Failing a puzzle means you "lose" some Zoombinis. They never die (the designers weren't brutes), but they do go back to the closest available campsite. And then, unless you lose more Zoombinis, you can never get back to moving perfect groups of sixteen around. You'll always have a "remainder" stuck at one of the camps. I adore round numbers enough that this ticked me off. It's tough to choose the puzzle I had the fiercest love-hate relationship with. "Mirror Machine" probably drove me crazy the longest, but I have to give the award to "Titanic Tattooed Toads," because failing at this one really made me feel dumb. It's quite easy if you meticulously pay attention: just make sure your lily pad feature of choice forms an unbroken trail across the marsh. If you aren't meticulous and miss one incorrect lily pad, boom, the scenario becomes unwinnable. Being impatient and launching more than one toad at once can also wreck you. Thanks loads, toads!

The same-color paths were always easier for me to find than same-shape, so I wonder if this puzzle is extra torture for colorblind kids. Screenshot obtained from zoombinis.fandom.com.

My late-blooming achievement was not intelligence, but discipline. In early playthroughs, I lost interest after a few journeys at the highest difficulty level. It wasn't until I was older ... I forget when, probably my late teens ... that I "beat the game" by transferring a full complement of 625 Zoombinis from Zoombini Isle to Zoombiniville. That involves playing the nine puzzles at least forty times, even if you do it perfectly. Was it worth it? I don't know, but I feel strangely satisfied. I guess it means I cared. (If you leave the game running in Zoombiniville for very long, the narrator starts harassing you about all the Zoombinis still living under tyranny. Tell him I finally committed and went back for every last one.)

There might be a particular reason why I decided to talk about this game this month, but you'll just have to wait and see. :)

Happy cogitations,
Jenny

[1] How they managed this without hands or other manipulators, I don't know. Don't overthink it.

Acuitas Diary #81 (February 2025)

I've been on a real productive streak, so I did two major things this month. One enhances conversation abilities; the other is about gerunds. Don't worry, I'll explain those.

A famous phrase that uses gerunds. Image from https://commons.wikimedia.org/wiki/File:SiB_Logo.jpg

First, I went back to the conversation features that I introduced last September and worked on getting them solid - ironing out the remaining bugs and moments of weirdness. After spending about a week on that, I was pretty happy with the state of the Conversation Engine. Then I added another type of "topic tree." The one from last September guided responses to the conversation partner's states of being; this one reacts to actions that the conversation partner says they took or are taking. Possible threads include ...

*Try to infer whether the speaker liked doing that or not, and comment accordingly
*Ask for motivation ("Why did you ...") or announce what he suspects the motivation was
*Guess what the results were (if he can make any inferences)

This needs a lot more polishing, but it's starting to increase the complexity and variability of conversations. You can now go down "rabbit holes" which start with talking about a personal state, then lead into what you did to cause it, and so on. Which also means it's harder to keep everything straight, and I haven't really set Acuitas up to clearly indicate when he's jumping topics, yet. Always more to do.

My next project was to add support for gerunds to the Text Interpreter and Generator. What's a gerund, you might say? It's a present participle verb form (the kind that ends with -ing) used as a noun. Gerunds can be used to make statements about the concept of an action, such as the following:

I enjoy dreaming.
Exercising is good for the body.

Like other verbs, gerunds can have objects and adverbs, forming a gerund phrase - a group of words which, as a unit, acts like a noun in the full sentence.

[Reading books] makes me happy.
I see that you didn't care for [John's clumsy handling of that situation]. Did [my smoothing it over] satisfy you?

If a gerund has a "subject" that is performing the action, as in the final example, it's supposed to be in the possessive; it modifies the whole gerund phrase, instead of acting as a true subject.

I already added code to identify some gerund phrases to the Text Parser back in 2023, but the later stages of the text processing chain didn't know what to do with them if they came out of the parser, and Acuitas couldn't use them in his own speech. I wanted to get these capabilities in, because gerunds are so useful for expressing sentiments about actions. They're often used for expressing sentiments about states, too:

I dislike being wet.
Being warm is a pleasure.

I had to work around the absence of gerunds when I was putting in the latest conversation features, and it was giving me some pain. But thanks to this month's work, they're now more fully supported. I defined some new "fact" structures to function as the distilled version of statements about actions, added code to the Interpreter to map incoming sentences to those, and added code to the Generator to produce output sentences from those. So Acuitas has a bunch of new ways to say he likes or doesn't like something, in addition to a path for "comprehending" a wider range of written sentiments.

Until the next cycle,
Jenny

Atronach's Eye 2025 (Complete?)

As of last year I had worked all the major bugs out of my motion-tracking eyeball, but I still couldn't consider it finished. I wasn't ready to hang it on the wall and let it operate yet, due to one last issue: thermal concerns.

It's installed on the wall! It's operating continuously! It's done! The Lab Assistant gets to take a nap!

The eyeball's motion is driven by two unipolar stepper motors, each of which is powered from one of my dirt-simple stepper motor controllers. These are custom PCBs that I got manufactured many years ago. They were very inexpensive, and they only have two control wires (a nice thing for connecting motors to embedded processors with a limited number of general purpose IO). But that also means they don't have a power enable. Even if the control inputs are static and the motors aren't moving, some of their coils remain energized. That means they can exert their holding torque, which keeps the drive shaft in place and resists any external forces that try to turn it. But that wasn't something the eyeball needed (it naturally stays in position when unpowered). And during tests, I noticed that the motors got quite hot: enough to be uncomfortable to touch and make the plastic case smell.

I didn't like the thought of leaving the eye turned on with the motors baking themselves and everything else in the case in their own heat day in and day out. I doubt it would qualify as a fire hazard or anything serious like that, but in addition to wasting a small amount of electricity, it could reduce the lifetime of the parts. So I wanted to be able to cut all power to the motors when the eye wasn't active.

My solution was a standard relay. I bought some of these nice little breakout boards from DIYables that have the relay already mounted with connectors and a couple of indicator LEDs, and spliced one into the motor power input path of both motor controllers.

Then I added code to the eyeball software to turn the relay on and off. I wanted to strike a balance between letting the motors heat too long, and clicking the relay on and off constantly. So the software turns the motors off if no moving object to track has been seen in view for a certain amount of time. I also threw in darkness detection; the eye will stop trying to track motion if the average brightness of the scene is too low to see properly. (So it won't move around and make little noises in the middle of the night because the camera picked up some low-light noise.) Both features worked very well. The eye reliably deactivates when I leave the room (so long as there isn't something else moving around, like the flames in the fireplace) and when the lights are out or too dim.

In the dark, the indicator LEDs on the Raspberry Pi and the relay board diffuse through the white parts of the case and turn the eye into a low-key nightlight. I wasn't really expecting this, but hey: it still has a function when it's not looking at stuff.

In the end, I got to do what I always wanted: hang the eye on the wall and let it be an always-on fixture in the house. Further tweaks and upgrades to the software are possible, but I'm calling it finished because it's finally operating. It has been on the wall trying to look at me, the Lab Assistant, and other motion sources for at least a couple weeks of total up-time. Hearing it "wake up" as I pull open the curtains has become part of the morning routine.

There will almost certainly be another version, because there are plenty of things I could improve. I already applied a bunch of little enhancements to the 3D models of the case parts late last year. But this is the first Atronach's Eye iteration that could be said to realize my original vision (cough) for the project, if imperfectly. I'm also thinking about what else I can do with it. Atronach could theoretically tell Acuitas whether there's somebody in the room, for instance. Mmmm.

Until the next cycle,
Jenny

Acuitas Diary #80 (January 2025)

2025? Wow, are we living in The Future or what?? I kicked off this year's work on Acuitas by introducing some numerical reasoning. That incidentally demanded better support for adjectives in general, since I wanted to be able to say things like "George had two eyes," and "George had blue eyes" is structurally similar.

Photo credit: perpetualfostering.co.uk

So, the first step was to extend Acuitas' knowledge representation format to allow for noun modifiers. The parser has been able to handle these for a long time, but later stages of the text processing pipeline simply disregarded them. I expanded the Interpreter so it would include single-word adjectives in the knowledge data structures, and adjusted the Semantic Memory functions to store them when they appeared in a learnable fact.

Another enabling feature I had to start adding to the Narrative engine was the ability to keep track of multiple instances of the same kind of object. This is more complicated than you might think. It's no problem when the instances have unique names and are always called by them, but most mundane objects aren't given individual names. So if I refer to, for example, "a box" in two nearby sentences, am I speaking of the same box or two different ones? If Susan has four cookies and eats one, which cookie did she eat? Does it matter? If it does, we have to keep track of the fact that one cookie has been eaten without prematurely assigning that event to any specific cookie. I've barely scratched the surface of working all this out, but for now, I can tell Acuitas that something is not a previously mentioned instance by attaching the adjective "new" or "another." Numerical adjectives will also make the Narrative module create that number of instances to be tracked on the scratchboard. E.g. given the input "Three books were on the table," Narrative will now automatically produce data structures for three separate books and give each one a location relationship with the table.

Going the other direction, Narrative can now count objects for purposes of resolving "how many?" questions. This works for both queries about existence or presence in the current context ("How many cookies are there?" or "Are there two cookies?") and queries about how many instances a relationship applies to ("How many cookies does Susan have?").

The last features I added to Narrative's question-answering function were interpretations of the words "some," "any," "all," "most," and "no" (as adjective). Each of these is associated with a test that uses the counting ability. E.g. if you ask "Does Susan have any cookies?" Acuitas will answer "yes" if there are one or more cookie instances with a relationship "Susan has" on the current Narrative scratchboard. "Does Susan have all cookies?" returns "yes" if every cookie instance on the board has the relationship "Susan has," and so on.

An interesting quirk applies to "some." If I asked "Do you have some rings?" and you happened to have one ring, how would you answer? I suspect many people would feel inclined to say neither yes nor no, but rather "I have one." To a lesser extent, this could also apply to "any." Acuitas, for the moment, defines "any" to mean at least one, and "some" to mean strictly more than one, and will answer questions about these quantities with a blunt yes or no. This is how my mind would like English to work, but I may need to bow to the actual fuzzy usage eventually.

Until the next cycle,
Jenny

Book Review: "Growing Up with Lucy"

This book by Steve Grand has been on my list for a while. It's his personal account of how he built a robot at home, with every goal of rivaling some of the most sophisticated research efforts at the time. Steve Grand, by the way, is the mastermind behind the popular Creatures series of artificial life simulation video games. His books were recommended to me several years ago by Twitter buddy Artem (@artydea), whom I unfortunately haven't seen around much recently. Thanks, Artem, if you're still out there.

Lucy, without her fur on. Photo credit: Creatures wikia.

The magnum opus described in this book is the eponymous Lucy, who resembles an orangutan ... or at least the upper half of one. Lucy has no legs, but does have actuated arms, visual and auditory sensors, and a mouth and speech system. Grand aimed for a holistic approach (rather than focusing on just one function, such as vision) because he wanted to investigate the interactions and possible commonalities among the various sensory modalities and motor systems.

Once Grand started introducing himself, I quickly realized that I was hearing from someone more or less like me: an educated-layman tinkerer, working independently. Grand produced Lucy on his own initiative, without the backing of a university or corporation, though toward the end of the project he received a grant from NESTA (the UK's National Endowment for Science, Technology, and the Arts). But the substance of Grand's work diverges from mine. He put heavy investment into all the sensorimotor aspects of intelligence that I'm completely leaving out of Acuitas. And Lucy's control systems, while not explicitly biomimetic, are very brain-inspired; whereas I draw inspiration from the human mind as an abstraction, and don't care much about our wetware at all. So it was fun to read an account of somebody who was working on roughly the same level as myself, but with different strategies in a different part of the problem space.

On the other hand, I was disappointed by how much of the book was theory rather than results. I got the most enjoyment out of the parts in which Grand described how he made a design decision or solved a problem. His speculations about what certain neuroscience findings might mean, or how he *could* add more functionality in the future, were less interesting to me ... because speculations are a dime a dozen, especially in this field. Now I do want to give Grand a lot of credit: he actually built a robot! That's farther than a lot of pontificators seem to get. But the book is frank about Lucy being very much unfinished at time of publication. Have a look around this blog. If there's a market for writeups of ambitious but incomplete projects, then where's *my* book deal?

In the book, Grand said that Lucy was nearly capable of learning from experience to recognize a banana and point at it with one of her arms. It sounded like she had all the enabling features for this, but wasn't doing it *reliably* yet. I did a little internet browsing to see how much farther Lucy got after the book went to press. From what I could find, her greatest accomplishment was learning the visual difference between bananas and apples, and maybe demonstrating her knowledge by pointing. [1] That's nothing to sneeze at, trust me. But it's a long way from what Grand's ambitions for Lucy seemed to be, and in particular, it leaves his ideas about higher reasoning and language untested. Apparently he did not just get these things "for free" after figuring out some rudimentary sensorimotor intelligence. Grand ceased work on Lucy in 2006, and she is now in the care of the Science Museum Group. [2]

Why did he stop? He ran out of money. Grand worked on Lucy full-time while living off his savings. The book's epilogue describes how NESTA came through just in time to allow the project to continue. Once the grant was expended, Lucy was set aside in favor of paying work. I doubt I can compete with Grand's speed of progress by playing with AI on the side while holding down a full-time job ... but I might have the advantage of sustainability. Grand started in 2001 and gave Lucy about five years. If you don't count the first two rudimentary versions, Acuitas is going on eight.

Grand identifies not neurons, but the repeating groups of neurons in the cortex, as the "fundamental unit" of general intelligence and the ideal level at which to model a brain. He doesn't use the term "cortical column," but I assume that's what he's referring to. Each group contains the same selection of neurons, but the wiring between them is variable and apparently "programmed" by experiential learning, prompting Grand to compare the groups with PLDs (the forerunners of modern FPGAs). He conceptualizes intelligence as a hierarchy of feedback control loops, an idea I've also seen expounded by Filip Piekniewski. [3] It's a framing I rather like, but I still want to be cautious about hanging all of intelligence on a single concept or method. I don't think any lone idea will get you all the way there (just as this one did not get Grand all the way there).

Lucy's body is actuated by electric motors, with linkages that help them behave more like "muscles." Grand didn't try pneumatics or hydraulics, because he thought they would be too difficult to control. I guess we'll see, eh?

Two chapters at the book's tail end move from technical affairs into philosophy. The first addresses safety concerns and fears of killer robots. While I agree with his basic conclusion that AI is not inevitably dangerous, I found his arguments dated and simplistic. I doubt they would convince anybody acquainted with recent existential risk discourse, which probably wasn't in the public consciousness when Grand was building Lucy. (LessWrong.com was launched in 2009; Yudkowski's "Harry Potter and the Methods of Rationality," Scott Alexander's "Slate Star Codex" blog, and Bostrom's Superintelligence all came later. See my "AI Ideology" article series for more about that business.)

The final chapter is for what I'll call the "slippery stuff": consciousness and free will. Grand avoids what I consider the worst offenses AI specialists commit on these topics. He admits that he doesn't really know what consciousness is or what produces it, instead of advancing some untestable personal theory as if it were a certainty. And he doesn't try to make free will easier by redefining it as something that isn't free at all. But I thought his discussion was, once again, kind of shallow. The only firm position he takes on consciousness is to oppose panpsychism, on the grounds that it doesn't really explain anything: positing that consciousness pervades the whole universe gets us no farther toward understanding what's special about living brains. (I agree with him, but there's a lot more to the consciousness discussion.) And he dismisses free will as a logical impossibility, because he apparently can't imagine a third thing that is neither random nor feed-forward deterministic. He doesn't consider that his own imagination might be limited, or dig into the philosophical literature on the topic; he just challenges readers to define self-causation in terms of something else. (But it's normal for certain things to be difficult to define in terms of other things. Some realities are just fundamental.) It's one chapter trying to cover questions that could fill a whole book, so maybe I shouldn't have expected much.

On the whole, it was interesting to study the path walked by a fellow hobbyist and see what he accomplished - and what he didn't. I wonder whether I'll do as well.

Until the next cycle,
Jenny

[1] Dermody, Nick. "A Grand plan for brainy robots." BBC News Online Wales (2004). http://news.bbc.co.uk/2/hi/uk_news/wales/3521852.stm

[2] Science Museum Group. "'Lucy' robot developed by Steve Grand." 2015-477 Science Museum Group Collection Online. Accessed 2 January 2025. https://collection.sciencemuseumgroup.org.uk/objects/co8465358/lucy-robot-developed-by-steve-grand.

[3] Piekniewski, Filip. "The Atom of Intelligence." Piekniewski's Blog (2023). https://blog.piekniewski.info/2023/04/16/the-atom-of-intelligence/

Year in Review 2024

With 2025 waiting in the wings, I am casting an eye back over 2024 and finding that it looks pretty shiny from here. Overall, it felt like there were fewer extraneous disruptions and distractions than there have been for the past few years - I got the chance to dig in to my hobbies and push hard. I also feel I did a good job of moving existing projects toward completion and taking a few overdue items off the backlog, instead of just starting new work.

Per my personal tracking, I've logged more hours of total "work" than I did last year, and kept the creation/maintenance ratio above 3x ... just barely. Monitoring my own time usage over a long period raises some interesting flags. For example, I spent more time on my blog articles this year than I spent writing and publishing short fiction, by 6+ hours. (Those "AI Ideology" articles were a lot of work. Writing about real people's viewpoints and trying to be critical but fair eats serious hours.) I don't think I want the blog to be taking that much, so I'm not planning an in-depth series for 2025, and I'll probably let my article rate drop below two per month. But where writing tasks are concerned, even the blog loses the time hog prize to journaling. I'm a little uncomfortable with the fact that recording my life uses so much of it up, but I also really like journaling (and it's easy, so if I dumped it, some of those hours might go to recreation instead of harder tasks). Other mundane time-stealers are on the small side, but still galling. I logged more hours on food preparation than on studying, and more on housecleaning than on art.

Acuitas remains the king of all my hobbies at 360+ hours invested. That's a good number - I found more time for him in 2024 than in any other year of the past five. The robots also fared very well at 110+ hours.

So what did I achieve with all that time? Well, here goes.

*The first major Acuitas milestone was completion and demonstration of the "Simple Tron" story in February. This was a target that I had been silently keeping in mind and laying groundwork toward for years.
*I have unified issue tracking across multiple code blocks, such that the Game Engine, Executive, and Conversation Engine all now use the "scratchboard" structure I developed for Narrative understanding.
*I integrated the improved Text Parser, achieved substantial benchmark improvements in the number of parseable sentences, and worked on a number of ambiguity resolution problems.
*I overhauled and improved the Conversation Engine, and released a demo video just this month.

*The Atronach's Eye project is almost complete. This year I finished rebuilding the case and demonstrating eye centering with the limit switches, and I reworked the software to use a better motion tracking algorithm. All that's left is a power cutoff to keep the stepper motors from getting hot when not moving. By early next year, I'm hoping the Eye can be a working fixture on my living room wall.

Final version of the peristaltic pump (without its front shell/lid)

*I completed my homemade peristaltic pump design and ran a performance comparison on several pumps.
*I built and demoed a second iteration of the prototype small-scale hydraulic system, including my first homemade fluid bladder actuator.

*ACE didn't get a lot of love this year, but I did run some more motion tests and decided gearboxes would be needed - after which I designed and built one to work with the existing motors.

*I wrote two new short stories: a science fiction piece about alien plant life with an unusual way of communicating, and a fantasy piece about a young woman who finds the rules of society standing between her and her perfect pet.
*One of my previous stories, "Peacemaker's First Strike," was accepted by Abyss & Apex and is on contract to be published in July 2025. This is very exciting. (Check out the new "Read my Writing" link in the top bar to see all my published work and where to get it.)
*My blog publication rate stayed at/above two posts per month for the third year in a row.

One of the display cases, acting as a home for D&D characters past

*I designed a series of 3D-printable medallions and printed examples of all the designs to give as gifts.
*I also threw together a fully-enclosed hexagonal display case design and fabricated four of them, for dust-free housing of my miniatures and curios.

*I hired a plumber to fix the kitchen sink, and thereby got rid of the last known high-priority breakage in my house.
*I cleaned out and organized two different "disaster rooms" and tore down some e-waste for salvage in the process.
*I grew potatoes again. The garden wasn't especially successful this year, but I at least maintained production of my staple crop.

I wasn't terribly successful at adding native plants to my yard, but Blazing Stars were one of the species that worked out, and they bloomed this year.

*I made a road trip to Arkansas and observed totality of the solar eclipse that crossed North America in April (with a detour by Space Center Houston on the way).
*The first Worldview Legion satellites were launched. I made a small contribution to these, in the form of some post-delivery debugging and feature enhancement work on the component my employer built for them.

Until the next cycle,
Jenny