 The T2tile project is building an indefinitely scalable computational stack. Follow our progress here on T Tuesday updates. Top stories this week. Last week, saying the proposal deadline to send a tutorial to ALIFE 20 was January 17th, which would be this week. I double-checked with the organizer, Juniper Lovato, and no, that was a mistake. It is indeed February. Okay. Also, last week, I had this crazy thing where I did the red keymaster, the keymaster in a red case. It wouldn't seem to do the touch screen unless I fussed with the corner screws more than I expected to. Watching the video last week, I did notice one thing that was a little bit strange was that the keyhole, the screw holes for mounting the board, the bugle bone onto my circuit board, I hadn't actually screwed them in on the red keymaster. They aren't strictly necessary because there's so many pins that the board gets held down really solid, but I wondered if that was it. This is what the red keymaster ended up looking like last week. It's pitiful little red buttons. I disassembled the whole thing again, and indeed the screws were not there. I put the screws in all four corners, put it back together again, and actually it worked a little better, but it didn't work 100%. So I'm not clear whether that was really the story or not, but I still had to back off on the case screws more than I expected. I do wonder if it's possible that there's some little crud, you know, a little plastic glob that's pushing down on the circuit, on the touch screen, the resistive touch screen, so the kind that it is. I'll have to check that in the future, but at the moment the red keymaster has a red case, and it is working, so we'll see. Keeping an eye on the academic hardware, computer hardware, Shulman and the Gitter put a link to this Solarity Network on Chip, took a look at it. 496 cores, and they're arranged in a 2D grid. They have a nearest neighbor connection as well as routing abilities. There's a lot to like about this. I mean, this is an academic research project sponsored by DARPA under a bunch of different universities, but it's got these rocket cores, these five big processing cores, and then these hundreds and hundreds of these little risk-5 vanilla cores, each of which has its own instruction memory, data memory, those are a little bit tight, but it might be enough that you can actually do something fairly cool with. And, you know, it looks like a tile. They call it a tile. Each one of those little dots is, you know, instruction and data cache and a CPU and everything right there, network routing and so forth. It's always disappointing. Going off of the grid of little 496 cores, it only goes out through one edge. So if you wanted to get from this guy just to get to the big cores, let alone getting to another chip, adjacent chip, you actually have to bottleneck through one side because, again, as always, as the case is, the computer hardware that we see, you know, prioritizing indefinite scalability is never what they're about. So, you know, we have to have our own 20 million DARPA program at some point. Well, who knows? It always breaks my heart. There's so much to like about this thing, but, you know, there's no way. Well, who knows? But they threw away their geometric 2D bandwidth by necking it down to just one edge. Also, the Scientist magazine, online, I'm not sure if it's in print as well, a paper came out of embargo today, I'm sorry, Monday, coming out in PAS, receiving the National Academy of Sciences, about using evolutionary techniques for soft robots to design robots that are supposed to move and then using frog cells that are teased apart and glued together and stacked up to mimic the shape that the computer evolution had picked and then seeing how well it works. And so these guys wrote up a lot of places covered it. The Scientist was one of the covers. Why do I mention that one specifically? Well, so, you know, this work was done by Michael Levin, who was the guy that did all that crazy planaria stuff that I talked about a few months ago at the SFI workshop on biological computation and living systems, whatever that was called. That's Michael Levin, the same guy. Another one, Josh Bongard, is another one of the A-Life guys doing more of the evolution side these guys got together and did this, you know, crazy stuff that was reported in PNAS along with their students. The reason I mention it is Emma Yazinski, the author of this review, this news thing about the paper, got in touch with me over the weekend and I contributed a blurb. The work is in its earliest stages, computer science. This is a marvelous proof of concept demonstrating how the artificial evolution of mathematical soft robots can guide the design of the functional biologists. I close the piece. You know, these things all have to have the same format. You've got to get a reaction from somebody who's not involved with the work. And that was me. And they have to, you know, say something about the limitations of the thing and so forth. So I ended up becoming the guy. Normally, when I get these requests, I never respond to them quick enough and they go on and then pick somebody else or whatever it is. I tried to do harder and, you know, turned around some comments. That was the first sentence of like three paragraphs that I wrote for. You know, that's fine. It's the way it works. I was giving them material to write with. So I'm a big pundit now. So that happened. All right. And I've been thinking a lot about programming because I've been doing a lot of programming, especially for the bond stuff, the chemical bond things, which I'm trying to do for a live 2020. And the thing that started to come through to me is that I want to think about this programming. I want to think about creating systems, computational systems, living systems, as not as being sort of arbitrary pointer instruction set, jumping all over random access memory, but in terms of phases or turns or sequencing and that the act of creating something is an act of sequencing stuff rather than general arbitrary programming and loops and running around and jumping up and down and so on. So my slogan is system sequencing is greater than computer programming. In the background image there, that's a jack-hard loom that was sort of emblematic of the early days of programming where you'd have these cards that would step through a little reader that would have pins and for each one that had a hole in it, you'd get a thread that would go up or down or whatever it was. And once you had programmed these cards like a player piano, you could weave extremely complicated fabrics on the jack-hard loom. And so this is the idea of sequencing and I'm not completely sure I understand it all, but really what it comes down to, oh I lost, I had some notes here. Yeah, there we go. So from one point of view, in a computer every time you execute an instruction, the lowest level, there is a sequence there, there are phases there. You load the instruction, you increment the program counter, you decode the instruction and so on. There's a whole pipeline of things that are going on for every single instruction. So that's not quite what I mean by sequencing and that's why I'm calling it a master sequence, that the idea is you figure out what the system is supposed to do and you express that whole behavior in terms of a sequence of fundamental steps. Whatever level is appropriate, the key is to keep doing it sequences at higher levels rather than just saying, well, we've got a sequence for each instruction and then above that, who knows? You can go around in loops, you can do function calls, recursions, never come back. The advantage of building an explicit sequence with phases is that you can have touchstones. When something goes wrong, you can fall back to the beginning of the previous sequence. If that self-check doesn't pass, you can fall back to the beginning of the previous one and so forth and that's without necessarily having gotten there from any particular path. When we take deterministic execution, we think we have to do each exact step in the sequence and if we miss it, who knows? We're completely lost. But if we have these landmarks, these beacons, these phases at every appropriate level, then it gives us a place to go, it gives us an anchor and that's why sequencing is better than programming and for robustness that's one of the things that I want to keep in mind. What do you think? Do you see what I'm saying? Am I completely nuts? The idea is just as if you want as much synchronization as needed to do the problem but no more rather than completely assuming a totally synchronized universe up front, the same thing is you want the flexibility. So like in Splat for example, there's a sequence of steps. The given, the vote, the check and the change, the four phases that happen in each time and those are important because it limits the flexibility of what can happen in an event. Sometimes that's aggravating when you're being a programmer and the art of doing the programming language design is to be able to have more complicated things happen during the givens, during the check. Voting, checking and changing to get more done but you still have this fundamental rhythm that's going, the sequence that's going over and over and over again and that wants to carry up into the higher level. So this week I was working on the bond stuff and trying to get a clean design, a clean software design for doing bonds in fairly general ways and I'm thinking that's going to be the scientific submission for the A-Life 2020 paper. Hopefully we'll have a little more news about that next week at this point I'm still doing infrastructure stuff but it's looking like it's got potential. But all of these things just keep coming over again. The boot sequence that I talked about a few weeks ago going all the way back to CCR in the 90s and then the boot sequence for system D and all these guys. It's a sequencing. The single event window has all these phases in it. The intertile connection, intertile event stuff that I was also working on this week has this sequencing. It's a state machine but it's not just a rat's nest of spaghetti everything pointing at everything. There's this axis of progress, the sequence that it's going through that when things go wrong it collapses back systematically and bonds that I just mentioned. So system sequencing, so I stick system in there to get out just the idea of not just teeny little loops but at all scales. System sequencing is greater than computer programming. It is now six weeks to the scientific deadline. I'm going to go after clean bonds. We'll see what happens as far as getting folks... I'm really hoping folks will be able to... I know there's a bunch of people out there who have played with Ulam, who have played with Splat and that's great. I mean I also really love the folks that are like the Sam Boy Saga, Luke Wilson. Are you tracing his stuff? He's doing 3D Splat stuff. It's very cool. In fact some of the things that he's done in his programming language design I would think about stealing for future versions of Splat but specifically for running on the grid stuff that's written in Ulam and Splat would be incredible. So that's it. It felt like I didn't have a whole lot to say but of course I soak up all the time anyway. We'll see intertile stuff and bond stuff next week hopefully for sure. That's what I'm putting on myself. You have a good week. Hope to see you next week.