Recently I mentioned that mathematician John Conway died last April. To his eternal disgruntlement, he is most famous for his “game” of Life — something he considered trivial and inferior to his real mathematical work. That fame is largely due to a Martin Gardener column in Scientific American — the most popular column the magazine had published up to then.
I said I wasn’t going to write about Life because it’s such a well-covered topic, but I thought I might whip up an implementation in Conway’s honor. (Went there; did that; videos below.) Getting into it made me realize Life connects back to my virtual reality posts.
So it turns out I am going to write about it (a little).
One solution to the puzzle.
I’ve written a lot lately about the physical versus the virtual. I’ve also written about algorithms and the role they play. In this post, I revisit both by exploring what is, for me, an old friend: The Eight Queens Puzzle. The goal is to place eight chess queens on a chessboard such that none can take another in a single move.
The puzzle is simple enough, yet just challenging enough, that it’s a good problem for first-year student programmers to solve. That’s where I met it, and it’s been a kind of “Hello, World!” algorithm for me ever since.
I thought it might be a fun way to explore a simple virtual reality.
Math version 1.0
This image here of the Mandelbrot fractal might look like one of the uglier renderings you’ve seen, but it’s a thing of beauty to me. That’s because some code I wrote created it. Which, in itself, isn’t a deal (let alone a big one), but how that code works kind of is (at least for me).
The short version: the code implements special virtual math for calculating the Mandelbrot. That the image looks anything at all like it should shows the code works.
Yet according to that image, something wasn’t quite right.
In the last post I explored how algorithms are defined and what I think is — or is not — an algorithm. The dividing line for me has mainly to do with the requirement for an ordered list of instructions and an execution engine. Physical mechanisms, from what I can see, don’t have those.
For me, the behavior of machines is only metaphorically algorithmic. Living things are biological machines, so this applies to them, too. I would not be inclined to view my kidneys, liver, or heart, as embodied algorithms (their behavior can be described by algorithms, though).
Of course, this also applies to the brain and, therefore, the mind.
There’s a discussion that’s long lurked in a dusty corner of my thinking about computationalism. It involves the definition and role of algorithms. The definition isn’t particularly tricky, but the question of what fits that definition can be. Their role in our modern life is undeniably huge — algorithms control vast swaths of human experience.
Yet some might say even the ancient lowly thermostat implements an algorithm. In a real sense, any recipe is an algorithm, and any process has some algorithm that describes that process.
But the ultimate question involves algorithms and the human mind.
For the last two weeks I’ve written a number of posts contrasting physical systems with numeric systems.
(The latter are, of course, also physical, but see many previous posts for details on significant differences. Essentially, the latter involve largely arbitrary maps between real world magnitude values and internal numeric representations of those values.)
I’ve focused on the nature of causality in those two kinds of systems, but part of the program is about clearly distinguishing the two in response to views that conflate them.
Last time I left off with a virtual ball moving towards a virtual wall after touching on the basics of how we determine if and when the mathematical ball virtually hits the mathematical wall. It amounts to detecting when one geometric shape overlaps another geometric shape.
In the physical world, objects simply can’t overlap due to physics — electromagnetic forces prevent it. An object’s solidity is “baked in” to its basic nature. In contrast, in the virtual world, the very idea of overlap has no meaning… unless we define one.
This time I want to drill down on exactly how we do that.
Last time we saw that, while we can describe a maze abstractly in terms of its network of paths, we can implement a more causal (that is: physical) approach by simulating its walls. In particular, this allows us to preserve its basic physical shape, which can be of value in game or art contexts.
This time I want to talk more about virtual walls as causal objects in a maze (or any) simulation. Walls are a basic physical object (as well as a basic metaphysical concept), so naturally they are equally foundational in the abstract and virtual worlds.
And ironically, “Something there is that doesn’t love a wall.”
First I discussed five physical causal systems. Next I considered numeric representations of those systems. Then I began to explore the idea of virtual causality, and now I’ll continue that in the context of virtual mazes (such as we might find in a computer game).
I think mazes make a simple enough example that I should be able to get very specific about how a virtual system implements causality.
With mazes, it’s about walls and paths, but mostly about paths.
This is the third of a series of posts about causal systems. In the first post I introduced five physical systems (personal communication, sound recording, light circuit, car engine, digital computer). In the second post I considered numerical representations of those systems — that is, implementing them as computer programs.
Now I’d like to explore further how we represent causality in numeric systems. I’ll return to the five numeric systems and end with a much simpler system I’ll examine in detail next time.
Simply put: How is physical causality implemented in virtual systems?