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. Quentin > > benayk > -- > View this message in context: > http://old.nabble.com/Why-the-Church-Turing-thesis--tp34348236p34423089.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.
