AISC 2025

Summary: If you make it a game where you can solve the game by detecting the patterns, but you don't know how to write an algorithm that would detect the patterns in the same way you do, then you can learn how to write a new kind of algorithm that performs some cognitive task that you don't yet know how to write.

One of the main things we want to get out of the first game is for you to invent an algorithm. The goal is to optimize the game such that:

1. Exhaustive search is intractable
2. A human can learn the game and then beat it consistently within ~1 minute.
3. You don't know how to write the computer executable code that would solve the game.

Now you can play the game a bunch and instrospect on your own cognition. The goal is to get evidence about what computations are you running in your brain that make you solve the problem. The idea is that we can use these bits to discover the computer executable code that solves the game faster.

The learning goal is to train the general skill of extracting a computer executable program from introspecting our own cognition.

For this exercise it doesn't matter whether somebody else has already come up with an algorithm that solves your game. It's only important that you don't know about it, and that you don't look it up, but find it through introspection.

Example:

The most important thing about the game is the mechanics, how does the player interact with the game. That's the thing we want to get at. And we don't want to get up at high-level descriptions of a fire extinguisher. We don't want to tell a story. We want to get at how the program works, how the player interacts with the program.

See Extracting Algorithms from the Brain to solve Negar's Cylinder Game for a concrete demonstration of doing this.

There are different levels of extracting brain algorithms. E.g. Negar did write down the algorithms that would play her cylinder game perfectly for every possible situation, and for every situation where there is no solution she proved that this is so.

This we could call a level 1 algorithm. An algorithm that given any stating configuration of a game with fixed rules will solve that game or say that it is impossible. We can call an agent that just executes a constant action sequence that works in only one particular starting gamestate a level 0 agent.

The next step is to find higher level agents. A higher level agent would not start with the hardcoded alogirthms that can solve any game. Instead it needs to learn these algorithms themselfs.

We can call a level 2 agent, an agent that knows:

• We know the goal.
• We know the exact rules of the game.
• We know what each action does.
• We know the current game state.

We also assume that:

• The environment state only changes when the agent takes an action.

This agent can perform tree search to find the optimal action sequence. Now we want to adapt the environment that such tree search is intractable. We then want to find general algorithms that can learn the structure of the game.

Again one way to do this is to introspect on how you are going about learning the game. Try to extract these cognitive algorithms.

I expect that at the core of this lay general algorithms to construct models.

It's pretty unclear what a model is supposed to be here. We may say that:

• A model allows us to predict how the world will behave.
• Allow us to reason about the world at a high level.
• Contains a list of properties that hold of the game.
  • E.g. that taking action 3 as many times as possible is a property of any optimal solution for Negar's Cylinder Game.

Another strategy:

1. Implement an algorithm A1 that solves the game.
2. Implement the algorithm A3 that you ran to produce the algorithm A2.
3. Implement the algorithm that you ran to produce that algorithm A3.
4. etc.

Everybody really confused about alignment. What is intelligence? How can you make a powerful intelligence "want" what you want? Does this question even make sense? So it's tempting to think "Before doing something as concrete as write source code that is trying to answer a question about alignment we need to deconfuse ourselfs. Without deconfusing ourselfs we are bound to write useless code, because we don't even know what question need to answer."

Hypothesis: This is confused. When somebody thinks like that they are imagining using programs in a very particular way.

There are different ways in which codifying your ideas can be helpful. Once you already have an idea you can codify it to see whether it actually works. This can be very useful, but if all your ideas are very confused you'll likely simply fail to write the code. Coding is hard and you might waste a lot of time.

But instead of using programs to express an already generated solution we can use them to augment the solution finding process. On way to do this is via very generic cybernetic augmentations, such as:

• Writing an idea in a digital text document allows me iteratively refine what is written.
• Setting a daily alarm to remember to do sport.
• Transcribing a conversation with whisper in realtime allows me to remember how we ended up at a particular topic, and we thought it was important.

These are great but these are not what I am interested in here. Let's start with examples of the thing I am interested in:

Example - Interactive Video Explanation of Quaternions

3blue1brown and Ben Eater created an interactive video explanation of quaternions. At any point you can pause the video and mess around with the definition of the quaterion, which changes a 3D visualisation of a quaternion in real time. Playing around with quaternions like this is a good way to build intuitions.

