I've pushed some code to AI::TerracedScan that supports chunking in a less ... weird way than I did it in the first pass at Jum.

See, I envisioned the initial letter-cluster accretion process in two steps. In the first step (which I coded up in early 2024), the letters spark to other letters and try to form bonds, then short bond groups of three letters if they can. During that phase, bonded letters are still visible to the spark scouts, so there's a bit of boiling around to get better clusters.

But for the next level of organization (the gloms), I wanted to hide the component letters; I see the gloms as firmly bound letter clusters that will only get reshuffled, or broken up if things aren't working out well—at which point any number of things get randomly broken up before the system attempts to regroup them, hopefully a bit better.

(Keep reading)

One of the two major items I wanted to take care of in this iteration of the terraced scan engine is something I've been thinking of as _move-style_ codelet design. All that really means is that (ideally) all the changes to the Workspace should be carried out in the context of formally defined, named moves. Tonight I pushed a bunch of code to Codeberg implenting a variant on the NaiveSort domain which I call NaiveSortM (which you can see here). It's the same abstract domain, still just sorting numbers, but reimplemented in in a consistent pure-move style. I'd done a lot of prototypical hacks in Jum to make moves work, and I've pulled them into the engine now.

Actually, I've gotten a few different things done in the past couple of days.

(Keep reading)

Back in the 90's, when I was first running out of money for graduate work, I had already gradually refined my understanding of What I'm Doing to be, in the shortest terms, "semantics." I didn't have the mental tools back then to understand what that meant in any detail—but I knew it when I saw it, and I saw it everywhere in the work of the Fluid Analogies Research Group (FARG). So what I wanted to do in 1997, and what I attempted in 2004 in the spare time I turned out not to have yet, and what I'm actually starting to achieve today, was to examine the several models of cognition that the Group had promulgated, and to distill out the commonalities.

By "examine," of course, I meant to redevelop the key models in sequence, basing them on some common codebase. In the mid-90's, to me, that meant "Jumbo, Numbo, and Copycat." Now it means a much longer list: Jumbo, Numbo, Copycat and Metacat, Tabletop, Letter Spirit, Phaeaco, SeqSee, Capyblanca, Ear's Mind, Madcat if I can ever find that thesis, Musicat, and Linguoplotter, or some subset of those. (I'm not made of time.) Some of them have code available, some don't. I don't particularly care about that, as the point isn't to port code but to comprehend and formalize the concepts they use.

(Keep reading)

The actual mechanism of the terraced scan is agnostic by design about what codelets actually do—there's no inherent restriction on the actions they can take. You're perfectly free to use working data structures that aren't the Workspace, and at some point I'll be exploring that. It might be nice to have some other data structure being built, a database or a document or maybe a code structure or something.

But as I've been actually exercising it and learning how I prefer to design codelets and the ecosystems they cooperate in, I'm starting to converge on some best practices, or at least practices I find easiest to work with. One of them has been to group the actions taken by codelets into "fff actions" (fizzle/fail/fire actions taken when the codelet terminates). Those started out as just a list of which units should be killed; if a spark fizzles, then the spark unit needs to be deleted. And if a bond is dissolved, then obviously the bond unit needs to be deleted.

(Keep reading)

I've decided to break off the current Jumbo sprint. I wrote a more detailed tech report on the "faux milestone" which you can download in the technical reports area, but I ended up feeling some qualms about how definitive that milestone really is. Does the completion of half a system rise to the momentous nature of a tech report? Probably not.

But a blog post? Sure—and I do want to explain what it is I completed, why it's interesting, and why I stopped at that point.

(Keep reading)

If you're reading this, then my new blog posting code is unstoppable and the Vivtek website is well on its way to being the informational colossus it was always fated to be. I'm writing this introductory post in late January of 2026, but my intent is for it to migrate gradually backward as I retroactively write a bit on recent work that still feels current enough for me to pretend to have been blogging it on the fly. I expect it to end up roughly in last October, as it should remain the first post of the modern era.

This is actually about the fourth or fifth website publication code I've written, and you can still find examples of all of these eras on the site, because I never throw anything away. Many of these pages, broken and with weeds growing through their antiquated HTML and template fields, are essentially old washing machines on the back porch with a motor that probably still works. I'll go into a little history below the fold.

(Keep reading)