2012/9/12 benjayk <[email protected]> > > > > Quentin Anciaux-2 wrote: > > > > 2012/9/12 Quentin Anciaux <[email protected]> > > > >> > >> > >> 2012/9/12 benjayk <[email protected]> > >> > >>> > >>> > >>> Quentin Anciaux-2 wrote: > >>> > > >>> > 2012/9/11 Quentin Anciaux <[email protected]> > >>> > > >>> >> > >>> >> > >>> >> 2012/9/11 benjayk <[email protected]> > >>> >> > >>> >>> > >>> >>> > >>> >>> Quentin Anciaux-2 wrote: > >>> >>> > > >>> >>> > 2012/9/11 benjayk <[email protected]> > >>> >>> > > >>> >>> >> > >>> >>> >> > >>> >>> >> Quentin Anciaux-2 wrote: > >>> >>> >> > > >>> >>> >> > 2012/9/11 benjayk <[email protected]> > >>> >>> >> > > >>> >>> >> >> > >>> >>> >> >> > >>> >>> >> >> Quentin Anciaux-2 wrote: > >>> >>> >> >> > > >>> >>> >> >> > 2012/9/10 benjayk <[email protected]> > >>> >>> >> >> > > >>> >>> >> >> >> > >>> >>> >> >> >> > >>> >>> >> >> >> > > No program can determine its hardware. This is a > >>> >>> consequence > >>> >>> >> of > >>> >>> >> >> the > >>> >>> >> >> >> > > Church > >>> >>> >> >> >> > > Turing thesis. The particular machine at the lowest > >>> level > >>> >>> has > >>> >>> >> no > >>> >>> >> >> >> > bearing > >>> >>> >> >> >> > > (from the program's perspective). > >>> >>> >> >> >> > If that is true, we can show that CT must be false, > >>> because > >>> >>> we > >>> >>> >> *can* > >>> >>> >> >> >> > define > >>> >>> >> >> >> > a "meta-program" that has access to (part of) its own > >>> >>> hardware > >>> >>> >> >> (which > >>> >>> >> >> >> > still > >>> >>> >> >> >> > is intuitively computable - we can even implement it on > a > >>> >>> >> computer). > >>> >>> >> >> >> > > >>> >>> >> >> >> > >>> >>> >> >> >> It's false, the program *can't* know that the hardware it > >>> has > >>> >>> >> access > >>> >>> >> >> to > >>> >>> >> >> >> is > >>> >>> >> >> >> the *real* hardware and not a simulated hardware. The > >>> program > >>> >>> has > >>> >>> >> only > >>> >>> >> >> >> access to hardware through IO, and it can't tell (as never > >>> >>> ever) > >>> >>> >> from > >>> >>> >> >> >> that > >>> >>> >> >> >> interface if what's outside is the *real* outside or > >>> simulated > >>> >>> >> >> outside. > >>> >>> >> >> >> <\quote> > >>> >>> >> >> >> Yes that is true. If anything it is true because the > >>> hardware > >>> >>> is > >>> >>> >> not > >>> >>> >> >> even > >>> >>> >> >> >> clearly determined at the base level (quantum > uncertainty). > >>> >>> >> >> >> I should have expressed myself more accurately and written > >>> " > >>> >>> >> >> "hardware" > >>> >>> >> >> " > >>> >>> >> >> >> or > >>> >>> >> >> >> "relative 'hardware'". We can define a (meta-)programs > that > >>> >>> have > >>> >>> >> >> access > >>> >>> >> >> >> to > >>> >>> >> >> >> their "hardware" in the sense of knowing what they are > >>> running > >>> >>> on > >>> >>> >> >> >> relative > >>> >>> >> >> >> to some notion of "hardware". They cannot be emulated > using > >>> >>> >> universal > >>> >>> >> >> >> turing > >>> >>> >> >> >> machines > >>> >>> >> >> > > >>> >>> >> >> > > >>> >>> >> >> > Then it's not a program if it can't run on a universal > >>> turing > >>> >>> >> machine. > >>> >>> >> >> > > >>> >>> >> >> The funny thing is, it *can* run on a universal turing > >>> machine. > >>> >>> Just > >>> >>> >> that > >>> >>> >> >> it > >>> >>> >> >> may lose relative correctness if we do that. > >>> >>> >> > > >>> >>> >> > > >>> >>> >> > Then you must be wrong... I don't understand your point. If > >>> it's > >>> a > >>> >>> >> program > >>> >>> >> > it has access to the "outside" through IO, hence it is > >>> impossible > >>> >>> for a > >>> >>> >> > program to differentiate "real" outside from simulated > >>> outside... > >>> >>> It's > >>> >>> >> a > >>> >>> >> > simple fact, so either you're wrong or what you're describing > >>> is > >>> >>> not > >>> >>> a > >>> >>> >> > program, not an algorithm and not a computation. > >>> >>> >> OK, it depends on what you mean by "program". If you presume > that > >>> a > >>> >>> >> program > >>> >>> >> can't access its "hardware", > >>> >>> > > >>> >>> > > >>> >>> > I *do not presume it*... it's a *fact*. > >>> >>> > > >>> >>> > > >>> >>> Well, I presented a model of a program that can do that (on some > >>> level, > >>> >>> not > >>> >>> on the level of physical hardware), and is a program in the most > >>> >>> fundamental > >>> >>> way (doing step-by-step execution of instructions). > >>> >>> All you need is a program hierarchy where some programs have access > >>> to > >>> >>> programs that are below them in the hierarchy (which are the > >>> "hardware" > >>> >>> though not the *hardware*). > >>> >>> > >>> >> > >>> >> What's your point ? How the simulated hardware would fail ? It's > >>> >> impossible, so until you're clearer (your point is totally fuzzy), I > >>> >> stick > >>> >> to "you must be wrong". > >>> >> > >>> > > >>> > So either you assume some kind of "oracle" device, in this case, the > >>> thing > >>> > you describe is no more a program, but a program + an oracle, the > >>> oracle > >>> > obviously is not simulable on a turing machine, or an infinite > regress > >>> of > >>> > level. > >>> > > >>> > > >>> The simulated hardware can't fail in the model, just like a turing > >>> machine > >>> can't fail. Of course in reality it can fail, that is beside the point. > >>> > >>> You are right, my explanation is not that clear, because it is a quite > >>> subtle thing. > >>> > >>> Maybe I shouldn't have used the word "hardware". The point is just that > >>> we > >>> can define (meta-)programs that have access to some aspect of programs > >>> that > >>> are below it on the program hierarchy (normal programs), that can't be > >>> accessed by the program themselves. They can't emulated in general, > >>> because > >>> sometimes the emulating program will necessarily emulate the wrong > level > >>> (because it can't correctly emulate that the meta-program is accessing > >>> what > >>> it is *actually* doing on the most fundamental level). > >>> They still are programs in the most fundamental sense. > >>> > >>> They don't require oracles or something else that is hard to actually > >>> use, > >>> they just have to know something about the hierarchy and the programs > >>> involved (which programs or kind of programs are above or below it) and > >>> have > >>> access to the states of other programs. Both are perfectly > implementable > >>> on > >>> a normal computer. They can even be implemented on a turing machine, > but > >>> not > >>> in general. They can also be simulated on turing machines, just not > >>> necessarily correctly (the turing machine may incorrectly ignore which > >>> level > >>> it is operating on relative to the meta-program). > >>> > >> > >> I still don't see why, what you describe is wishful thinking, or you're > >> wrong, or you can't explain correctly, what I understand from what you > >> write, is that you are wrong. > >> > >>> > >>> We can still argue that these aren't programs in every sense but I > think > >>> what is executable on a normal computer can be rightfully called > >>> program. > >>> > >> > >> Then if it's executable, then the simulated thing can't be different > >> (give > >> different results) than the non simulated one, so it's clear you don't > >> understand what is a computer and what is a program. > >> > >> > > And I can show that you're wrong: > > > > - You say you can write a program on an actual computer that can know it > > is > > running on "real" hardware such that I could not create a virtual > > machine/interpreter running that program, with the program giving the > same > > result. > > > That's not what I am saying. I am saying that if it gave the same results, > it may not be correct anymore relative to the levels we defined the > meta-level on, because the result would have to change based on what this > virtual machine is doing (because the meta-program it is supposed to be > emulating accesses the hardware of that virtual machine).
So back to what I said before... your "meta" program is an oracle not emulable by a turing machine, not a program. It can know exactly on what it runs. And your "program" is not a program, it is a program + an oracle (the oracle is the blackbox that can know on which level the program is running). Nothing new here, and nothing that contradict computationalism. Quentin > Note "may", it > depends on the specific definitions of levels. > > Also, I am not saying that we cannot emulate that program at all, just not > with a turing machine. That is because we can write a meta-program that > knows what a turing machine is and knows if one attempts to emulate it and > subsequently accesess its states to reflect on what it's doing (thus making > the emulation incorrect because it emulates the wrong level). This is not > necessarily precisely possible in real life, because here no turing > machines > exists and there is no clear lowest level. But there being no real > meta-programs is no more a problem than no real turing machines existing. > The point is that we can easily define a meta-program that accesses the > programs that attempt to emulate it, because in theory it is definable > which > the lowest level is (simply the level we formulate the computation on). > That's all that is required to make the point from a computer science view. > You may still say that this is not a program anymore, but I believe that it > fits very well into our intuitive notion of "program". > > I would like to see a definition of a program that excludes what I am > talking about. Do you have one? > > benjayk > -- > View this message in context: > http://old.nabble.com/Why-the-Church-Turing-thesis--tp34348236p34424939.html > Sent from the Everything List mailing list archive at Nabble.com. > > -- > You received this message because you are subscribed to the Google Groups > "Everything List" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/everything-list?hl=en. > > -- All those moments will be lost in time, like tears in rain. -- You received this message because you are subscribed to the Google Groups "Everything List" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/everything-list?hl=en.
