2012/9/12 Quentin Anciaux <[email protected]> > > > 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 >
And so as such, contrary to what you claim... such a program *can't* run on actual hardware, because it is *impossible* to implement the oracle it uses. 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. > -- 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.
