1.8 KiB
| title | date | tags | techne | episteme | slug | |
|---|---|---|---|---|---|---|
| [SI] Why an UTM? | 2012-01-15 |
|
:done | :speculation | 2012/01/15/si-why-an-utm/ |
Why do we use a UTM? If all TMs are fundamentally equivalent, why not just pick a convenient one? Maybe there is even some kind of optimal TM that we should use?
The reason KC is based on a UTM is that you can try to cheat at complexity by embedding most of it in your TM. For example, you could add an instruction "P" that prints all the digits of π and thus claim that π can be compressed to one character. Similarly, you could add instructions for any number you want.
Here's the problem with that, though: how does your TM know how to print π? You would still need to include an algorithm in the description of the machine itself. You are really just shuffling the complexity around, not removing it. By using an UTM, you can't make this mistake because you have to explicitly provide a description of a TM as part of your program. It's therefore irrelevant if you use a simple machine and complicated algorithm, or build a complicated machine that then runs a trivial algorithm. The total complexity doesn't go down.
As a somewhat realistic example of this mistake, have a look at Divine Simplicity. Basically it's the idea that God is without parts and therefore the simplest possible thing. But that's really just a conjuring trick. You can't talk about this simple God at all without somehow specifying its properties and simply identifying them with God doesn't help you - your language still has to explain these properties. You're just using a framework in which "God" has a very short name and the language is doing all the real work. It's the theological equivalent of LenPEG.