A programmer's view of the Universe, part 2: Mario Kart
This is the second installment of a little series of discussions. They're not much more than that, just discussions. And I hope I'm inviting discussion rather than quenching it. But I'll be honest — the goal of this series is to pound a stake through the heart of a certain way of thinking about the world that has become quite popular. If my series fails in that regard, I hope it may still provide some entertainment value.
Part one, The fish, was about a twisty line and a fish's examination of it. Today we move to a twisty plane.
Embedded Systems
There are many kinds of computer programs, and many ways to categorize them. One of the broadest and most interesting program categories is embedded systems. These systems are the centerpiece of today's little chat.
Embedded systems are a bit tricky to define because they come in so many shapes and sizes. Loosely speaking, an embedded system is a little world of its own: an ecosystem with its own rules and its own behavior. So an embedded system need not even be a computer program: a fish tank is also a kind of embedded system.
We call them embedded systems because they exist within the context of a host system. The host system provides the machinery that allows the embedded system to exist, and to do whatever it is that the embedded system likes to do.
For fish tanks, the host system is the tank itself, which you may purchase from a pet store. A tank has walls for holding the water in, filters and pumps for keeping the water clean, lights for keeping the fish and plants alive a little longer, and access holes for putting your hand through to clean the tank. There's not much to it, really. The embedded system is everything inside: the water, the plants, the rocks, the fish, and the little treasure chest with bubbles coming out.
For computer games, another popular kind of embedded system, the host system is the computer that runs the game: a PC, a game console, a phone, anything that can make a game exist for a while so that you may play it.
Programmers have been building embedded systems for many decades: a whole lifetime now. It is a well-studied, well-understood, well-engineered subject. Gamers understand many of the core principles intuitively; programmers, even more so. But in order to apply all that knowledge outside the domain of embedded systems, we will need some new names for the core ideas.
The most important name is the One-Way Wall. I do not have a better name for it. It is the most important concept in embedded systems. In lieu of a good name, I will explain it to you, and then the name will stand for the thing you now understand. It's the best I could come up with.
But first let's dive into an embedded system and see what this wall looks like from the inside.
Mario Kart
I will assume you've played Mario Kart, or you've at least watched someone else play it. Mario Kart is the ultimate racing game in terms of sacrificing realism for fun. It bears so little resemblance to reality that it's a wonder it tickles our senses at all. The Karts skid around with impossible coefficients of friction, righting themselves from any wrong position, and generally making a mockery of the last four centuries of advances in physics.
It's really fun.
Mario Kart, like all games, has a boundary around the edge of the playing area. In Mario Kart you bump into it more often than in most other games, which is part of the reason I chose it to be our Eponymous Hero. If you want to win a race, you will need to become quite good at accelerating around corners, which means you will spend a fair amount of time bumping up against an invisible wall.
You know the wall I'm talking about, right? It's invisible, so you can see right past it to the terrain beyond. But the wall is there, and you are not permitted to venture beyond it.
In slower-paced games, when you arrive at the invisible map boundary, you will sometimes be told by the game: "You can't go that way. Turn back!" And since that is your only option, you comply. These invisible boundaries are non-negotiable.
In other games, you may stop on contact with the boundary, or perhaps bounce off. But the boundary is always there.
Imagine Mario and Luigi chatting about the you-can't-go-that-way wall. Their conversation might go something like this:
Mario: "Luigi, my brother!"
Luigi: "Maaaarioooooo!"
Mario: "Yes, Luigi. I am a here. Tell me my brother, why is it that every a time I a spin around the cactus in the third a bend of the Desert a Track, I get a stuck and have to start accelerating from nooooothing?"
Luigi: "Whaaaaa?"
Mario: "Brother, the Desert a Track! It's Number a Three! You know the big a bend, where you have to slow down? I am always a forgetting to slow, and I just a stop. Just a like that!"
Luigi: "I don't know, Brother. That Bowser, he is always a squishing me right before I hit that turn, and I am a flat like a pan a cake for a looooong a time."
Mario: "What about that a time two races ago, where Wario hit you and you a spun around and you a headed for the hill, and you got a stuck and wailed for me?"
Luigi: "Ah, that Wario! I will get him next a time!"
Mario: "Why did you not just turn around then?"
Luigi: "My Kart, it did not a move, no matter how I wailed."
Mario: "That is a what I am a speaking of, Brother. Your Kart moves in all other places, but if you head for the hills, it just a stops a suddenly!"
Luigi: "I a hate a stopping a suddenly."
Mario: "Yes, Brother. So do I. But why can we not traverse that a part of the hill? What is on the other a side?"
Luigi: "I think it is Track 4, Brother. They do not want you to wind up in the lake."
Mario: "Whaaaa? Who is this a 'they'? And why can we a not see the lake from a Track a 3? I think there is a nothing there, Brother. Just a more hills."
Luigi: "No, my brother. I think it is a Track a 4. Or maybe Track a 2. There must be a something there."
Mario: "Perhaps you are a right, my brother. We should get a back to a racing now. We can talk a more about a this after the next a race."
Luigi: "Yes, brother. I will a get that Wario this a time!"
Well-formed nonsensical questions
In our Highly Realistic Dialog, Mario is wondering about the Invisible Boundary at the edge of the track. He asks his brother the seemingly obvious question: "What is on the other side?"
As a gamer, if you pause to consider the question at all, the answer seems to be: "Nothing I care about." The invisible (or sometimes visible) Boundary seems just like any other wall. It is designed to keep you in where you're at, or out of where you're not, depending on your point of view.
But the gamer's view is that the boundary does have another side. You have no way to get there, but it exists. For maximum gameplay immersion a game universe needs to appear consistent. Thus, when you peer through the wall it appears that the other side is just more of the same.
To an embedded systems programmer, Mario's question is complete nonsense, like a fish asking the temperature of the water on the other side of the glass. There is no water on the other side, and for that matter a fish can't ask questions, so the question itself is based on nonsense premises.
From a perspective within the Mario Kart universe, the "other side" of the Invisible Boundary is... a kind of nothingness. The embedded world quite literally ends at the boundary. The level designers usually try to make it appear as if the current world continues on, but this is an illusion. They discontinue the model's polygons beyond the line of sight. Put another way, the water stops at the edge of the tank.
The nothingness beyond the Invisible Boundary of an embedded system is much deeper and more significant than simply not having objects there. In that nothingness there is no programmatic substrate upon which to place objects. If you were to ask: "What lies between Mario's head and Luigi's head," the answer may well be "nothing", since no game objects may overlap the line between their heads at the particular time you ask the question. But that "nothing" is qualitatively different from the "nothing" on the other side of the Invisible Boundary. Between Mario and Luigi there is a space – a place in their universe where objects and forces and logic apply, even if they are Mario Kart's twisted versions of physics and logic. That universe ends abruptly at the surface of the boundary.
The question "What's on the other side" is well-formed in a strictly mathematical sense. You could project a line from Mario to the nearest boundary, and ask the more precise question: "If Mario is at distance D from nearest boundary B, what overlaps the point P obtained by extending the Mario-boundary line L to a distance D beyond B?" ("Whaaaaa?")
The new formulation of the question is more well-formed, but it is every bit as semantically nonsensical.
What's really on the other side
In the context of the Mario Kart universe, the system boundary truly only has on side, and Mario and Luigi are on that side. From their perspective, we can't meaningfully ask the question "What's on the other side?" However, there is a semantically significant interpretation of "the other side" of that invisible boundary. To get to this better answer we must leave Mario's universe.
From the perspective of an embedded systems programmer, the entire Mario Kart universe is data structures laid out in the memory space of some machine. There is a program — the game engine — that interprets the data in a way that makes it appear to be a universe that is similar to ours in various intuitively appealing ways, yet different from our universe in various fun ways.
It is very unlikely that the polygons and other level data are laid out in strictly contiguous order in the host machine's memory space. It is more likely that they are spread out, with gaps, like dominoes spilled on a tile floor.
The question "What's on the other side?", when viewed from the perspective of a systems programmer, might be phrased more precisely and meaningfully as follows: "What occupies the memory spaces adjacent to the memory used by the Track Three Desert Level?"
This is the same as Mario's question, but we had to step outside the Mario Kart universe in order to ask the question in a way that made sense. The Mario Kart universe, like most game universes and in fact most embedded systems, is designed to appear complete. There is apparently "stuff" beyond the boundary; you just can't go that way.
When we step up into the host system and ask the analogous question about the "other side", both the question and the potential answers become much more complex: many orders of magnitude more complex, in fact. Fortunately, due to the Mario Kart system being so simple, increasing the complexity still gives us a vaguely accessible problem.
Let's try to cook up an answer to this new, more complex question regarding the contents of the program memory space on the "other side" of the invisible wall.
In terms of atomic program units (say, bits or bytes), the amount of memory used by a game like Mario Kart is actually high enough to defy our sense of scale. A game with hundreds of megabytes or gigabytes of runtime data has billions of discrete elements, which is too many for us to keep track of individually. One of the key jobs of a programmer is to organize their code so that the elements can be managed at human-CPU scale: up to seven "things" at a time. But this organization can't mask the fact that billions of individual elements exist, each with its own role to play in supporting the embedded system.
Hence, even for a game as "simple" as Mario Kart, we're stuck imagining how it works internally. Even the programmers who built the game have only a dim and incomplete mental model of the game. It's like building a skyscraper, or a city: you build it a piece at a time, and it's rarely fruitful to try to picture everything inside of it simultaneously.
Anything that goes wrong or is out of place in the program could take days to track down with state of the art tools. That's just how it is. We're not able to comprehend large problems all at once; we can only attempt it in small increments.
Bearing this necessarily incomplete understanding in mind, what exactly would we find in the machine memory between the elements of Mario and Luigi's track mini-universe?
The answer is familiar to programmers and perhaps surprising to non-programmers. The answer is: almost anything. It could be elements of a different program, or random garbage not being interpreted by any program, or supplemental data for the Mario Kart universe, such as language translation strings. Or Luigi could be right: it could be Track 4, pre-cached for the next race. Perhaps not exactly the way he's imagining it, but... close.
Moving beyond the Wall
Our little visualization of the host system's memory raises another natural question: what would happen if you "zapped" Luigi's Kart across the boundary?
This question isn't entirely as nonsensical as "what's on the other side?" With the proper programming tools, you might be able to observe changes in the machine memory as Luigi's Kart moves, and these changes might follow an observable pattern that leads to a relevant prediction of sorts.
As just one possibility, Kart motion might be represented as shifting a Kart memory structure along the sequential indexes of an in-memory array. This arrangement is unlikely for performance reasons, but it's certainly possible, and should serve to illustrate the point. If you were to find that moving Luigi's Kart ten meters (in the scale of Luigi's track universe) resulted in a structure motion of 1000 memory addresses, then you might make the reasonable prediction that in another ten meters his representation would move another 1000 addresses.
This might well put him beyond the end of the physical memory array. In most real-world scenarios this would be a bug, and would result in some sort of nasty response from the machine, such as a game crash. Or in a more user-friendly environment, the game engine might simply prevent his motion in that direction and move him back into his universe. This might put his Kart in an uncomfortable position, but it will at least be a real position according to the logic of the Mario Kart universe. At least the Kart won't have disappeared.
However, it is infinitesimally possible that Luigi's Kart could be moved into another physical machine process in the host system — say, another instance of Mario Kart running on a time-sharing operating system or virtual machine — in such a way that Luigi and his cart physically disappear from the old universe (a process address space) and appear in the new universe (another process address space).
Even if this infinitely remote possibility were to occur, chances are high that the sudden appearance of Luigi and his Kart would wreak local or even global havoc in the new universe. He might get lucky and crush Bowser into a pan-a cake, but more likely he would wind up stuck in a stone wall or a hill, unable to move. Or even more likely, his Kart's memory structure would be copied into a non-game area, such as the translation string section, and Luigi's sudden mysterious appearance might manifest as nothing more than garbled speech from one of the other characters.
There are many possibilities, too many to imagine. The most important takeaway here is that no matter how unlikely Luigi's safe intra-universe migration may be, it is possible. With some external help from the host system, it would even be straightforward: perhaps no more than a few days work from a skilled programmer.
In real-world programs sharing adjacent address spaces, it's improbable (but possible!) that migrating data from one process to another in a randomly chosen destination spot would have semantically meaningful results in the destination address space.
To put it in simpler terms: under just the right circumstances, Luigi could teleport to the other side, and wind up in a different world.
Ghosts in the machine
An embedded system is a little environment. My Betta in the previous installment of this little series lived in a very simple embedded system. Its most obvious difference from my own environment is that the tank was filled with water, while my room was filled with air. The differences from the host system can yield different behavior and different rules. In the fish tank, the rules are only a little different — for example, most things are more buoyant inside the tank. In a virtual embedded system, the rules and behavior might be completely different from those of the host system. It all depends on how the embedded system was designed to work.
Every embedded system has a containing surface, which might be called its frontier. The frontier is one-sided in the sense that the rules of the embedded system may simply stop at the boundary: there is no "other side". In some embedded systems (such as a Euclidean space embedded in a non-Euclidean space), even the supposedly intuitive notion of extending a line across the boundary only has meaning on one side, the "inside" of the frontier.
If there is a formal mathematical term for this One-Sided Frontier idea, I've yet to come across it, and I've spent quite some time looking. If you have any suggestions, let me know. The closest I could find are the spaces that are undefined in noncontinuous functions, such as the Tangent function for a value of 90 or 270 degrees. If you ask a question
So the other side of the frontier is
If a computer program's code inadvertently reaches into
I have seen all these things happen. All C/C++/assembly programmers have seen bugs like this — program bugs with "crazy" behavior. The bugs are so spooky, and so hard to track down, that computers are now designed to be gatekeepers at the Wall, and when you try to step across they say STOP! It's much better to be blocked immediately than to let your program wander into
This computerized gatekeeping is commonly called "protected mode". The computer checks every addressing instruction, and any time a program tries to access the memory area outside its own, things halt immediately. When you see the message "segmentation fault", or a blue screen of death, or some other sign that a fatal, unrecoverable program error has occurred, it is almost always because someone or something in the embedded system tried to escape.
Holes in the Wall
From the perspective of a computer game, the system frontier is relatively uninteresting. It's not much different from any other obstacle.
However, in other embedded systems these frontiers are almost mystical in nature. They provide endless fascination for computer scientists working in the domain of programming languages, which are yet another kind of embedded system.
To see how it works, let's consider the situation in Mario Kart, which is simpler.
In Mario Kart, most of the racers are computerized opponents, or AIs. A few of them, usually at least one, are controlled by people, using steering wheels or other physical controllers. Sometimes (e.g. in simulation mode) all the opponents may be computerized.
In order for people to interact with the embedded system, there must be some way to send information back and forth across the system frontier.
Coming from the Mario Kart side, we typically have video and sound signals. The embedded system generates these signals and sends them to your TV or device.
Coming from the people side, we typically have motion input: which way to move the Karts. The signals begin as your physical motions: buttons you press, or in newer controllers, the direction you tilt the controller. They are sent from the host system to the embedded system and they generally produce observable effects in the embedded system. Like magic!
Mario Kart is especially interesting because the external camera is physically present within the game. You can see it in the instant replays of your races: a little guy with a camera, floating behind you on a little cloud. The game designers have arranged things so that you can almost never see him while racing, because he's always flying behind your head, along your line of sight.
But he's there. And in fact that camera is always there, in all video games. It's just that the Mario Kart designers have chosen to reify him as a cute little turtle guy with a camera, floating behind you on a cloud.
The external camera is a one-way hole in our one-way wall: it sends data out of the embedded system. For all intents and purposes it also sends the sound data, since the sounds are usually scaled as a function of distance from the camera.
During a race, there's a lot of stuff going on in the embedded system, and there's a lot of stuff going on in the host system. But they constrain their communication via mostly-invisible channels, and these channels are restricted in the kinds of communication they may convey. Your controller can send motion inputs, but (at least today) it can't send video data. And (at least today) the characters in the game can't control your arms and legs, the way you can control theirs.
Hopefully now you should have a mental picture of this magical wall between an embedded system and the Great Undefined Beyond on the "other side" of its system frontier. The wall may have deliberate holes in it: channels, really. Information may flow across these channels in predefined ways. And the channels are almost always invisible to occupants of the embedded system.
Reflections
I've spent a lot of effort telling you about a rather strange, twisty kind of surface: the frontier of an embedded system. This frontier exists for all embedded systems. It may have "holes" (data channels) in it. The number and nature of these channels is entirely up to the designers of the embedded system. Programmers sometimes call these channels "reflection" or "metaprogramming".
The holes in the frontier may or may not be detectable within the embedded system itself. They may only be detectable within the host system. This, again, is up to the designers. For most of the embedded systems I know of, the channels are "well defined", in the form of application programming interfaces offered to either the embedded system or the host system for communicating across the frontier.
But you need a channel for this kind of communication. Setting it up is usually not cheap. And setting up meta-reflection (in other words, being able to "see" the channel from within the embedded system or host system) is even more work.
So most of the time, channels through the embedded system frontier are completely invisible and undetectable from inside the embedded system. They're quite real, and information flows either one way or both ways, but they cannot be detected from within the embedded system, and their behavior is intrinsically non-repeatable via experimentation.
When data comes across these invisible channels, stuff "just happens" in the embedded system, with no clear indicator nor explanation as to why.
In our discussion so far, I have intentionally blurred the distinction between the host system (such as a fish tank or a game console device) and the host system's host system (such as your bedroom or living room). But you've probably noticed by now that all host systems are embedded in some larger system. This is just the way things work. The fish tank is in your bedroom, which is a system embedded in a house, which is a system embedded in a neighborhood, embedded in a county, a nation, a continent, a planet, a solar system, a galaxy, a universe.
It's perhaps not as clear in the case of fish tanks, but host systems often overlap and even cooperate. A city is composed of many interleaved subsystems. So is your body. It's not always a simple containment relationship. Systems are made of, and communicate with, other systems.
But one way or another, all systems are embedded systems.
There is no reason to assume that our Universe works any differently. Our Universe is a system; that much should be self-evident. It has boundaries; astronomers and astrophysicists have recently even determined that the boundary appears to be a dodecahedron.
We are already painfully aware of the question "what happened before the Big Bang, if in fact the Big Bang occurred in the way all the evidence suggests", and its inherent nonsensicality. What happened before the beginning of Time? What lies beyond the end of the Universe?
Programmers already know intuitively the answer to these questions. The answer is:
This has ramifications for the way we think about things today.
I believe I will have more to say about this soon. Right now I think I will go play Mario Kart: a game as fun as any I think I've ever played.
Part one, The fish, was about a twisty line and a fish's examination of it. Today we move to a twisty plane.
Embedded Systems
There are many kinds of computer programs, and many ways to categorize them. One of the broadest and most interesting program categories is embedded systems. These systems are the centerpiece of today's little chat.
Embedded systems are a bit tricky to define because they come in so many shapes and sizes. Loosely speaking, an embedded system is a little world of its own: an ecosystem with its own rules and its own behavior. So an embedded system need not even be a computer program: a fish tank is also a kind of embedded system.
We call them embedded systems because they exist within the context of a host system. The host system provides the machinery that allows the embedded system to exist, and to do whatever it is that the embedded system likes to do.
For fish tanks, the host system is the tank itself, which you may purchase from a pet store. A tank has walls for holding the water in, filters and pumps for keeping the water clean, lights for keeping the fish and plants alive a little longer, and access holes for putting your hand through to clean the tank. There's not much to it, really. The embedded system is everything inside: the water, the plants, the rocks, the fish, and the little treasure chest with bubbles coming out.
For computer games, another popular kind of embedded system, the host system is the computer that runs the game: a PC, a game console, a phone, anything that can make a game exist for a while so that you may play it.
Programmers have been building embedded systems for many decades: a whole lifetime now. It is a well-studied, well-understood, well-engineered subject. Gamers understand many of the core principles intuitively; programmers, even more so. But in order to apply all that knowledge outside the domain of embedded systems, we will need some new names for the core ideas.
The most important name is the One-Way Wall. I do not have a better name for it. It is the most important concept in embedded systems. In lieu of a good name, I will explain it to you, and then the name will stand for the thing you now understand. It's the best I could come up with.
But first let's dive into an embedded system and see what this wall looks like from the inside.
Mario Kart
I will assume you've played Mario Kart, or you've at least watched someone else play it. Mario Kart is the ultimate racing game in terms of sacrificing realism for fun. It bears so little resemblance to reality that it's a wonder it tickles our senses at all. The Karts skid around with impossible coefficients of friction, righting themselves from any wrong position, and generally making a mockery of the last four centuries of advances in physics.
It's really fun.
Mario Kart, like all games, has a boundary around the edge of the playing area. In Mario Kart you bump into it more often than in most other games, which is part of the reason I chose it to be our Eponymous Hero. If you want to win a race, you will need to become quite good at accelerating around corners, which means you will spend a fair amount of time bumping up against an invisible wall.
You know the wall I'm talking about, right? It's invisible, so you can see right past it to the terrain beyond. But the wall is there, and you are not permitted to venture beyond it.
In slower-paced games, when you arrive at the invisible map boundary, you will sometimes be told by the game: "You can't go that way. Turn back!" And since that is your only option, you comply. These invisible boundaries are non-negotiable.
In other games, you may stop on contact with the boundary, or perhaps bounce off. But the boundary is always there.
Imagine Mario and Luigi chatting about the you-can't-go-that-way wall. Their conversation might go something like this:
Mario: "Luigi, my brother!"
Luigi: "Maaaarioooooo!"
Mario: "Yes, Luigi. I am a here. Tell me my brother, why is it that every a time I a spin around the cactus in the third a bend of the Desert a Track, I get a stuck and have to start accelerating from nooooothing?"
Luigi: "Whaaaaa?"
Mario: "Brother, the Desert a Track! It's Number a Three! You know the big a bend, where you have to slow down? I am always a forgetting to slow, and I just a stop. Just a like that!"
Luigi: "I don't know, Brother. That Bowser, he is always a squishing me right before I hit that turn, and I am a flat like a pan a cake for a looooong a time."
Mario: "What about that a time two races ago, where Wario hit you and you a spun around and you a headed for the hill, and you got a stuck and wailed for me?"
Luigi: "Ah, that Wario! I will get him next a time!"
Mario: "Why did you not just turn around then?"
Luigi: "My Kart, it did not a move, no matter how I wailed."
Mario: "That is a what I am a speaking of, Brother. Your Kart moves in all other places, but if you head for the hills, it just a stops a suddenly!"
Luigi: "I a hate a stopping a suddenly."
Mario: "Yes, Brother. So do I. But why can we not traverse that a part of the hill? What is on the other a side?"
Luigi: "I think it is Track 4, Brother. They do not want you to wind up in the lake."
Mario: "Whaaaa? Who is this a 'they'? And why can we a not see the lake from a Track a 3? I think there is a nothing there, Brother. Just a more hills."
Luigi: "No, my brother. I think it is a Track a 4. Or maybe Track a 2. There must be a something there."
Mario: "Perhaps you are a right, my brother. We should get a back to a racing now. We can talk a more about a this after the next a race."
Luigi: "Yes, brother. I will a get that Wario this a time!"
Well-formed nonsensical questions
In our Highly Realistic Dialog, Mario is wondering about the Invisible Boundary at the edge of the track. He asks his brother the seemingly obvious question: "What is on the other side?"
As a gamer, if you pause to consider the question at all, the answer seems to be: "Nothing I care about." The invisible (or sometimes visible) Boundary seems just like any other wall. It is designed to keep you in where you're at, or out of where you're not, depending on your point of view.
But the gamer's view is that the boundary does have another side. You have no way to get there, but it exists. For maximum gameplay immersion a game universe needs to appear consistent. Thus, when you peer through the wall it appears that the other side is just more of the same.
To an embedded systems programmer, Mario's question is complete nonsense, like a fish asking the temperature of the water on the other side of the glass. There is no water on the other side, and for that matter a fish can't ask questions, so the question itself is based on nonsense premises.
From a perspective within the Mario Kart universe, the "other side" of the Invisible Boundary is... a kind of nothingness. The embedded world quite literally ends at the boundary. The level designers usually try to make it appear as if the current world continues on, but this is an illusion. They discontinue the model's polygons beyond the line of sight. Put another way, the water stops at the edge of the tank.
The nothingness beyond the Invisible Boundary of an embedded system is much deeper and more significant than simply not having objects there. In that nothingness there is no programmatic substrate upon which to place objects. If you were to ask: "What lies between Mario's head and Luigi's head," the answer may well be "nothing", since no game objects may overlap the line between their heads at the particular time you ask the question. But that "nothing" is qualitatively different from the "nothing" on the other side of the Invisible Boundary. Between Mario and Luigi there is a space – a place in their universe where objects and forces and logic apply, even if they are Mario Kart's twisted versions of physics and logic. That universe ends abruptly at the surface of the boundary.
The question "What's on the other side" is well-formed in a strictly mathematical sense. You could project a line from Mario to the nearest boundary, and ask the more precise question: "If Mario is at distance D from nearest boundary B, what overlaps the point P obtained by extending the Mario-boundary line L to a distance D beyond B?" ("Whaaaaa?")
The new formulation of the question is more well-formed, but it is every bit as semantically nonsensical.
What's really on the other side
In the context of the Mario Kart universe, the system boundary truly only has on side, and Mario and Luigi are on that side. From their perspective, we can't meaningfully ask the question "What's on the other side?" However, there is a semantically significant interpretation of "the other side" of that invisible boundary. To get to this better answer we must leave Mario's universe.
From the perspective of an embedded systems programmer, the entire Mario Kart universe is data structures laid out in the memory space of some machine. There is a program — the game engine — that interprets the data in a way that makes it appear to be a universe that is similar to ours in various intuitively appealing ways, yet different from our universe in various fun ways.
It is very unlikely that the polygons and other level data are laid out in strictly contiguous order in the host machine's memory space. It is more likely that they are spread out, with gaps, like dominoes spilled on a tile floor.
The question "What's on the other side?", when viewed from the perspective of a systems programmer, might be phrased more precisely and meaningfully as follows: "What occupies the memory spaces adjacent to the memory used by the Track Three Desert Level?"
This is the same as Mario's question, but we had to step outside the Mario Kart universe in order to ask the question in a way that made sense. The Mario Kart universe, like most game universes and in fact most embedded systems, is designed to appear complete. There is apparently "stuff" beyond the boundary; you just can't go that way.
When we step up into the host system and ask the analogous question about the "other side", both the question and the potential answers become much more complex: many orders of magnitude more complex, in fact. Fortunately, due to the Mario Kart system being so simple, increasing the complexity still gives us a vaguely accessible problem.
Let's try to cook up an answer to this new, more complex question regarding the contents of the program memory space on the "other side" of the invisible wall.
In terms of atomic program units (say, bits or bytes), the amount of memory used by a game like Mario Kart is actually high enough to defy our sense of scale. A game with hundreds of megabytes or gigabytes of runtime data has billions of discrete elements, which is too many for us to keep track of individually. One of the key jobs of a programmer is to organize their code so that the elements can be managed at human-CPU scale: up to seven "things" at a time. But this organization can't mask the fact that billions of individual elements exist, each with its own role to play in supporting the embedded system.
Hence, even for a game as "simple" as Mario Kart, we're stuck imagining how it works internally. Even the programmers who built the game have only a dim and incomplete mental model of the game. It's like building a skyscraper, or a city: you build it a piece at a time, and it's rarely fruitful to try to picture everything inside of it simultaneously.
Anything that goes wrong or is out of place in the program could take days to track down with state of the art tools. That's just how it is. We're not able to comprehend large problems all at once; we can only attempt it in small increments.
Bearing this necessarily incomplete understanding in mind, what exactly would we find in the machine memory between the elements of Mario and Luigi's track mini-universe?
The answer is familiar to programmers and perhaps surprising to non-programmers. The answer is: almost anything. It could be elements of a different program, or random garbage not being interpreted by any program, or supplemental data for the Mario Kart universe, such as language translation strings. Or Luigi could be right: it could be Track 4, pre-cached for the next race. Perhaps not exactly the way he's imagining it, but... close.
Moving beyond the Wall
Our little visualization of the host system's memory raises another natural question: what would happen if you "zapped" Luigi's Kart across the boundary?
This question isn't entirely as nonsensical as "what's on the other side?" With the proper programming tools, you might be able to observe changes in the machine memory as Luigi's Kart moves, and these changes might follow an observable pattern that leads to a relevant prediction of sorts.
As just one possibility, Kart motion might be represented as shifting a Kart memory structure along the sequential indexes of an in-memory array. This arrangement is unlikely for performance reasons, but it's certainly possible, and should serve to illustrate the point. If you were to find that moving Luigi's Kart ten meters (in the scale of Luigi's track universe) resulted in a structure motion of 1000 memory addresses, then you might make the reasonable prediction that in another ten meters his representation would move another 1000 addresses.
This might well put him beyond the end of the physical memory array. In most real-world scenarios this would be a bug, and would result in some sort of nasty response from the machine, such as a game crash. Or in a more user-friendly environment, the game engine might simply prevent his motion in that direction and move him back into his universe. This might put his Kart in an uncomfortable position, but it will at least be a real position according to the logic of the Mario Kart universe. At least the Kart won't have disappeared.
However, it is infinitesimally possible that Luigi's Kart could be moved into another physical machine process in the host system — say, another instance of Mario Kart running on a time-sharing operating system or virtual machine — in such a way that Luigi and his cart physically disappear from the old universe (a process address space) and appear in the new universe (another process address space).
Even if this infinitely remote possibility were to occur, chances are high that the sudden appearance of Luigi and his Kart would wreak local or even global havoc in the new universe. He might get lucky and crush Bowser into a pan-a cake, but more likely he would wind up stuck in a stone wall or a hill, unable to move. Or even more likely, his Kart's memory structure would be copied into a non-game area, such as the translation string section, and Luigi's sudden mysterious appearance might manifest as nothing more than garbled speech from one of the other characters.
There are many possibilities, too many to imagine. The most important takeaway here is that no matter how unlikely Luigi's safe intra-universe migration may be, it is possible. With some external help from the host system, it would even be straightforward: perhaps no more than a few days work from a skilled programmer.
In real-world programs sharing adjacent address spaces, it's improbable (but possible!) that migrating data from one process to another in a randomly chosen destination spot would have semantically meaningful results in the destination address space.
To put it in simpler terms: under just the right circumstances, Luigi could teleport to the other side, and wind up in a different world.
Ghosts in the machine
An embedded system is a little environment. My Betta in the previous installment of this little series lived in a very simple embedded system. Its most obvious difference from my own environment is that the tank was filled with water, while my room was filled with air. The differences from the host system can yield different behavior and different rules. In the fish tank, the rules are only a little different — for example, most things are more buoyant inside the tank. In a virtual embedded system, the rules and behavior might be completely different from those of the host system. It all depends on how the embedded system was designed to work.
Every embedded system has a containing surface, which might be called its frontier. The frontier is one-sided in the sense that the rules of the embedded system may simply stop at the boundary: there is no "other side". In some embedded systems (such as a Euclidean space embedded in a non-Euclidean space), even the supposedly intuitive notion of extending a line across the boundary only has meaning on one side, the "inside" of the frontier.
If there is a formal mathematical term for this One-Sided Frontier idea, I've yet to come across it, and I've spent quite some time looking. If you have any suggestions, let me know. The closest I could find are the spaces that are undefined in noncontinuous functions, such as the Tangent function for a value of 90 or 270 degrees. If you ask a question
f(x)
at these values of x
, the answer is something like "You can't go that way."So the other side of the frontier is
undefined
. This statement has a deep, almost philosophical meaning to programmers. It does not mean "nothing"; no, no no! It means anything. It is a modern-day Wand of Wonder, a Bag of Tricks, a Horn of Plenty, a Box of Chocolates. You never know what you're going to get.If a computer program's code inadvertently reaches into
undefined
, then it has stepped across a mystical wall into another universe, and anything could happen. It's as if Gremlins have taken over the machine. Your PC speaker might beep erratically or continuously. Your video array might burst into random fireworks. Your printer might fire up and print out mysterious symbols. Your program may even continue to operate normally, but with the addition of unexplainable and unrepeatable phenomena.I have seen all these things happen. All C/C++/assembly programmers have seen bugs like this — program bugs with "crazy" behavior. The bugs are so spooky, and so hard to track down, that computers are now designed to be gatekeepers at the Wall, and when you try to step across they say STOP! It's much better to be blocked immediately than to let your program wander into
undefined
, where ghosts may take hold of your data in ways that may even cause your legal department to take notice. Stranger things have happened, as they say.This computerized gatekeeping is commonly called "protected mode". The computer checks every addressing instruction, and any time a program tries to access the memory area outside its own, things halt immediately. When you see the message "segmentation fault", or a blue screen of death, or some other sign that a fatal, unrecoverable program error has occurred, it is almost always because someone or something in the embedded system tried to escape.
Holes in the Wall
From the perspective of a computer game, the system frontier is relatively uninteresting. It's not much different from any other obstacle.
However, in other embedded systems these frontiers are almost mystical in nature. They provide endless fascination for computer scientists working in the domain of programming languages, which are yet another kind of embedded system.
To see how it works, let's consider the situation in Mario Kart, which is simpler.
In Mario Kart, most of the racers are computerized opponents, or AIs. A few of them, usually at least one, are controlled by people, using steering wheels or other physical controllers. Sometimes (e.g. in simulation mode) all the opponents may be computerized.
In order for people to interact with the embedded system, there must be some way to send information back and forth across the system frontier.
Coming from the Mario Kart side, we typically have video and sound signals. The embedded system generates these signals and sends them to your TV or device.
Coming from the people side, we typically have motion input: which way to move the Karts. The signals begin as your physical motions: buttons you press, or in newer controllers, the direction you tilt the controller. They are sent from the host system to the embedded system and they generally produce observable effects in the embedded system. Like magic!
Mario Kart is especially interesting because the external camera is physically present within the game. You can see it in the instant replays of your races: a little guy with a camera, floating behind you on a little cloud. The game designers have arranged things so that you can almost never see him while racing, because he's always flying behind your head, along your line of sight.
But he's there. And in fact that camera is always there, in all video games. It's just that the Mario Kart designers have chosen to reify him as a cute little turtle guy with a camera, floating behind you on a cloud.
The external camera is a one-way hole in our one-way wall: it sends data out of the embedded system. For all intents and purposes it also sends the sound data, since the sounds are usually scaled as a function of distance from the camera.
During a race, there's a lot of stuff going on in the embedded system, and there's a lot of stuff going on in the host system. But they constrain their communication via mostly-invisible channels, and these channels are restricted in the kinds of communication they may convey. Your controller can send motion inputs, but (at least today) it can't send video data. And (at least today) the characters in the game can't control your arms and legs, the way you can control theirs.
Hopefully now you should have a mental picture of this magical wall between an embedded system and the Great Undefined Beyond on the "other side" of its system frontier. The wall may have deliberate holes in it: channels, really. Information may flow across these channels in predefined ways. And the channels are almost always invisible to occupants of the embedded system.
Reflections
I've spent a lot of effort telling you about a rather strange, twisty kind of surface: the frontier of an embedded system. This frontier exists for all embedded systems. It may have "holes" (data channels) in it. The number and nature of these channels is entirely up to the designers of the embedded system. Programmers sometimes call these channels "reflection" or "metaprogramming".
The holes in the frontier may or may not be detectable within the embedded system itself. They may only be detectable within the host system. This, again, is up to the designers. For most of the embedded systems I know of, the channels are "well defined", in the form of application programming interfaces offered to either the embedded system or the host system for communicating across the frontier.
But you need a channel for this kind of communication. Setting it up is usually not cheap. And setting up meta-reflection (in other words, being able to "see" the channel from within the embedded system or host system) is even more work.
So most of the time, channels through the embedded system frontier are completely invisible and undetectable from inside the embedded system. They're quite real, and information flows either one way or both ways, but they cannot be detected from within the embedded system, and their behavior is intrinsically non-repeatable via experimentation.
When data comes across these invisible channels, stuff "just happens" in the embedded system, with no clear indicator nor explanation as to why.
In our discussion so far, I have intentionally blurred the distinction between the host system (such as a fish tank or a game console device) and the host system's host system (such as your bedroom or living room). But you've probably noticed by now that all host systems are embedded in some larger system. This is just the way things work. The fish tank is in your bedroom, which is a system embedded in a house, which is a system embedded in a neighborhood, embedded in a county, a nation, a continent, a planet, a solar system, a galaxy, a universe.
It's perhaps not as clear in the case of fish tanks, but host systems often overlap and even cooperate. A city is composed of many interleaved subsystems. So is your body. It's not always a simple containment relationship. Systems are made of, and communicate with, other systems.
But one way or another, all systems are embedded systems.
There is no reason to assume that our Universe works any differently. Our Universe is a system; that much should be self-evident. It has boundaries; astronomers and astrophysicists have recently even determined that the boundary appears to be a dodecahedron.
We are already painfully aware of the question "what happened before the Big Bang, if in fact the Big Bang occurred in the way all the evidence suggests", and its inherent nonsensicality. What happened before the beginning of Time? What lies beyond the end of the Universe?
Programmers already know intuitively the answer to these questions. The answer is:
undefined
is there. Undefined is not the same as "nothing", no indeed. It's anything. And we can't go that way.This has ramifications for the way we think about things today.
I believe I will have more to say about this soon. Right now I think I will go play Mario Kart: a game as fun as any I think I've ever played.
71 Comments:
Very thought-provoking article. I especially liked the tie-in at the end to the questions modern science is considering about the Big Bang. You make a very valid point -- those sorts of questions are meaningless in the context of the embedded system.
The whole time I was reading your Mario Kart analogy, I couldn't help but think of the story of the Tron Lightcycle simulator built back in the days of unprotected memory. Their lightcycles wandered off into "undefined" and dealt with this exact issue.
I was glad to see you take the Flatlandian step right at the end and apply this all to our own universe. Of course, this leads to strange metaphysical problems. I'm looking forward to the next part of this series.
Wow, M and Jebadiah -- both very appropriate links! Loved 'em both - thanks for pointing me to them.
I have the final 3 parts of the series sketched out, but it may be a few months before they're all published. I'm tackling an awfully big sacred cow here, so I need to go about it very carefully.
All very thought-provoking, but I still can't pop a wheelie on my kids' Wii version...
Steve, that last comment of yours evokes a hugely amusing little mental movie: I'm picturing you sneaking up on a placid, ornately decorated bovine, peacefully chewing its cud; looking around furtively to ensure that nobody is watching; then tackling the immobile beast, which moos in surprise and then just kind of stares at you.
Also, interesting article. I'm looking forward to seeing where you're going with this.
What's beyond the end of the universe?
I say it's bugs.
I was going to post a link to the Tron article, but someone beat me too it, so I'll just say the other thing I wanted to say:
I do not have a better name for it. It is the most important concept in embedded systems. In lieu of a good name, I will explain it to you, and then the name will stand for the thing you now understand. It's the best I could come up with.
That's the best succinct defense of jargon I've ever read. I've clipped it for my snippets file, and will be deploying it in future whenever someone challenges my use of new terms for new ideas.
"What's beyond the end of the universe?"
The cowboy universe. Spluh.
Another aspect that might be worth bringing in is that it's sometimes possible to deliberately manipulate the "errors" that result from trying to pass through the wall -- the infamous buffer overflow exploit. Typically, through a lot of trial and error, malicious programmers are able to find ways that jumping out of valid space permits them to jump back into valid space, but in some otherwise impossible way (e.g. with more privileges).
Perhaps there are ways to cross the universe's wall and jump back in, in such a way as to allow otherwise impossible in-game activities such as faster-than-light travel, time travel, time reversal, or finding a parking space in midtown.
(Sorry 'bout the ghost-post, I messed up my hyperlink the first time.)
> Perhaps not exactly the way he's imagining it, but... close.
Like the 'hidden world' in Metroid. There's a wall glitch that lets you break sequence and move into areas you're not supposed to be able to access, so the wall colors and textures and enemies are 'wrong'.
> migrating data [...] would have semantically meaningful results
Yes, results like summoning nasal demons!
Actually, that desn't seem as farfetched in a MarioKart universe.
"Because just as those who draw landscapes place themselves below in the plain to contemplate the nature of the mountains and of lofty places, and in order to comtemplate the plains place themselves upon high mountains, even so to understand the nature of the people it needs to be a prince, and to understand that of princes it needs to be of the people." Machiavelli
Thanks for the nice article.
I wanted to comment on this:
> host systems often overlap and even cooperate. It's not always a simple containment relationship.
I think in any complex environment this is the case. Embedded systems (and components with interfaces) have the problem of leaky abstractions, where you need to know what's really happening on the "other side", in the host system, to function properly. I think that's an important distinction -- that it's a very simple component that has only a few interface points and no need to leak (in either direction).
Stevey, what are you working on?
Obviously you're revisiting the Foo conference discussion, but I'm really curious about your target.
Hoping for a good one.
Cheers,
PS
So all that existential metaphysical stuff is undefined, eh? Enlightening ;-)
At this moment I'm running some Javascript embedded in Rhino, in Java, in a Firefox process in Linux, possibly in a VM, in a physical CPU, in my room, etc. Most of these embedded systems are also embedded in the Internet, tunneling SSL through the firewalls to communicate with an embedded database. And all these systems have little embedded subsystems (modules)...
(This is also interesting from a security standpoint, and it cuts both ways. Say Alice opens an SSL tunnel to Bob, bypassing firewalls and wiretaps... but Charlie has somehow tapped Bob's CPU with nanotubes... Muahahaha!)
Have you tunneled through the wall of time and seen a future where programmers are actually productive thanks to a single, unified, global computing system?
Or would that be futile because you can't have modularity without some form of embedding?
Looking forward to the next installment!
And then we have embedded systems within embedded systems...
I have a feeling that this series is going to be a brilliant demonstration of "proof by analogy is fraud".
I'm just not sure whether this is intentional. Is the final installment scheduled for April 1st?
I went behind the wall in Quake. There's a gray space, and you can still move around, and return back whenever you want.
It makes no sense to talk about the universe in terms of rules, rules only apply to abstract things like space, time, walls, but they have nothing to do with the universe, which is, let's agree, something outside of our mind, the real thing that we can perceive in some way and assert that it obeys our rules. No, it doesn't.
There's no rules, and no wall, because it's complete. I believe there's no bugs in the universe because of it's completeness, no way to break the rules, because meta-rules are *just* the rules themselves.
Comparison to Mario Kart makes my brain hurt. I thing that's a sign of a broken theory, when you feel there's something wrong to it, yet you can't understand what exactly.
I liked this post a lot. It kind of felt as if I were reading Borges at some point. Nice work!
I've been thinking about this question, "What's on the other side of the wall at the end of the Universe?" since I was a kid. Until recently, the answer had to be "more Universe" to infinity. It was like, "What's the mystery of the Holy Trinity?" The answer to that one is, "No one knows. That's why it's called 'the MYSTERY of the Holy Trinity', asshole!" So, after initity, there has to be more infinity.
I got the best alternative to this kind of circular sophistry last night watching Nova on PBS. They were talking about absolute zero. One physicist thinks that matter changes into some kind of wave at that temperature. From that, I thought that infinity is not a place, but a state of matter. This is a lot more satisfying to me than "more infinity".
To relate this to your analogy to Mario, it seems to me that you used it to frame the question, but were not able to extrapolate anything new from it. I appreciate the effort, though. You've certainly attacked the question with more zeal and tencity than I ever have.
You know, I spent a hell of a lot of time, both playing Mario Kart, and studying embedded systems, but I have no idea what the hell you're talking about.
Firstly, the original Mario Kart DID have explicit walls, so clearly we're talking about the more recent iterations. ;)
Secondly, the question maps poorly to computers. What's north of the invisible wall is not track 4; there's no reason to create universal coordinates in a game! However track 4 may be stored near track 3.
Finally, many embedded systems don't have a One Way wall. An embedded system can contain physical reality, sensors to measure that reality, actuators, and a computer to drive the actuators based on sensors and a programmers' understanding of physical reality. The actuators can in turn influence reality. It's not the end of proofs or undefinedness, but it does make your logic very fuzzy. Sort of a best effort proof ;)
But this is no different than an extremely rudimentary model of the human brain (hint: much better analogy!).
@alisey: that works because quake models the world as a BSP. you can't do it in a portal-based game like Duke Nukem or Marathon.
A little off-topic on camera
If it has no ranged attacks, it becomes a silly "spectator" in the dungeon, walking around and keeping an eye on the player character but not doing much of anything else. Give it a morale of 1, lots of movement and hitpoints, and name it The "Dungeon Survivor Camera Crew". Your players will report intense satisfaction from finally maneuvering it into a deadend and killing it.
A dodecahedron so keppler was right in establishing his theory of how planet follow their paths. Iunknown I never though about it that way.
This reminds me of a book I read a long time ago, The Holographic Universe. I think I should read it again now that I'm a programmer.
Fascinating series!
The universe, to the best of our knowledge, is infinite. The possibility that the universe is a closed hyperbolic space is still there, but there is no evidence for that. That the universe were a closed hyperbolic space with dodecahedral symmetry was an idea by Jeffrey Weeks and colleagues that even made the front page of the Nature a few years ago, but in fact no evidence was found at a closer look.
You should watch the movie "The Thirteenth floor" if you haven't already. It's about exactly this (a computer-simulated world wherein one of the simulated characters gets out)
http://www.imdb.com/title/tt0139809/
It's OK if you don't agree with the author of an article, as long as you have understood what he's written.
It's even OK if you didn't bother to read all, or didn't have the chops to understand everything, as long as you understood _something_ and commented on that.
What once was kind of sad and now are getting really annoying are comments that wildly throw themselves off hills expressly defined not present in the article.
If you read something, why not try - at least for fun - to just _read it through_ before posting something that not only has been the major subject of the article, but also been defended (or at the very least expressed) quite well.
Or please just give references. Not of the "Oh, I just found this finger up my nose" kind, but tying in to chains of thought outside of your own ears.
Thanks.
Cheers,
PS
not any real connection to your posts point but it was an intersting thing to run across so soon after reading it.
http://www.sciencemag.org/cgi/content/full/322/5909/1753a
about a cell type called "boundary vector cells" whose activity patterns encode an animal's distance, in a certain direction, from a salient geometrical border.
Maybe "You can't go that way. Turn back!" is just part of the 'bio engine' implementation !
I happen to be reading "Paradise Lost" by John Milton. There, heaven, hell and earth are all "embedded systems" which are surrounded by chaos and chance.
In the book, Satan opens the gates to the enclosures of hell after having been banished to it, and the outside of the enclosure is described as:
"The secrets of the hoarie deep, a dark
Illimitable Ocean without bound,
Without dimension, where length, breadth, and highth,
And time and place are lost; where eldest Night
And CHAOS, Ancestors of Nature, hold
Eternal ANARCHIE, amidst the noise
Of endless warrs and by confusion stand. [...] next him high Arbiter
CHANCE governs all"
Sounds like undefined to me ...
Satan miraculously makes it through to heaven, as Luigi in his cart would race through system memory into a memory area where he is suddenly part of another mariocart game.
I also like the flatlands simile, such a movement would be similar to a movement in the fourth or fifth dimension in a three dimensional world. But from the perspective of Luigi or Satan, the experience of moving would probably be extremely incoherent.
Shades of Greg Egan in there...
Could the speed of light just be the clockrate of the universe? Or has quantum entanglement already wrecked that idea?
I'm somewhat surprised that no one has pointed out yet that much of what you are saying about embedded systems has also been said about languages (which, as I come to think of it, are embedded systems themselves) by the likes of Wittgenstein, Gödel and Kripke.
But something tells me you will have a pretty original insight to share at the end of it all. Can't wait.
A very fertile essay, Steve, from which many more ideas may sprout and
bloom. Here's a few regarding undefined-ness.
I think the 'undefined' concept originated from mathematics, best
example would probably be dividing any number by 0....Any
mathematician will tell you such a division is "not defined", with
good reason. I remember seeing a chain of logic that 'proved' that
1==2, and being asked "why is this proof false?", the answer being
that there as a hidden division by 0 in the proof. I forget the
details, but the moral of the story is, if your proof has a hidden
division by 0, you can prove anything, even nasal demons.
Also, undefined behavior in programs can be worse than 'gremlins' or
'nasal demons' or myseterious crashes. Undefined behavior can be a
security hole. For instance, in this CERT vulnerability
report, a compiler is permitted (by the C language standard) to
elimiate some error-checking code on the grounds that it can't happen
without assuming undefined behavior. The C programming language
leaves some behaviors undefined to appease different implementations,
or to allow research or improvements on the language, but programmers
who rely on this undefined behavior may be opening the door to
attackers.
In contrast, Java has very few (none?) conditions with undefined
behavior. I suppose concurrency race conditions might qualify as
undefined in Java, but if your Java program is single-threaded, you
don't have nearly as many gremlins, nasal demons, or what-have=you to
worry about.
The C Standards Committee is focusing on how to address these
problems in the C language itself.
I see only a few problems here.
The coordinates of an object in Mario Kart space are probably floating point values in a slot in memory somewhere. The memory could easily hold values that indicate that Luigi is spatially beyond the outside wall, but the system prevents this. If you somehow forced the coordinates of an object to go beyond this wall (using game enhancing tools to change that value or the code that prevents it from going outside that range, for example), something meaningful would probably happen.
What is outside the wall in Mario Kart? Nothing, because the wall doesn't let anything go there.
What is outside the embedded system that makes up Mario Kart? I think you are answering that question by saying "undefined".
The same important distinction exists inside our universe. Space and time are concepts that are only necessarily meaningful INSIDE THE UNIVERSE. Maybe there's nothing beyond what we consider the edges of spacetime. But I don't think that's what you were trying to talk about. You want to ask what exists outside the universe, where measurements of spacetime are likely meaningless. You apparently answer that by saying "undefined".
Yes, undefined has a bit of a mystical quality to it, but in reality there's nothing magical about it. It means "No one has decided what that should be." Saying that 1/0 is undefined just means that talking about 1/0 isn't meaningful.
In programming, if you do not define a value, the rules are defined by the environment you use. In python, if I access a variable I didn't assign anything to, it raises an UnboundLocalError or NameError, depending on the kind of variable. In C, if it's a local variable, it uses whatever happens to already be in that spot on the stack. This could be anything, but it is what it is for a very specific reason that it is not worth the effort to discover (easier to define the value and stop thinking about it).
When you talk about two different programs using the same memory space, it sort of makes sense to describe the results of one program accessing the memory of another program (except in carefully planned and valid ways) as undefined. They are unpredictable and chaotic enough that it would be very difficult to figure out why a particular result occurs.
So what does it mean when you talk about "undefined" for something outside of the universe? I don't think you make this clear. I'm tempted to say it means you don't know, but that's a stretch.
Perhaps it would be more accurate to say you cannot know. The nature of embedded systems is that multiple hosts could simulate an identical system. I could play Mario Kart 64 on a real Nintendo 64 or on a Wii with Wiiware (which uses an emulator). Assuming I have a perfect emulator and other tools and skills I don't really have, I could set up two games of Mario Kart 64 simultaneously, one on a N64 and one on a Wii, give them exactly the same controller input (and any other kind of input that might exist), and the same things will happen in each. If Luigi were to venture a guess as to the nature of what is outside, his guess must be the same in both places, and at best he will be wrong in one of the cases. It's impossible for him know what is out there.
That is, until something different happens in each system. Perhaps one of the courses is subtly different on the Wii version from the N64 version. Maybe a railing was added in the Wii version. Maybe someone drives off where that railing would be, someone else collides with that driver, etc. Suddenly the two games are not identical, and it's possible to know whether it is running on a N64 or a Wii. From "inside", one might think of the existence of the railing as "undefined" before someone ran into that space (and either bounced back or fell off the track) and "defined" as either there or not there afterwards.
That is, if I'm not abusing your terms. If I am, I would welcome some clarification.
This sort of thing is difficult to talk about, and even more difficult to talk about clearly and meaningfully. I commend you for doing both.
Arslan,
The 2=1 "proof" is as follows:
Let x = y, then
x*x = x*y
x*x - y*y = x*y - y*y
(x+y)(x-y) = y (x - y) [factor]
x+y = y [divide both sides by x-y]
y+y = y [subsitution]
2y = y
2 = 1
Very interesting post, keep it up!
On the topic of the universe as an embedded system: you've correctly addressed the main problem with most of the questions people (and even many philosophers) ask surrounding the limits of our universe, that "undefined" is about as close to a correct answer as can be given. Props for drawing the clear distinction between "anything" and "nothing", I think that's a fairly important observation!
The truly important philosophical question, in my opinion, is how to cut off the infinite regress of systems within systems - while it may not make sense to ask what's "outside" our universe, it is perfectly reasonable to inquire about the rules of the system that contains the current one, even if we do not have any looking glass into that larger system (which is certain to happen at some level - from within a Javascript interpreter it's going to be mighty difficult to figure out how the x86 processor you're ultimately executing code on works, and even if you could, you'd never be able to figure out the underlying electrical effects that cause it to work!).
Unfortunately, this raises fairly serious philosophical concerns because regardless of how complete our knowledge is of any level in the hierarchy, we can always return and ask about the rules of the super-system that contains the last one that we've understood, and the process goes on forever.
To me, the real question is how this is resolved in the Real World - clearly there is some way that the universe (or whatever we want to call the largest of the systems, the One System To Rule Them All) is able to attain its own context without running into an infinite regress, but it's hard to envision a program that can run without a processor! Perhaps there's no answer; certainly many scientists draw the line there and claim ignorance or call it "God," but one can't help but think that there's got to be some explanation, however unintuitive it might be...
An XKCD episode that asks quite similar questions: http://xkcd.com/505/
The related ideas:
a) that every computer program or set of mathematical axioms ("system") instantiates a virtual reality;
b) that there is no fundamental difference between virtual reality and "real" reality;
c) that systems, and hence realities, can be recursively embedded (nested) in one another;
and d) that physics is computation (the universe is a computer program that simulates the laws of physics)
have also been explored by: David Deutche in The Fabric of Reality, Greg Egan in Permutation City and Nick Bostrom.
I used to think this too Steve. But then I jumped over the flag pole in Super Mario Brothers and sure enough the world just kept going and going and going...
If you're looking for a better mathematical analogous concept to your invisible wall, then domain restrictions are probably a good bet. You've picked an extremely limited example -- functions with singularities, like tan, whose domain is the real numbers except a set of isolated points. But more natural examples include the square root function, whose domain is { x in R : x >= 0 }, the set of non-negative real numbers. The line x = 0 is a very real "invisible wall", and it "doesn't make sense" to follow the curve of y = sqrt(x) to the left of x = 0.
I do take a slight issue with your concept of the data channels being holes in the one-way wall of an embedded system. Certainly information starts off outside of the Mario Kart universe and ends up taking influence inside it, but it seems less natural to conclude that the information has to "cross" the level boundary in any real sense.
This is all very "Douglass Hofstadter"ish and Strange Loopy.
I am a strange loop
Strange loop
I like it.
This comment has been removed by the author.
Nice try David Hodgson. Just in case you missed it, these two steps are suspect:
(x+y)(x-y) = y (x - y) [factor]
x+y = y [divide both sides by x-y]
since x=y, (x-y)=0 and dividing by 0 is undefined. As already mentioned, 'undefined' means anything is possible, so that's why you apparently proved 2=1
In fact, if you keep going, you can make anything equal anything else you care to choose.
:)
great insight. real fruit for thirsty heart for God's way, or the universe.
This comment has been removed by the author.
Is it really undefined?
Quite often for at least some possible implementations (i.e. certain subsets of host systems) f(x) is defined and deterministic from the perspective of the host system, but undocumented from the perspective of emedded system. At such it is not really undefined, but simply unknown from the perspective of the embedded system.
Therefore if you have knowledge of the host system you can probably take advantage of the "undefined" from within the embedded system. Just ask any hackers, virus writers, game programmers, or embedded engineers ;-)
ITouchMonnkey:
In a strict sense you are right, any implementation of f(x) will
define it for values for which it is technically undefined. As a more
concrete example, you can compile a program that calculates 1/0 and
run it. On x86 systems, the program will crash (the x86 chipset
throws a hardware exception).
The real danger comes from dealing with two systems that treat
undefined behavior differently. The CERT vulnerability in
my earlier post is just such an example. It relies on the fact that
the C standard leaves undefined what happens if you have arithmetic
overflow when adding an integer to a pointer. In this example the
hardware treats pointer arithmetic averflow in a modular fashion
(wraps around). But a certain compiler's optimizer assumes that adding
a number to a pointer always yields a pointer of a larger value (eg
wrap-around never occurs), and consequently the optimizaer removes
critical error-checking code.
So I'd say that attackers and virus writers can take advantage of the
fact that multiple systems treat undefined behavior differently. And game
programmers and embedded engineers who rely on undefined behaviors
are providing a secret invitation to attackers and virus writers.
@ITouch Monkey: see Vincent's comment of 6:37 PM, December 28, 2008:
In programming, if you do not define a value, the rules are defined by the environment you use. In python, if I access a variable I didn't assign anything to, it raises an UnboundLocalError or NameError, depending on the kind of variable. In C, if it's a local variable, it uses whatever happens to already be in that spot on the stack. This could be anything, but it is what it is for a very specific reason that it is not worth the effort to discover (easier to define the value and stop thinking about it).
From the post: "When data comes across these invisible channels, stuff "just happens" in the embedded system, with no clear indicator nor explanation as to why."
The programming language Haskell explicitly encapsulates this idea using the IO monad; the Haskell type system enforces a strict boundary between the "open" functional universe, and the "closed and restricted" IO universe.
From my perspective, "undefined" it is just another way of saying "doesn't really matter".
There's nothing wrong about having "undefined" behaviour since it helps simplify things. If you assume Mario will never ever get out the track, you don't need to explicitly define boundaries and rules and checks to verify the condition that the cart can, should or would never get outside the track.
For example, right now i am writing this comment assuming that my computer will have a constant feed of electricity.
Anyway, it is a fun and nicely written article but as always you are testing new ways to seduce us readers to convince us that C/C++/ASM are bad and dangerous languages, and Java and NBL are great.
Since i am a long time reader of your blog and long texts, and as usual my expectations are continually growing, i'd like to read one blog post from you telling us from your experience the dangers and problems of Java and any "NBL" out there, and the benefits of C/C++/ASM solely available to them.
Cheers!
@dmhouse:
But more natural examples include the square root function, whose domain is { x in R : x >= 0 }, the set of non-negative real numbers. The line x = 0 is a very real "invisible wall", and it "doesn't make sense" to follow the curve of y = sqrt(x) to the left of x = 0.
But you can take the square root of a negative number, in order to follow the curve you need to turn 90 degrees onto the imaginary axis of the complex plane. So I guess technically you're not going to the left of x = 0 but the curve does continue past this point.
It's funny that I happen to read your post now, about an hour after reading about the Kalam cosmological argument
I guess you are going to clarify this statement:
"But one way or another, all systems are embedded systems."
Within the limits of the conversation so far, this statement seems at best imprecise. It looks like you are trying for an induction, however, which would put a much greater significance on being able to demonstrate that there are no exceptions - particularly a boundary system.
Anyway, I'm hooked so I will just have to wait!
-Edward
In the sort of coincidence that seems to happen to me all the time, I read your article about the same time I was reading page 373 and Calca 3 (page 927) of Neal Stephenson's new book Anathema. In the Calca (a lesson unimportant to the text but interesting enough to include as an aside) he names a concept similar to your one-way wall: The Halikaarn's Arrow. It is a one-way conduit for information to flow from one universe to another. Unfortunately, he goes on to describe these universes in terms of a DAG and therefore there can be no arrow back, but it was quite freaky to have that moment of recognition between your article and the book.
@chas owens:
it was quite freaky to have that moment of recognition
i think that's called an "upsight" :)
Steve,
Isn't a convex hull the name of the surface you're describing?
Esteban
But more natural examples include the square root function, whose domain is { x in R : x >= 0 }, the set of non-negative real numbers. The line x = 0 is a very real "invisible wall", and it "doesn't make sense" to follow the curve of y = sqrt(x) to the left of x = 0.
As another poster already pointed out, if we leave the domain, we find complex numbers. So it's really only the domain of sqrt as long as we are forced to remain in R for the results.
If you look at other domain restrictions (like 'division by 0 is not possible' or 'you can't compute functions of infinity') and peer really close, other things are peaking through. In the above case, difference quotients and derivatives or limit computations.
So it *seems* that undefined behavior is only undefined as long as we don't look closely, in many cases. This strangely relates to both programming (overflow exploits) as well as physics (Heisenberg) - although in the latter, we only see what we look for, not what is there.
You know, I hated the article (shoddiest analogy in a long time!), but the discussion sure pulls it out.
some have a curiosity & amazement of understanding the unknown, while others practice mysticism (where are u?).
When all parts are known, amazement & mysticism begin to vanish. For e.g. you do not speak of how amazing it is to fly. Software creating dazzling effects are amazing/mystical only because all paths taken are not known - if eventually tracked down bugs are no-longer mystic.
ok..i'm a party pooper...we're all living in the matrix..
This is dramatically brilliant. Really appreciate the article. I was getting tired of reading nonsense articles on nonsense blogs.
THANKS.
-Saj
Hoi!
I am really thankful for explaining this "undefined" in this article. I have been thinking about this "What's outside [the universe]?" for quite a while now, but now I can understand the problem - as being INSIDE the embedded system, I can't understand the OUTSIDE. It is in my scope of reality "undefined"... and thinking about this usually made my head hurt and my mind go "segmentation fault".
Thanks again for explaining :)
Now I can switch to think about finding a way to break that wall :D
BB
I think you are looking for "bottom" from Dana Scott's domain theory.
> If there is a formal mathematical
> term for this One-Sided Frontier
> idea, I've yet to come across it,
> and I've spent quite some time
> looking. If you have any suggestions,
> let me know.
Wow, astonishing that nobody comes up with the laws of form. Draw a distinction! ... and mark one side of of the boundary! The other side of the boundary is called the "unmarked space". The unmarked space does even not exist from the inside of the system. If you want to observe it, you have to draw another distinction, which means that you have to step outside of the system.
Another parallel which comes to my mind is Niklas Luhmann and his idea of the need, that each system has to reproduce its boundaries in itself, otherwise the system will screw up.
cite from Wikipedia:
Furthermore, each system has a distinctive identity that is constantly reproduced in its communication and depends on what is considered meaningful and what is not.
Either this has to be done by the programmer in C who takes care that pointers are not pointing to unmarked space or the system itself which are substituting pointers by references which are not able to make references to unmarked space.
I know similar comments have already been made, but... I have gotten beyond the wall in at least two games, I'm not a big gamer but I make a habit of trying to get out. It doesn't usually cause bugs, because location is just a coordinate and not a memory location. That doesn't mean the analogy doesn't work but I think there is a sort of insurmountable difference between the in game wall and the wall between player and game- one difference being the nature of holes.
So-
In Pilotwings on snes you just keep flying till you run out of fuel, and there is a functionally infinite quantity of land, no wall.
In a snowboarding game I played there were a few weird jumps you could make which got you off the game, to a weird plane of snow you could just glide on. This plane itself had an end, just a sudden end and you fall off, at which point you fall forever until you decide to quit the game. No error.
Another game had the player die after falling too far, game automatically quits.
If you program elegantly enough then there is no necessity for a mysterious wall at all, you can generate fully consistent realities.
As for our own universe, the dodecahedron thing, however weird this sounds, would mean a wraparound universe, not a wall. It's a topological thing... and I'm not even sure it implies a finite universe, I think we could live in a 3-sphere and still have it be infinite. The question is what shape the universe is AT INFINITY. :P
I've heard it argued that the Universe is really just a simulation whose physical constants, its light speeds and quark charges, are really simply the mostly basic limitations of whatever simulation is capable of displaying. I often thought this made those quantum paradoxes, the ones where a particle could be in two places at once or where Schrodinger's cat may really never actually be dead, as simply your version of 'undefined', (which is really the most eloquent way I've ever really heard it described...) as examples of trying to peer outside our simulation, our embedded system, so that it's practical rules were simply overloaded, giving way to these strange phenomena.
It's not these macrocosmic and microcosmic are meaningless (every question posed outside a context, either implicitly or explicitly provided, is truly meaningless...) There is a world outside the fish tank: the fish simply don't have access to the necessary context to provide themselves with meaningful answers. If one fish were ever to build a vehicle to escape his fish tank, the way we rocketed into space, then his worldview would expand and his undefined void would contract.
'Undefined' is therefore all a matter of perspective. In a way, our human consciousness, brokered via our five senses and our abstract usage of language, provides our only holes between the embedded system within and the larger system outside. Our very capacities for logic and reason, represented in mathematical deduction and the scientific method, could even be seen as bars in our own embedde cage, as creators and determiners of the undefined, byproducts of a pragmatic need to condense our universe to fit our own mental limitations.
It's an interesting question and I can't wait to see how you develop the theme further. These parts make me excited!
This comment has been removed by the author.
re: "If there is a formal mathematical term for this One-Sided Frontier idea, I've yet to come across it"
The term "Event Horizon" from the Mathematical Physics of Black Holes seems to fit.
C.J.
Steve, this is a great post. I was actually reading some things about quantum mechanics and drawing similiarities to what you're speaking about.
Specifically, consider the uncertainty principle... where inside the system is well known and outside the system would conversly be further unknown as the pairing is "in" and "out" of the system.
I believe Computer science is nothing more than man imitating nature... and frankly what is nature anyhow? Are machines really anything different than living beings in any way?
Do people truly understand infinity? There are infinite systems beyond our galaxy just as there are infinite systems within our own bodies. Infinitely large and infinitely smalll... a concept that despite this idea no one can truly grasp.
Hmmm... this article seems to have interesting religious/philosophical ramifications. If God does exist, and he exists outside our embedded system, then it would seem pointless to try to prove/disprove his existence. The only way we could know anything about him would be via any clues he sends into our embedded little world, should he chose to send any. What would follow from the article is that it would be pointless to attempt to prove something about a system that is outside ours. Like Mario trying to prove that I have a girlfriend! (good luck there Mario). Really enjoy reading your rants Stevey.
A pirate with a steering wheel coming out the crotch of his pants walks into a pub. He walks up to the bar and orders a pint of the finest ale.
The bartender says "Here ya go mate. By the way, you do know you have a steering wheel coming out of your nuts there, eh?"
The pirate replies "Arrrr, it's driving me nuts!"
http://avoirdestuyaux.blogspot.com/2009/02/pirate-steering-wheel-joke.html
Is Steve still around? It's been 6 weeks since the last blog.
REQUEst FOR STEVE YEGGE TO POST AGAIN
That's an intriguing post. The idea of undefined seems to be consistent with the type systems but in a far more intuitive fashion. One could invent some type system using this intuition.
If I try to get the type of "undefined" in Haskell using the command to the interpreter:
:t undefined
It gives me: forall a. a
where "a" is a type variable which means "anything" or "could be anything".
If I try to annotate it with a specific type for example:
:t undefined::Integer
It gives me: Integer.
If again, I try to annotate it with another type like:
:t undefined::String
It gives me: String.
But when I try to run "undefined", I get an exception. We get similar behavior from all other things of the type forall a. a. They either raise an exception or go into infinite loops.
Using the :t command to the interpreter is much like asking the host system the question: "If you were to give me an answer, would it be an integer/string?" The answer from the host system is "Yes. It would be an integer/string". But when you really ask for an answer, it just hammers on your head so that you can't possibly blame it ;-)
This is consistent with your post: it could be anything, but we just can't get it :)
Post a Comment
<< Home