Now imagine the scenario where you don't really understand quaternions, but understand them just enough to create a similar tool that allows you to interactively explore quaternions. You can now use this tool to discover new facts about quaternions, and build intuitions about how they behave.

Example - Cantor Dust

An example in this direction is cantor dust, a binary visualisation tool, that allows you to determine whether a sequence of bits is x86 machine code, a png, text, etc. by reprenesting the data in a format that the human visual cortex can process.

Imagine you want to create a taxonomy of file formats and you can't lookup what file formats exist. You can use this tool to inspect many files and quickly identify when you are looking at a file format that isn't in your taxonomy yet.

Example - Blender

When manipulating a mesh in blender you immediately see the effect of your inputs as you make them. Blender also has many settings for how to display geometry. You can move the scene camera, render objects as wireframes, show vertex colors or weights, display various gizmos. It it's video editor you can enable real time displays like a chroma vectorscope, or color histogram, that make color grading easier. As you change the color grading these real time displays immediately update. And all this can be done while playing the video.

Blender is an example of a program that facilitates the interative, interactive creation of various artefacts. One interesting program we might want to create, is one that similarly facilitates the creation of some specific artefacts, such that through the creation and inspection of the artefact we can learn something useful about e.g. alignment.

I want to create computer programs that we can explore in order to learn new things to increasing the bandwidth between the researcher and reality. We want to create interactables that when explored give us new bits of information about alignment relevant concepts.

What follows are a bunch of less central examples that still provide evidence that learning from programs can be powerful.

Example - Game Development

In game development you often start with an idea, implement it, and then notice that the game is fun a way you didn't model at all. GTA was originally meant as a police simulator, but then the developers realized that it's much more fun to run around and cause havoc in the city.

In general good gamedevelopers develop a game through constant conversation with the game. It's simply too hard to perfectly predict how it will feel like to interact with specific program. But that isn't to say that your models don't improve. By making many games with such an iterative feedback loop your models of what makes for a program that is fun to interact with. You'll still be suprised, not as often, and not as much.

Example - Stephen Wolfram Investigating Cellular Automata

Stephen Wolfram studied cellular automata for a long time. Often he describes the phenomenon of computational irreducability. He has a model of what the cellular automaton will do but his predictions regularly fail completely. He discovered once a cellular automata that was so random, that it was used for some time in the wolfram's language random number generator routine.

Note that this is not an interactable.

In general sometimes it is simply easier and faster to express an idea as computer executable code, to get our bits. The computations that generate interesting observations are simply too complex to be run in the human brain. Or at least doing so would be much slower.

I don't like how Stephen Wolfram is using the term computational irreducability. Clearly it's a real phenomenon, but when he fails to predict a cellular automata it could also be because his model isn't as good as it could be. And perhaps he thought longer and harder he would be less suprised, like in game development.

Example - Natrual Selection

Primer is constantly suprised about what outcome natural selection will produce. When you are suprised about something it means that your model isn't that good. Whenever you can create a computer simulation that suprises you, it's a potential learning opportunity. See also The Tragedy of Group Selectionism.

This is another example where you are are constantly suprised.

Note that this is not an interactable.

Example - Monty Hall problem

The Monty Hall problem is very unintuitive. There are people who argued at length that it doesn't matter whether you switch. Seeing through why you should switch is hard. But it's pretty easy to implement a stochastic computer simulation of the problem. By running it you can see that if you switch you are more likely to get the car. If the monty hall problem where unsolved, we can now with confidence try to understand why you should switch, because we now know that such understanding should be possible.

This is an example where the logical reasoning is harder to do than writing a simulation.

Note that this is not an interactable.

In terms of how to use this for alignment here is a rough idea for an interactable that might be useful for making process on the Tiling Agent Agenda.

I expect it to be much more fun, and also trains you being creativity.

Besides training how to design and implement information rich software environment Measurement_Devices">"microscopes" that we can get useful bits from, I expect you'll learn other generally useful skills for research:

• Expressing your ideas in code
• Refining your ideas in conversation with the code that expresses your idea.
• Become good at thinking about and designing algorithms

