 Hey, folks, welcome to the Artificial Life Advanced Class. So where we were, we've been running these growing diamonds on the T2 tile grid since August. And the first time we did it, a couple of weeks it ran, and then it ran into a internal error of some kind which caused a crash, which caused a crash norm and took everything out. There was not an absolutely clear diagnosis as to what it was. My suspicion was that in very rare cases, it's possible to run out of space in what I had allocated for packets to get exchanged back and forth between tiles. I increased the size of that by a factor of four, distributed it all out to the grid and started the whole thing up again, ran a couple of dozen seeds, growing diamond seeds on the grid, same code, and let it go. And so how has it gone since then? Well, let's take a look. I made it into a game. I mean, the algorithm, what happens with these growing diamonds is, if there's enough of them, they grow until they fill space and they jam up and then eventually one of them decides to check out. And that creates more space, so they grow again, they lock up again. And the game is, can you figure out, can you do better than chance at figuring out which of these diamonds is gonna die when they jam up? It's not always, the answer is not always big. I have a theory here. Yeah, I thought it was gonna be this time. And, all right, so now it's jammed up, let's be a game. I just labeled them from left to right, top to bottom, you know, when they pick something that are jammed up. All right, so here, this is where I put in some more seeds because it was actually getting too loose. Now it's jammed up again. And so that makes more space and then they can all jiggle around again and they lock up again. All right, one more. It was a big game. It's just the way it worked out. But the bigger picture is that, well, so first point is, how can we possibly predict it's supposed to be random? And it is random at some degree. Now the idea is, the way these diamonds work is that decisions about whole diamond level stuff like motion and growth happen at the center of the diamond. And that control code is designed that they want to see them move. When it sees the center move, it resets this timer that keeps everything going. And when things jam up, the timer does not get reset. And eventually it's, the timer's got some randomness in it. Eventually one of them reaches, it's I give up and it kills the diamond and that creates more space. But again, there's no actual wall clock timer that's being provided to these things. These individual sites on the individual tiles, they don't know any kind of absolute time. That would be unscalable exactly the same as if they knew their exact coordinates in space. They don't know either of those things. All they know is when they get an event. And an event is random, events are asynchronous, but that doesn't mean that every site gets the same number of events. And in particular, when an event happens toward the edge of a tile and intertile event, those take longer because of the communication and coordination necessary between the tiles. Whereas an event that happens all in the middle of a tile that requires no communication starts and finishes much quicker. So you get many more events happening in the middle of the tiles than you do at the edges. And as a result, in effect, time runs faster in the middle of the tile. So if you look at these, so this one, you know, the middle of the tile is right about here and the middle of the diamond is somewhere around here. It's not exact center, but it's fairly well centered. This one, same thing. It's kind of the center of the diamond is not too close to the edge. This one, this was in the lower left. This one, the shore, you know, the diamond, you know, right in the meter that, well, actually that one's even a little close too. So time runs at different speeds at different places on the grid. That's really weird. That's like science fiction stuff, but that's what we signed up for when we were going for indefinite scalability. And how is that actually gonna end? The big picture? Hopefully it'll end because I end it because we have code to run that we wanna do instead. At the moment, we're just continuing to stress test with the growing diamonds. So we shall see. All right, we are at T minus five on the artificial creation countdown. And you know, that means, you know, we are at the halfway mark and we've got five updates before us, five updates after us. We're not quite at the halfway mark in terms of days because we have this big chunk of time in November where we do not have updates scheduled, but we're increasingly far behind. We were supposed to have the H3 sequencer in August. We didn't. We're supposed to have state machines in September. We don't really. So, you know, last time I talked about the T2 tile or report and I had lots of detailed stuff, but afterwards thinking about it, what I realized was, you know, yeah, whatever, I don't really care about those. The main thing I care about is public embarrass and then if I'm caring about that, why am I, you know, YouTube videos, live streams and so forth? Well, of course, because that's the way to keep myself focused and actually try to make progress and not just say, oh, yeah, I'll do it next year. Once I got as far as thinking, well, what I'm really afraid of is the, you know, the nightmare and the going to school in my pajamas. Then the response to that was, well, you know, yeah, I might make a fool out of myself or screw up the audio settings and so forth, which I still can't do very well, but I'm still convinced that the underlying ideas definite scalability, robust, first, best effort, those are good ideas. Those are ideas that are underserved but in our current technological, digital computing, information technology environment and we need to get them out there. So that just leads me to the fundamental feeling that, well, okay, I can be an embarrassment, I can moan and groan and people kind of go, ew, you know, just back away slowly, but my job is just do the work and put it out there and then we'll see what happens from there. So that is the title card for this time. I mean, we don't have a specific technology to go after, so we're just saying it's the halfway point of the countdown between T minus 10 and T minus zero and for me, the takeaway is just do the work. Okay, so for this time, we were supposed to have a self-copying program demo, ha, didn't get close, a loop reshaping demo didn't get, but I sort of got something that's related to it, have some fun, you know, well, it was a little bit challenging, the last kind of updates because there was a lot of frustrating stuff. So we shall see. What I wanna spend a couple of minutes on here, I'm determined not to go along is to talk about spatial programming in one dimension. Well, wait, the T2 tile is two dimensions and everybody complains, why isn't it three dimensions? But in fact, it's nested structures at all different scales and when we're talking about programming, which is what I've been focusing on exclusively, we're using these pocket chain loops which are laid out in two dimensions but they are logically one dimension. There's next and previous and next down the loop and it really doesn't care where it is and what that led me to the realization was was that for a long time I was against abstraction and because abstracting away space as we did with CPU and RAM, random access memory abstracts away space location 100, location a billion are equivalent. You can put anything in one, you can put anything in the other. And the, but the guilty party is not the abstraction, the guilty party is discarding space wholesale. What we wanna do is do space preserving abstraction, maps and increase scale slowly. And as we increase the scale, we have more stuff that we do not wanna deal with ourselves, so we wanna delegate the spatial details and whether the lower level deals with it by performing searches or it caches to remember what it needs to do, whatever, that's not our problem. As we climb up the levels of larger and larger scale to become more and more abstract, which we still do want. So we've already got, we've got a lot of levels of abstraction already in the Moogle Feast Machine from individual sites, you know, where we have tiles full of individual sites to the idea of the HC3 diamond with individual pockets and we in fact search through the pocket to find the contents there each time we need to do it. Is that less efficient than knowing the exact one? Yes, but it's more flexible, it's more abstract. And now we're taking it to the next level of actually, you know, creating languages for describing what happens along the 1D chain where now we're ignoring the pocket structure, it's all just next and pre, we don't care whether it's up, down, left or right and the sites are gone. And so what, you know, I don't have a real language for it but I started to work on a little bit of notation, you know, we've got a few basic ideas. X is a content carrier on the pocket chain. Y is another pocket chain, a kind of carrier and X is specifically one of the things that we have to be careful of. That's gonna be an instruction in the program. The Y is gonna be either an instruction or just a temp like that, we don't care. And EC is an empty codon. So we can make rules that we say, you know, if you've got an important one and one that might be a temp or an important one followed by an empty codon, you can swap the important one with the empty codon. And the important point there is that the empty codons don't affect the ordering. As long as we don't swap any X's with X's or X's with Y's, we will keep the underlying ordering of the program. We'll just have more or less empty stuff stuck in there to fluff up the loop because we want the loop to be fluffy but not floppy. Fluffy means that we have empty space in between so we can move things around to get them forward and get them backward where we need to do. But floppy means we have tons and tons of empty stuff which means when we need to drive something that counts all the way around the loop, it's gonna be very efficient. And so I've implemented a bunch of these rules and code, so there it is. Pattern Y, pattern X, pattern empty codon and so forth and pretty much directly reflect the rules. So that's the kind of design that I've been working on in the last couple of weeks and that's the reason why we're busy making the program chain the one-dimensional representation that's gonna hold the program. We're making that more able to take care of itself. Okay, and we have a couple of minutes maybe we could take, all right. So here we've got a diamond that we've already started. I have gone in with a scalpel and removed fee. So I've got a thing called insert here. All right, so here's an insert zong atom and if I give it an event there. Okay, what did that do? That just looked around to find an empty codon that's the EC and converted into a zong which is just a debugging type that I've developed. And you know, all right, so now if we can let this thing run I suppose we should change the, go to the right. So now what we've got is we've got two loops each of which consists of, so we can't really tell it, one empty and one zong. And what's gonna happen if we let this thing run for a while, which I don't know if we can really afford to take the time unfortunately. These things will eventually they will grow out because they'll use those rules where they've discovered that, aha, there's not enough work, we're kind of crowded. So we've got a zong and an empty and we'd like to have a little more empty. So it'll go ahead, I hope, maybe I'll leave this running it and we'll come back to see if it's actually managed to spring any of them things. Well, actually, I guess we could look at a little bit. I've got a clip. All right, this is a one that I set up ahead of time that we can just look at. And so here, it's already growing out to a bunch of slightly bigger stuff. And eventually, this is gonna pick up speed and go faster. All right, there we go. And so then we can kind of see it that the four loops are not filling the entire diamond. They're not even filling their own quadrant anymore because now they're only getting as big as they need to to be fluffy but not floppy, given how much actual content there is in there. And each one of those loops has three zongs in it. So it grows out to about double two or three times. It's local, it's random. So they get a little bit floppy but I don't feel too bad about this. All right, so that is that for next time. The goal is to have the actual programs that are living inside this, to take care of itself. Think, spike, assembler and loader, we shall see. And please, please, please have some fun. Yes, folks, thanks for coming and taking a look. We are the halfway point. We shall see how it goes. I hope to see you next time.