Starting from a single live cell, of the 256 rules 16 immediately wink out (empty grids in the picture below), 16 don't change (vertical lines), 48 move the cell (24 each to the left and right), 30 grow into triangles over time (6 each to the left and right and 18 on both), 18 form Sierpinski patterns and 22 are more chaotic. Here's a detail in Lua Carousel where you can see many of these types.

However, things look different if you start from a random configuration of live and dead cells. Seemingly well-behaved rules hide subtleties, and seeming patterns vanish.

For a given rule, different random initial configurations largely look the same from a distance, which suggests random selection yields more realistic pictures for a rule.

Eye-balling the surface, I think 47/256 rules are chaotic.

Rule 30 is the famous one, but my favorites are rule 150 and 165.

(I've also been skimming Stephen Wolfram's "A New Kind of Science" as I do this. Wolfram separates "nested" from "random" patterns, but that seems to be an artifact of starting with a single live cell. "Nested" patterns (like Sierpinski triangles) are just a milder kind of chaos our visual cortex can get a grip on.)

Starting with a single live cell is 'simple' but grossly incomplete, exercising only scenarios 0, 1, 2, and 4 in the first step.

And if we truly care about simple, why not just start with all dead cells? Rules don't care.

Anyways, I see two fairly simple initial states that exercise every possible scenario in time step 1: the mirror images 10111 and 11101 when surrounded by runs of dead cells.

Now I see only the one real stable rule: rule 204. 204 is binary 11001100, each bit of which is exactly the middle bit of numbers 7-0. In other words, every scenario maps to the central square.

Even here, though, the long runs of dead cells keep the "true nature" of a rule from coming out. I think random initial conditions do that much better.

Perhaps what would be best is to keep our simple pattern in the center exercising all scenarios, and then pad it with a random initial state. We do have to remember to pad it out with 3 dead cells. Let's do that on both sides for symmetry.

Ah, here's a nice screenshot of a central portion of the ruleset, ideal density for chaos to emerge.

Links

• Lua Carousel
• Instructions for browsing the 1-D CAs on Lua Carousel.

After finishing the map, I've been paying attention to the "meta game" of manually adjusting box positions and widths (height depends on amount of text) to make the arrangement pleasing to the eye. Constraints I've grown conscious of during this process:

• Lining up child nodes vertically
• Lining up nearby nodes. (imperfectly)
• Avoiding long edges.
• Keeping nearby edges approximately the same length.

I'd appreciate if anything seems jarring in this image, or if you have new OCD rules to infect me with :)

One frustration: I spent a while adjusting widths of boxes to not wrap lines within words, only to find that adjusting zoom messes things up again. This is an old problem: I can have precise scaling or crisp text, but not both. All my apps choose the latter. ]]> http://akkartik.name/post/2024-04-14-devlog 2024-04-14 http://akkartik.name/post/2024-04-14-devlog

Convolving a list with itself. Given a list [x1, x2, ..., xn−1, xn], where n is unknown, construct [(x1, xn), (x2, xn−1), ..., (xn−1, x2), (xn, x1)] in n recursive calls.

And I am able to switch apps and solve it right on my phone, without needing to get out of bed.

I do have to put up with some klunky syntax, though: https://akkartik.itch.io/carousel ]]> http://akkartik.name/post/2024-04-13-devlog 2024-04-13 http://akkartik.name/post/2024-04-13-devlog https://www.exaequos.com

Looks like it's a fork of emscripten augmented to compile a whole OS kernel and userland. Includes raylib for graphics, and Lua bindings to it so I feel at home. Seems easy to build so I'm comfortable depending on the hosted version.

There's an app store anyone can publish apps to. Your changes remain in your browser's local storage until you publish them. All apps in the app store are mounted on the file system under /usr/store so it's easy to look at their source code.

Here's a port of one of my early LÖVE apps, for geometric constructions. It's on the app store so anyone should be able to run it just by clicking on this link.

https://www.exaequos.com/?a=/usr/store/akkartik/geom

Disclaimers. It's slow. Still lots of bugs. I had to reboot the VM several times while recording this video. Commands often hang or crash, then completely stop working until I reload. It's never lost my data, though. (Data is stored in local storage.) ]]> http://akkartik.name/post/2024-04-02-devlog 2024-04-02 http://akkartik.name/post/2024-04-02-devlog

https://akkartik.itch.io/carousel/devlog/708682/drawing-histograms ]]> http://akkartik.name/post/2024-03-29-devlog 2024-03-29 http://akkartik.name/post/2024-03-29-devlog "Add noise then quantize."

https://akkartik.itch.io/carousel/devlog/706603/the-simplest-possible-dither ]]> http://akkartik.name/post/2024-03-24-devlog 2024-03-24 http://akkartik.name/post/2024-03-24-devlog As background, you can click 'edit' on my Carousel-based .love files…

… to edit their source code right on your device, whether it's a computer or mobile device.

The question is how to preserve your edits in the face of changes to lower levels: either the LÖVE app or the .love file you're making changes to.

It seems to me one essential constraint of my platform choice is: upgrading the LÖVE app on a mobile device will blow away all installed .love files. Nothing I can do about this, and luckily LÖVE upgrades rarely enough that maybe we can live with that.

But it does mean we can't get too comfortable making edits on a mobile device. With that in mind, I'm trying out the following flow:

• When you edit a file in my Carousel-based multi-file apps like sokoban.love, it highlights the file in red to show that it has local modifications.

  

• Later if you switch to a new version of sokoban.love, you can choose to 'revert' the file and blow away your changes.

  

• You can also 'stash' the file so it won't run but you also still have access to it.

  

• Stashed files receive an immutable version suffix, and get highlighted in a third color.

  

• Stashed files can be unstashed if you want to try them out after making edits.

  

Still klunky, but feels like an improvement. And I'm trying to only show the new complexities when they're relevant, so most people won't have to care about them. Above all, the hope is that the red reminds people to not make too many changes on a mobile device.

And yes, I've been thinking about Ink & Switch all week. Perhaps this needs CRDTs and collaborative editing. But making it more friendly might encourage more changes than this platform can candidly handle, given the restrictions of mobile platforms. ]]> http://akkartik.name/post/2024-03-23-devlog 2024-03-23 http://akkartik.name/post/2024-03-23-devlog I seldom mess with it, but today I modified it to show gridlines any time I drag things around. Should lead to neater maps!

https://akkartik.itch.io/carousel/devlog/702311/all-the-1-d-cellular-automata ]]> http://akkartik.name/post/2024-03-17-devlog 2024-03-17 http://akkartik.name/post/2024-03-17-devlog https://www.spinellis.gr/sw/dgsh

]]>