Interactive programs can also be useful in different ways. One can design a game such that you yourself can solve it using your brain, but where you don't know the algorithm that would solve the task. Now playing the game yourself and observing how you are going about doing things can give you many bits of informations that help you in desiging an algorithm you couldn't before.

This is a demonstration for how you can discover an algorithm by playing a game where you don't know the algorithm for solving the game, and then introspect on your own cognition.

To get the most out of this video it's reccomended to first understand Negar's cylinder game, preferably by playing it. Take the python source code and run it. The game explains itself when run.

Here is also a video of going through Havel-Hakami but this is less important than this video.

Chapters:

• 0:00 Describing what we did previously: We can solve a subproblem with havel-hakami. New objective: We want to solve the remaining problem by extracting the algorithm our brain executes when we play the hame.
• 1:52 Playing the Game.
• 2:16 Writing down the strategy in code: Don't revisit states.
• 2:42 Writing down the "computation trace" for what Negar did when playing the game.
• 3:49 Johannes figures out how to solve a specific subproblem, and we then iteratively codify the algorithm.
• 5:46 We give an "intuitive proof" of why this algorithm is optimal in solving the subproblem.
• 6:39 Describing the outcome: We managed to extract simple algorithm from our brains. Probably this was faster than if we had thought about it abstractly.

Here is an a video of Gustaf working, edited with auto-editor. (Original video length >1h.)

NOTE: The video is slightly broken by auto-editor because the audio was not normalized.

Most important feedback: Reflection is good. But here I think you did to much abstract reflection in advance. In some sense you haven't started the exercise yet. I expect it to be much faster you just start doing the task even while you are still confused. This forces you to focus on resolving the confusions that are most relevant for the task. Reflecting on a concrete task you have already attempted to do, gives you a lot more bits to work with.

Misc feedback:

• 4:30 First going through the constraints and making sure that you understand them is good. Restating them in your own words seems like good general strategy.
• You mention that in my demonstration video I did shoot myself down a lot less, and that therefore I could iterate more on my ideas. It's worth noting that I didn't do this on the object level that much, but I did do it a lot on the meta level. Especially in the beginning I did notice multiple times that what I was doing was too abstract and that I should do something more concrete.
• Setting reflection timers seems very good.

Ways in which the Video Recording itself can be improved:

• Normalize Audio (see OBS Audio Filters)
• Make the text on screen larger

When talking to Gustaf we realized that the bottleneck was that he didn't want to generate a game idea. That's why he thought about it abstractly. Partly because he didn't know how to generate one.

I did the following exercise with him for ~10 minutes:

1. Johannes: Say a random word.
2. Gustaf: Tomato.
3. Johannes: Turn the tomato into a game.
4. Gustaf: The player could draw a tomato.
5. This could be done with bezier curves.
6. Or maybe the player needs to just draw a circle.
7. Maybe you have shapes like circles, triangles and squares and you need to build a bridge.
8. Maybe the player has a bunch of shapes.
   1. The player selects a shape, and a color for the shape.
   2. The background has an image.
   3. The player needs to place shapes ontop of the image such that the placed shapes approximate the image as closely as possible.

Afterward he had what I'd consider a novel game idea.

The following settings ensure that the audio has the right volume and that noise is removed. This is important for auto editor to work correctly. You need to tweak the gain setting such that you don't max out the audio meter when speaking. All other settings can stay the same.

To add these filters click on the 3 vertical dots next to the audio bar:

And then select filters.

The videos become a lot better when we cut out the silence. auto-editor is a tool that can do this automatically for us.

I can also do it with the video you send me, but if you do it yourself it's even better.

Here is how you can use auto editor to cut out silent parts, but keep silent parts where something on the screen changes.

auto-editor --edit '(or audio:4% motion:0.0018,blur=0,width=1920)' some-file.mkv && auto-editor --edit audio:4% --silent-speed 6 some-file_ALTERED.mkv

When sending the video files please send them as a whole, using some service like gdrive (don't send them in element).

Especially if you are on a Mac your display resolution might have a higher resolution than the default canvas in OBS. Left click the preview -> right click the preview -> transform -> fit to screen, or Ctrl+F after left clicking.