3 ms·

If we're talking about Turing machines, all of the machines are of equal computational power, and are also able to emulate each other. We aren't necessarily ta

by dasht 16y ago

If we're talking about Turing machines, all of the machines are of equal computational power, and are also able to emulate each other. We aren't necessarily talking about Turing machines but let's suppose that we are. We're talking about machines powerful enough to compute anything that any Turing machine can compute. You are correct that any one of these machines can emulate any of the others. What's relevant to Kurzweil's argument is two-fold: If I tell you about Turing-class machine A and give you Turing-class machine B, we know right away that you can write an A emulator that runs on B. We know that because they are both Turing class. What we don't know is how big that emulator program is. It might take a trillion lines of code just to write the emulator. Next, I have told you about machine A but now I also give you a 50 Megabyte program (called "GENOME") that runs on machine A. Now you must write your emulator, encode GENOME for your emulator, and run it on B. We know you can do that since these are both Turing class machines. What we do not know is how many bits it will take to encode GENOME. It could be 50 Megabytes. Or it could be 50 Terabytes. You just can't tell without proving things about the specific details of machines A and B and your emulator. Kurzweil makes an argument analogous to "Hey, GENOME only takes 50MB on machine A. There's no way it takes 50TB on machine B. Information theory at work, man! Use your head!" Problem is, "information theory" says no such thing. Actually, it says "If that's all we've been told, hell it could easily take 50TB on machine B. It could take 5 bytes. Who knows? There's not enough said about machines A and B or the program GENOME to tell!" Basically I was saying that if you offer some facility to translate programs from machine A to machine B, only a very small portion of the programs on machine B will turn out to be programs that were translated from machine A. Therefore the probability of programs halting on machine A tells us nothing about what the majority of programs on machine B are likely to do, and therefore tells us very little about the probability of a random program on machine B halting. Yes. You are correctly observing that Omega is not really a constant - it is a class of constants. For machine A there is Omega_A. For machine B, Omega_B. That is why Chaitin lectures about Omega but only after several reminders that it's really "Omega_X for some specific machine X -- but I'm mostly just going to say Omega and let X be understood." So, now, think that through with Kurzweil goggles on. In Kurzweil's world, a program of 50MB on one machine can't be 50TB on the next machine -- that's just silly, right? Well, if he were correct then, in general, Omega_A and Omega_B, for any machines A and B, would have to be somewhat close in value. We know that Omega_A and Omega_B don't have to be close (other than that they both come from the same (0,1) interval). By contradiction we conclude that we don't live in the world Kurzweil is describing.

btilly 16y ago
Next, I have told you about machine A but now I also give you a 50 Megabyte program (called "GENOME") that runs on machine A. Now you must write your emulator, encode GENOME for your emulator, and run it on B. We know you can do that since these are both Turing class machines. What we do not know is how many bits it will take to encode GENOME. It could be 50 Megabytes. Or it could be 50 Terabytes. You just can't tell without proving things about the specific details of machines A and B and your emulator. If your emulator requires substantially different space to encode the raw description of the program than the original, then the emulator sucks. So if GENOME takes 50 MB to encode in one place, it should take 50 MB to encode in another. Certainly in any emulator written for real computers, it wouldn't take more than that. But we're lacking the emulator. That's important because nobody knows how big or little that will be. The point that the biologist made boils down to saying that the emulator is an incredibly complex thing that has to encode an environment whose complexity is much, much more than that of the genome. So one flaw in that line of reasoning from Kurzweil is that we have no known upper limit on the size of the emulator itself. The biologist's argument basically comes down to, "The emulator itself needs to be much, much bigger than GENOME, and we have no idea how to write it." (Note that I'm not arguing that Kurzweil is correct, but merely that your arguments against him were not correct.) Yes. You are correctly observing that Omega is not really a constant - it is a class of constants. For machine A there is Omega_A. For machine B, Omega_B. That is why Chaitin lectures about Omega but only after several reminders that it's really "Omega_X for some specific machine X -- but I'm mostly just going to say Omega and let X be understood." So, now, think that through with Kurzweil goggles on. In Kurzweil's world, a program of 50MB on one machine can't be 50TB on the next machine -- that's just silly, right? Well, if he were correct then, in general, Omega_A and Omega_B, for any machines A and B, would have to be somewhat close in value. We know that Omega_A and Omega_B don't have to be close (other than that they both come from the same (0,1) interval). By contradiction we conclude that we don't live in the world Kurzweil is describing. Not so fast. As I pointed out, even if the emulator was just a ridiculously small 50 bytes, then Omega_A would tell us very little about Omega_B because only about 1 program in 10120 on machine B would be programs that are emulated from machine A. You know nothing about the halting probability of the rest, and so Omega_A says very little about Omega_B. (Obviously that 50 bytes is ridiculously small. But in http://www.cs.auckland.ac.nz/~chaitin/lisp.html http://www.cs.auckland.ac.nz/~chaitin/lisp.html Chaitin has an interesting example of a Lisp variant that can run a theorem prover against itself with only 410 bytes of overhead. So with pairs of machines, you can get away with surprisingly little.)

by dasht 16y ago

btilly 16y ago

Next, I have told you about machine A but now I also give you a 50 Megabyte program (called "GENOME") that runs on machine A. Now you must write your emulator, encode GENOME for your emulator, and run it on B. We know you can do that since these are both Turing class machines. What we do not know is how many bits it will take to encode GENOME. It could be 50 Megabytes. Or it could be 50 Terabytes. You just can't tell without proving things about the specific details of machines A and B and your emulator. If your emulator requires substantially different space to encode the raw description of the program than the original, then the emulator sucks. So if GENOME takes 50 MB to encode in one place, it should take 50 MB to encode in another. Certainly in any emulator written for real computers, it wouldn't take more than that. But we're lacking the emulator. That's important because nobody knows how big or little that will be. The point that the biologist made boils down to saying that the emulator is an incredibly complex thing that has to encode an environment whose complexity is much, much more than that of the genome. So one flaw in that line of reasoning from Kurzweil is that we have no known upper limit on the size of the emulator itself. The biologist's argument basically comes down to, "The emulator itself needs to be much, much bigger than GENOME, and we have no idea how to write it." (Note that I'm not arguing that Kurzweil is correct, but merely that your arguments against him were not correct.) Yes. You are correctly observing that Omega is not really a constant - it is a class of constants. For machine A there is Omega_A. For machine B, Omega_B. That is why Chaitin lectures about Omega but only after several reminders that it's really "Omega_X for some specific machine X -- but I'm mostly just going to say Omega and let X be understood." So, now, think that through with Kurzweil goggles on. In Kurzweil's world, a program of 50MB on one machine can't be 50TB on the next machine -- that's just silly, right? Well, if he were correct then, in general, Omega_A and Omega_B, for any machines A and B, would have to be somewhat close in value. We know that Omega_A and Omega_B don't have to be close (other than that they both come from the same (0,1) interval). By contradiction we conclude that we don't live in the world Kurzweil is describing. Not so fast. As I pointed out, even if the emulator was just a ridiculously small 50 bytes, then Omega_A would tell us very little about Omega_B because only about 1 program in 10120 on machine B would be programs that are emulated from machine A. You know nothing about the halting probability of the rest, and so Omega_A says very little about Omega_B. (Obviously that 50 bytes is ridiculously small. But in http://www.cs.auckland.ac.nz/~chaitin/lisp.html http://www.cs.auckland.ac.nz/~chaitin/lisp.html Chaitin has an interesting example of a Lisp variant that can run a theorem prover against itself with only 410 bytes of overhead. So with pairs of machines, you can get away with surprisingly little.)